I was never good with bits and bytes!
Address I get is
28 C8 8E 79 A2 1 3 ED
I wondered if it was a different command for the UID.
Looks like a 0x03 sensor which explains everything!
One in the sameā¦ 8 bytesā¦ mine is just backwards from yoursā¦ your ā3ā is the same as my 0x03 that I notice in my two worst-case sensors.
It is possible to make code that works with those sensors, once you know their quirks.
Ah serves me right for going for very cheap Chinese ones!
You and thousands of others, and in most cases thereās really no way to know what youāre buying. My first approach was: if they donāt comply with the datasheet just ignore them, but thereās enough of them out there (and nobody knows if theyāve got them) that I figure you kindaā have to support them, or spend the rest of your life answering queries about strange readings. If the 0x03 was an adequate test I guess you could just ignore them and print a warning, but weāve no way of knowing if this is adequateā¦ so far just 3 examplesā¦ 2 of mine and one of yours.
Well I did buy a batch of 10! What sketch/program/HW are you using to get these test results?
Iāll stick one on a Tasmota WmosD1 and see what it gives meā¦
Itās some āextreme 1wireā testing Iāve been doing on an stm32f207ā¦ dual 1-wire buses, 400m of cat5, 100 devices per bus with adaptive bus load measuring. Iām currently working on a full blown enviro-monitor rather than just a ds18b20. Will hopefully open-source it all eventually, but itās early days.
Iām interested in hearing the results!
Thatās really very informative, thanks @dBC.
Iām very tempted to check for the ā03ā sensors and simply report ābad sensorā, rather than try to work around it.
It would be nice, alas probably unnecessary, to adjust the library to accommodate the ā80ā sort too - those could then work down to something like 5 readings per second if you didnāt have too many of them. 
Iām going to copy all of your post and keep it with my DS18B20 data.
@Gwil, @glyn.hudson, @TrystanLea
I think you need to be aware of @dBCās findings in post 78 above.
Actually, I recently throttled mine back to no more frequently than 2 seconds to avoid the self-heating I reported here.
1 Like
As I wrote - āprobably unnecessaryā, so Iāve no real intention of doing it. Although, if in a moving fluid, self-heating is likely to be a lot less significant than it is in still air.
The library declines to process the sensors when itās asked to run faster than 0.2 s - that was to protect the power readings, nothing to do with the temperature sensors.
I shall include a warning to be printed alongside the list of sensor addresses.
If the sensor is an ā03ā one, you will see :
28 C8 8E 79 A2 01 03 ED Sensor may not be reliable
Thatās the best way I can think of to handle the problem.
1 Like
From what Brian reported, I presume applying power rather earlier that you need to (assuming itās decided we still need to switch it) is part of the answer. Given that sensors that use the RJ45 socket on our emonTx and emonPi get a constant (not switched) power supply anyway, itās use is at best questionable.
My bus is permanently powered, so Iām not well set up to test the effects of power cycling. But I did leave mine unpowered overnight and this morning the 0x03 sensor reads 25.000C. Iām almost certain 25C wasnāt the last measurement it made yesterday, and if it was itād be a helluvaā coincidence with Brianās 25C. So it looks like it remembers the last conversion for a while without power, and when that eventually fades away it replaces it with 25C.
Iāll do some more tests to see if I can narrow down āfor a whileā and update the post above when I have.
1 Like
This has, as you suggested earlier, got the scent of a fiddle/cover-up. Isnāt the honest way to report by some means that it hasnāt got a credible reading, then let whatever is receiving the data decide what to do? I donāt think Iād like to trust one of those.
What Iāve got to do is write @borpin a test sketch that varies the time between applying power and resetting/calling to convert, and/or between resetting and calling to convert, and ask him to try it and see what happens.
Its one saving grace is that it correctly implements this part of the spec:
If the DS18B20 is
powered by an external supply, the master can issue read
time slots after the Convert T command and the DS18B20
will respond by transmitting a 0 while the temperature
conversion is in progress and a 1 when the conversion is
done.
I use that approach for all sensors and then I donāt need any special code to handle the weird ones. I suspect thatās not going to work in easily with your timing constraints and broadcast conversions though. Iāve got the luxury of being able to wait until the device is finished, you mightnāt.
Before clearing the bench, I thought Iād capture some shots of that approach in action. In all these Blue is the 1wire bus, and Yellow is the bus current draw so you can tell when a conversion is in progress.
The big picture. A directed ConvertT command followed by 10msec polling to see when itās done, followed by a ReadScratch command. The resolution was set to 9-bits for this one so it demonstrates an out-of-spec conversion on a 0x03 device (520 msecs Vs 93.75 msecs)
Zoomed in on the ConvertT command. As the final bit of that command arrives at the device it starts drawing current. I immediately follow up with a read slot (the final Blue pulse) and it replies with a ā0ā to tell me a conversion is in progress. If that immediate read ever comes back as a ā1ā, I count an ftc soft error and resend the command. Otherwise I know the device received it and acted on it, and I start the 10 msec read slot polling.
Zoomed in on the end-of-conversion. Eventually, a 10 msec read slot poll returns ā1ā and I know the device has a fresh conversion ready to be read so launch the ReadScratch command.
In emonLibCM, I do more-or-less the opposite: I broadcast a Convert T a calculated number of sample sets before the next logging report is due, so that the sensors should have finished converting and the temperatures are ready to retrieve after the power and energy values have been averaged and scaled, so that the most recent temperatures can be reported without waiting while the conversion takes place.
It wouldnāt be impossible to employ the technique you describe - it would mean doing and timing a test conversion at setup time, then using that instead of the data sheet value. It would come into its own if all the sensors on the bus happened to be from the ā80ā family and a very fast logging period was required.
Am I therefore currently seeing the previous reading if the conversion is too slow? TBH, at 10s intervals it makes no practical difference to most people.
As youāre permanently powering your sensors, that looks as if it is probably the case. If you set the resolution to 12 bits, that will give the maximum conversion time and your ācloneā sensors (according to dBC) will report in less than that, so you should get the present reading from 500 ms earlier.
But I have to stress that it is unrealistic to ask for the library to accommodate a device that fails to conform to the published specification.
1 Like
Yes that is fine and perfectly reasonable. I was just checking my understanding of the end result.
Just thinking about the warning if a ā3ā - perhaps
This DS18B20 clone may be unreliable and must be wired to RJ45 or Terminal 2 for constant power.
That doesnāt cover the case for you and 11-bit resolution (the default). If the temperature is changing rapidly, or even not so rapidly, because the library is good to at least a 5 minute reporting interval. That last reading might still be OK some of the time, but Iād still call it unreliable.
And besides, are you sure thatās the only fault those ā03ā sensors have?
That definitely sounds more robust than basing anything on the MSB of the UID, but then againā¦
Thatās the approach I take. In fact on my crazy dense buses with my slow plodding one-sensor-at-a-time approach, readings can get seriously oldā¦ ~ 100 x 700 msecs = 70 secs, worst case. I just report the age with the reading. In this case Iāve got ~50 sensors on the bus and you can see the conversion as it sweeps through the sensorsā¦ oldest is 33 seconds and newest is 0 seconds:
To avoid self-heating I already limit sampling frequency to no more frequently than 2 seconds, so theyāll hit that limit when theyāve got just a few sensors. And if the readings really are time critical to someone, I give them a mechanism to force the scan to a specified sensor, making it the next in the sequence and continuing on from there.
With your broadcast approach a lot of those problems go away, but I guess get replaced with another problem: you need to know theyāre all finished converting when you go to read the results. Maybe you could assume theyāre all going to take 750 msecs all the time, and never take advantage of the faster sampling times? How critical is timely temperature data?