Am 05.10.2015 um 22:25 schrieb Loren Amelang:
>
> 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"?
>
I don't know what the origin of these patterns in owfs is but reading
the errata/trimvalid node checks exactly for these patterns. Nothing else.
>
> My errata display showed the same Trim value the time it said
> "invalid" as it did all the times it said "valid".
>
That may be because the errata/trimvalid node does its own chip read
without updating the cache value of the errata/trim node.
> And it sounds like
> if the POR read had failed, the pattern outside the "XXXXX" area
> probably would have been wrong.
>
IIRC this trimvalid check is a safe bet only for the B7 die where the
chip would *always* send a value which is not matching the "valid"
pattern in case something failed. It's only owfs which handles the C2
die just as the B7 die.
>
> --- 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.
>
If you do bitbanging, it is sufficient to unload the w1-gpio driver to
have the bus unpowered. Part of its cleanup routine is to float the GPIO
pin. I don't think there is another reason but an (unlikely) bug inside
w1-gpio to have the bus unpowered.
> When I added the resistor to make
> 1K, I just clipped it onto the existing resistor with the system
> "live" and operating.
>
Hmm, there shouldn't change the behaviour then.
> Does OWFS issue POR commands while it is
> running?
>
This "POR command" 0x64 David mentioned in his post is actually the
"apply trim 2" command. It is only sent when writing something to the
errata/trim node
> Is there some log or parameter I could check to find out
> when a POR occurs?
>
You can check if there are ever stray 85°C readings in your log. That's
the POR value. But you get those readings only when POR just happens
while a conversion is running, so when there're no 85°C readings it
doesn't mean there was no POR, just the other way around.
> 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.
>
The resistor value just shouldn't matter there. It only affects signal
rise time on the bus.
>
> 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.
>
So you *have* POR. 85°C means POR during conversion in your setup,
because you have by no way the sensor at 85°C.
Honestly, power the sensors (with 3.3V) and see if you get rid of the
85°C bug.
Kind regards
Jan
------------------------------------------------------------------------------
_______________________________________________
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers
