Ds18b20 and emonTX3CM firmware

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. :grin:

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?

How long is a piece of string? Anyone’s guess is the correct answer! When I wrote that code, I considered that, if somebody went for a 5 or 10 minute reporting period, then a temperature essentially from the previous report could be too old - because I thought at the time I couldn’t afford to wait for the Dallas library to start conversion, wait and get the readings - the sensible thing to do was kick off conversion just before I needed it and carry on sampling while the sensors did their thing.

So I assume they’re all within spec and start the conversion so that they finish a few ms early.

Bur I’ve really no idea what any particular user might want the temperature for. If it’s room or outside ambient, 5 minutes old is easily OK. If you’re controlling a boiler with it, a 5 minute overshoot could well not be OK.

Are you saying that the Library only updates the temp every 5 minutes? Or is this the emonTH we have moved to?

If it is updating every 10s but I’m getting a temperature 20s old (but the kind developers have told me that), I’d probably be OK with it. If not I’d need to find a better solution.