On Mon, 5 Oct 2015 02:54:55 +0200, Jan Kandziora <j...@gmx.de> wrote:
---
That may be the culprit.
These errata initially only applied to the B7 die. But the C2 die has
another bug, it sometimes doesn't load the factory calibration values
from EEPROM on POR, resulting in wrong temperature readout.
---
I found your link and the Maxim note. Looks like my Trim values match the
proper pattern:
"28.D64788000000/errata":
> 48077
ans = 0b1011101111001101
TRIM2 0b10111011
TRIM1 0bXXXXX101
or 0bXXXXX011
"28.884D88000000/errata":
> 48117
ans = 0b1011101111110101
TRIM2 0b10111011
TRIM1 0bXXXXX101
or 0bXXXXX011
Apparently only the "XXXXX" part is variable? But they say "A failure can be
expected to effectively randomize the TH and TL values and can induce
temperature measurement errors of up to ±60 Degrees Celsius." They can't
be coding 120C into five binary bits... Maybe they respond to all 32 bits even
though they know only five should ever change? And the five bits only govern
the ±2°C range of the "blanket trim"?
My errata display showed the same Trim value the time it said "invalid" as it
did all the times it said "valid". And it sounds like if the POR read had
failed, the pattern outside the "XXXXX" area probably would have been wrong.
---
So if your bus setup is brittle and you get more PORs, it's more likely
you trigger the bug and the chip doesn't load the calibration values.
---
I'm not clear when this POR might be triggered. My current Linux session says
it has been up since February, and I don't believe the board was power cycled
even then. When I added the resistor to make 1K, I just clipped it onto the
existing resistor with the system "live" and operating. Does OWFS issue POR
commands while it is running? Is there some log or parameter I could check to
find out when a POR occurs?
But I really don't think I'm seeing a random POR read bug. As I said, my
temperature readings were constantly offset by the same amounts through all the
power cycles while I was setting up the hardware, and for all the months of
constant operation since then. I clipped in the resistor and suddenly got good
readings, without a (known) reset.
---
> But bus.0 -> Statistics -> Errors shows: CRC8_errors 11
> CRC8_tries 409
Never looked into these counters too deeply, sorry. If it really
matters, I will.
---
I have no idea if it matters. I'm just out of other ideas...
Here is a bit of early morning minimum temperature:
---
2015-10-05 08:35:07.963821 66.875 68.0
2015-10-05 08:40:08.040912 66.875 68.0
2015-10-05 08:45:08.117072 66.875 68.0
2015-10-05 08:50:08.195994 66.875 68.0
2015-10-05 08:55:08.291690 66.875 68.0
2015-10-05 09:00:08.384716 66.875 68.0
2015-10-05 09:05:08.465214 66.875 31.8884
2015-10-05 09:10:08.544804 66.875 68.0
2015-10-05 09:15:08.623682 66.9866 68.0
2015-10-05 09:20:08.691407 67.1 68.0
2015-10-05 09:25:08.767480 67.1 68.1116
2015-10-05 09:30:08.843657 67.1 68.1116
2015-10-05 09:35:08.902269 185.0 68.225
2015-10-05 09:40:08.981250 67.1 68.225
2015-10-05 09:45:09.072202 67.2116 68.225
---
Still seeing occasional 185 (85C) and 32 (0C) failures, about as often as
before. Not sure why it shows "31.8884" instead of 32, when 85 converts
exactly... Something in my Python code?
Thanks again,
Loren
| Loren Amelang | lo...@pacific.net |
------------------------------------------------------------------------------
_______________________________________________
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers
