Detect power on reset and insufficient power for DS18B20

[Laxilef]

Hi,

This PR fixes the 85 degrees issue on some DS18B20 sensors (probably not original).
Related issues: #179

I implemented the condition as it is done in the Linux kernel:
https://github.com/torvalds/linux/blob/a66191c590b3b58eaff05d2277971f854772bd5b/drivers/w1/slaves/w1_therm.c#L1177-L1181

The changes only affect the DS18B20 family and have been tested in a real situation.

[RobTillaart]

@Laxilef

The well documented value of 85 is an indication that the data is read from the device before either a convert command has been sent (POR) or the convert command was not received / processed well. This latter scenario can indicate problems with wiring, either length capacitance or pull up, and is an important warning signal.
So I propose to remove the term "fake" from the PR (comments et al) as 85 is a well documented value.

Second and maybe more important 85C is a legitimate value as the range of the sensor goes up to 125C.
So projects that measure and control in this range could get an error ?
Disclaimer: I did not check the library code to identify the possible side effects this detection of 85 has.
Maybe it has none and does it work well

Final point, in your proposed code you check the scratchpad[6]

    // detect fake data
    if (deviceAddress[DSROM_FAMILY] == DS18B20MODEL && scratchPad[6] == 0x0C) {
        if ((scratchPad[0] == 0x50 && scratchPad[1] == 0x05) || 
            (scratchPad[0] == 0xFF && scratchPad[1] == 0x07)) {
            return DEVICE_POWER_ON_RESET_RAW;
        }
    }

According to the datasheet I have this is a reserved register.
Q: do you have more information about the meaning of values in this register? please share.
(update: broadly discussed in #179, although no source this 0x0C value test makes sense. See below)

Furthermore you test with the scratchpad value 0xFF07 which is if my math is right about -15.5C
This is also a normal in range value.
Q: do you have more information about this specific value? please share.

[RobTillaart]

@Laxilef

about the 0x0C test

I quickly scanned the information of the link you gave

• https://github.com/cpetrich/counterfeit_DS18B20/tree/master?tab=readme-ov-file#solution-to-the-85-c-problem

And although that site is imho highly reliable source, it does not mention or shares the source of that knowledge either.
Apparently it sounds like an internal state or so - which is of course very interesting.

---

update 1:

Quickly went to the issue 179 too and apparently I already had worked with the 0x0C value 5-6 years ago. I do not recall the discussions but they were also about POR and the 85 C detection.

That leaves only the question open about the 0xFF07 test (-15C) where that comes from.

[RobTillaart]

@Laxilef

Read the last piece of information.

The changes only affect the DS18B20 family and have been Laxilef/OTGateway#213 (comment) in a real situation.

That use case makes perfect sense, so the testing the POR 85C pattern makes perfect sense in the library.

That leaves only the question open about the 0xFF07 test (-15C) where that comes from.

[RobTillaart]

Note: I have created an issue for my DS18B20 libraries to detect POR (85 + 0x0C) .

[Laxilef]

Second and maybe more important 85C is a legitimate value as the range of the sensor goes up to 125C.

That's true. But we also check scratchpad[6]. In my project, I don't want to reject any 85c responses because it could be a valid value.

So I propose to remove the term "fake" from the PR (comments et al) as 85 is a well documented value.

It is assumed that this behavior is possible on counterfeit DS18B20 sensors, even after requesting the convert command. I can remove the word fake, but what can I replace it with? :)

Furthermore you test with the scratchpad value 0xFF07 which is if my math is right about -15.5C
This is also a normal in range value.
Q: do you have more information about this specific value? please share.

Unfortunately, I couldn't find any official data and simply borrowed the implementation from the Linux kernel. Related commit: torvalds/linux@021da53

		Bit masks to read/write (logical OR):

                1: Enable check for conversion success. If byte 6 of
                   scratchpad memory is 0xC after conversion, and
                   temperature reads 85.00 (powerup value) or 127.94
                   (insufficient power) - return a conversion error.

[RobTillaart]

@Laxilef

OK, I understand - still this 0x0c is an undocumented feature.
That said I trust the 85C check in combination with 0x0C to be an added value for the library.

The 0xFF07 check is not explained yet, and a new magic number pops up - 127.94 - which is out of range.
Is there a way to link this 0xFF07 to 127.94?

[RobTillaart]

From: https://github.com/cpetrich/counterfeit_DS18B20

It appears the chip returns a temperature of 127.94 °C (=0x07FF / 16.0) if a temperature conversion was unsuccessful [5] (e.g. due to power stability issues which arise reproducibly in "parasitic power" mode with multiple DS18B20 if Vcc is left floating rather than tied to ground. Note that the datasheet clearly states that Vcc is to be tied to GND in parasitic mode.).

Assuming this information is correct, it is definitely another problem, so deserves its own error code. Agree?

---

Some other sources link this 127.94 value to parasitic power and not grounding Vdd pin properly.

So seems to be confirmed more than once.

[Laxilef]

These are all conversion errors. It seems to me :)
Of course, we could return error codes, but that would require deeper refactoring.
Now, if we call getTempC(...), we still won't see the reason because:
https://github.com/milesburton/Arduino-Temperature-Control-Library/blob/master/DallasTemperature.cpp#L413-L414

[RobTillaart]

More detailed diagnosis means easier support. that said, it can be merged as it is now, and later refined if needed.
In short - green light from me.

@milesburton opinion?

[RobTillaart]

@Laxilef
Gave it a good night sleep, and only a minor remark on the PR popped up.
The 0x07FF (127.94C) error does not depend on the scratchPad 0x0C value as 0x07FF is out of range.

So propose to adjust the PR to

//  detect POR and GND error conditions
    if (deviceAddress[DSROM_FAMILY] == DS18B20MODEL)
    {
        if ( (scratchPad[0] == 0x50) && (scratchPad[1] == 0x05) && (scratchPad[6] == 0x0C) ) {
            return DEVICE_POWER_ON_RESET_RAW;
        }
        if (( (scratchPad[0] == 0xFF) && (scratchPad[1] == 0x07)  ) {
            return DEVICE_GND_RAW;  //  to be added too
        }
    }

This is a stronger proposition for the 0x07FF error, and allows to diagnose both different error conditions.

my 2 cents,

[Laxilef]

Done
DEVICE_GND_* is not an obvious error name, so I used DEVICE_INSUFFICIENT_POWER_*

[milesburton]

Sorry folks I've been quiet busy. This looks good to me. Thanks for your contribution @Laxilef