If only life were that clean! I’ve noticed significant variations in how the various non-genuine ds18b20s work. Most are actually an improvement on the genuine part, but one group are a real pain to deal with. In my collection I’ve identified 4 different classes and it looks like the MSByte of the UID gives some clue as to which class they’re in:
The first group of 3 are genuines and perform as per the spec, with very little variation. I’ve got 100 of them populating those test boards and their performance is pretty much identical. They all have 0x00 in the MSB of the UID (2nd byte from the left).
The second batch all have 0x01 in the UID MSB. They’re slightly slower than the genuines, but still within spec (just).
The third batch all have 0x80 in the UID MSB. They’re great performers and way way faster than the genuines.
The final batch are the stinkers. They all have 0x03 in the UID MSB (at least in my small sample) and take 519 msecs to convert no matter what the resolution. In addition, they don’t init the temperature readout to 85C after a power up but instead remember and return the previous conversion (if the power fail is less than ~20 mins, otherwise it returns 25C). I almost wonder if that’s an attempt to hide their non-compliance with regards conversion times. Rather than hand you back 85C, they hand you back an old temperature (or 25C) and hope you won’t notice. This might be where Brian’s 25C is coming from.
I’ve also occasionally had a non-genuine return all 0s on a scratchpad read (caught on the scope). Unfortunately that passes the crc check and you’ll get an erroneous 0C reading. So it’s worth doing an additional test that byte[4] is non-zero, and rejecting the reading if it is.
I count 4 different soft errors:
I’ve never seen any of them on the genuine parts, but I do occasionally see each of the others on non-genuine parts, especially on extremely long bus runs. crcB is the classic bit error detected by the crc check. crc1 means the read came back all-1s. This happens when the sensor didn’t recognise its UID and so nobody responded to the READ_SCRATCH command. crc0 is the all-0 case described above. ftc is failure-to-convert: it’s a lot like the crc1 case but it means the sensor didn’t recognise its UID on the CONVERT command so never started a conversion running. If you don’t check that a conversion did actually happen, you end up reading stale data - although in your case I guess that would be 85C since you power cycle between each reading (except for that last class of 0x03 devices).
UPDATE - for a much more detailed analysis including photos of the die of each variant follow the link in this post below.