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.
I wrote:
And from the documentation:
void EmonLibCM_datalog_period(float _datalog_period_in_seconds)
Sets the interval (seconds) over which the power, voltage and current values are averaged
and reported. There is no return value. It has not been tested below 0.1 s nor above 5
minutes (300 s). Note that this may be called after the library had been initialised with
EmonLibCM_Init( ) so that the datalogging period can be changed whilst the sketch is
running. Note also that emoncms.org will not accept data faster than once every 10 s.
Default: 10
And for temperature measurements:
Temperature Monitoring
Temperature measurement parameters are set up prior to calling
EmonLibCM_TemperatureEnable, which enables temperature measurements
(‘conversion’). The conversion, which can take up to 750 ms depending on the
measurement resolution demanded, is triggered so that the measurement result is
available to be retrieved the next time that data is logged. The resolution and datalogging
periods must be chosen so that there is adequate time for conversion to take place.
Depending on the number of sensors, temperature reporting is not reliable, and the
resolution is reduced to 9 bits, with a datalogging period of less than 1 s, and not permitted
with a datalogging period of less than 0.2 s. …
[The following has been added, to be published shortly]
Note that problems might be experienced unless only DS18B20 sensors conforming to the Maxim specification are used.
I don’t understand what you’re saying there. The first reading is only 70 s old if you don’t publish it immediately, but wait until you’ve converted and read the last one before publishing all. Were you to do a broadcast convert, then wait for each sensor to complete its conversion, it’s highly probable that you’d only have to wait the 700 ms for the first, the rest should complete conversion at around the same time, then you retrieve all the values (testing for completion if necessary) with a sweep taking around 16 ms for each sensor - I make that 2.3 s per 100. And all temperatures are contemporaneous, and 1.6 s old.
Now you could be close to self-heating like that. 
No, you can still test each one for completion, and poll it if it hasn’t. But even if you have a ‘speedy’ one for the first few, then a rogue one, it’s unlikely to delay you significantly more than 700 ms anyway.
True, but I don’t really “publish” as such. I hang onto the latest readings from each sensor and hand them over upon request from the host. I also provide a way for the host to do a bulk reading, so figured I should provide some indication of just how stale the data is on any one sensor. And if they’re really keen, I provide them a mechanism to request “do this one next”. If they do that just after I’ve started one going it could be a full 2 x 700 msecs before I have a fresh result for them though… and on average about 1 second later.
My environment is a bit too extreme to permit broadcast conversions. The power requirements and IR drop just make it too unreliable.
I’m not sure you can. The are-you-done-yet poll is not directed at any particular sensor. I’ve not tried it in a broadcast situation, but I imagine the rules are the same: respond with a 0 if still converting, respond with a 1 when complete. So at best you’d be able to tell if all the sensors have completed the conversion, but not which ones. That might be sufficient for your needs though?
I’ve just completed an overnight test of this topology:
All wiring cat5 except for the vertical line on the left, which re-purposes the obsoleted untwisted telephone cable run in from the street and through the walls.
With that much load on the bus you need to dynamically adapt the bit timings based on the bus capacitance. Here’s how a return-to-1 looks on the scope (I’ve set the scope’s rise-time threshold to match the processors 0->1 threshold voltage):
You can see it bounces around a little but not enough to disturb things (12 usecs to 14.3 usecs). The code measures it constantly and adjusts the bit timings to match, so you can dump an extra 200m of cat5 on a live bus and it just keeps trucking.
The code measures the bus load at 12.49 usecs and in the overnight run did 75K conversions with just 1 soft error. If you drill down on that, it was a crc error while reading the scratchpad of one of the clones at the end of the 250m run, but on a retry it read fine. Since the conversion is the big time consumer, you don’t want to throw away the result because of a bit error in the reading. If I get 3 consecutive bit errors, I abandon that conversion, count it as a hard error, and try again next time around.
On a topology like that, everything just falls apart with broadcast conversion requests.
1 Like
And now, I can see why. 
Reading the data sheet, it says that the master must issue read time slots after a Read Scratchpad request “so that the DS18B20 can provide the requested data.” (obviously). To me, that seemed to imply that if the requested data isn’t ready, the master will see a zero (conversion in progress). But you’re right, it doesn’t actually say what will come back once the read command has been issued. My guess is it might be 85 °C (meaning ‘I don’t know yet, you didn’t ask me to start to convert early enough’).
That would certainly be good enough with a broadcast “convert” and a limited number of sensors, most useful of course when all the sensors are responding at about the same time, but little help to me unless I test the sensors at start-up. And even then, the benefit is small, as neither the emonPi nor the emonTx will be capable of reading the number of sensors you have while servicing the ADC interrupts.
1 Like
I accidentally tested that the other day with one of those ‘03’ class sensors. It returned the current scratchpad results (i.e. the previous conversion) if you read while it was in the middle of a conversion. I happened to still have the bus current probe on, and it remained undisturbed as a result of the premature read. It’s as if it handles 1wire transactions and temperature conversions completely separately. But we know it’s not exactly typical, so I’m not sure what the other classes do in that case. But I’d always assumed the 85C is reserved for power-up initialisation, and after that you get back the last conversion, no matter how old it might be.
If they all work like that, it might work in your favour. You may just be able to keep them all converting all the time and read them asynchronously to the conversion. Although I’m not sure what happens if the conversion completes and starts writing to the scratchpad just as you’re reading it.
The other problem is detecting sensors that have stopped participating. The ‘03’ sensors at the end of a marginal Vcc connection are very problematic. At least the rest return you 85C to let you know they’ve reset during the conversion.
1 Like
Good morning,
I also report my brief experience, on my bus I have 3 sensors (probably chinese clones), whose addresses are:
{ 0x28, 0xA0, 0xF9, 0xD7, 0x3E, 0x19, 0x01, 0xBA }
{ 0x28, 0xE1, 0xAD, 0x56, 0xB5, 0x01, 0x3C, 0x5E }
{ 0x28, 0x7F, 0xB5, 0x10, 0x0C, 0x00, 0x00, 0xBC }
the second, the one with MSB 0x3C, has the problem you describe here: the first measurement after a power interruption is always 25°C, even if the interruption lasts a few seconds, but if I feed it permanently (supply pin not managed by the library) it seems to work fine.
I report one more thing: if I set the maximum resolution (12 bit) it no longer has this effect and the first reading is always correct.
Whilst researching a related matter, I came upon a copy of a research paper into the subject of counterfeit DS18B20 sensors. It is available on Github:
and the original paper is here:
Dr Chris Petrich is a Research Associate at the University of Alaska.
1 Like
very interesting document
That is interesting. Is it worth adding in the classification code to the EmonTX Sketch?
Can you explain further? Do you mean “Family A1: Authentic Maxim DS18B20” etc?
There are 2 sketches there
Just wonder if something from that could be used to identify the device at boot that could then help with any issues arise. i.e. you don’t have a genuine one so this may not work.
Ah, I see now what you mean.
It would make the code quite unwieldy, and then what do you do if the user doesn’t have a programmer so can’t see any start-up messages?
But more to the point, isn’t it a case of caveat emptor? You might call it harsh, but is it up to the sketch to police what the user buys? If a sensor doesn’t work, then we tell them to load the “discover_fake” sketch - and if it’s fake, go out and buy a genuine one to replace it. I don’t think we ought to support the counterfeiters, in any way. I think it should go on the Shop page for the emonTx, emonTH and emonPi that our software is guaranteed to work only with genuine Maxim sensors, and if a non-genuine one is connected, it might or might not work.
And therein lies the second problem: some of the fakes might, or even will, work, but sorting out and identifying which will and which won’t - why should we?
The easiest test - until the fakers catch on if they haven’t already - is the device address. Those can be printed at startup, but the same programmer (lack of) argument applies.
Yes fair enough, just wondered if a useful debugging tool.
If you are serially connected, then getting the startup info can be done reasonably easily.
I’m not suggesting supporting clones, just suggesting it might be a means of helping users with issues.
Just a thought…
I looked at those diagnostic sketches briefly, and didn’t see where the response time was measured. That’s what is going to cause failures with emonLibCM, because the sensors are commanded to measure the temperature just in time for the reading to be available when the data is sent back. If the sensor doesn’t respond, then it’s missed the boat.
If that isn’t in the non-dangerous “discover_fake” sketch, it might be an idea to add it.
1 Like
I have now added a “response time” test to Dr Chris Petrich’s sketch.
It is customised for the emonTx V3.x, but a comment contains a list of the pin numbers required for each OEM sensor node.
discover_fake_DS18B20.zip (5.2 KB)
The ZIP file also has a screen dump of the typical output for a good DS18B20 sensor
N.B. It has only been tested on an emonTx V3.2 with one sensor.
Also, as mentioned above, note that emonLibCM initiates the reading of the temperature sensors so that the reading becomes available just before the values are due to be reported. A sensor that fails the reporting time test is not likely to work, and should be replaced by a genuine Maxim component.
INSTALLATION
Unzip the sketch into a directory in your usual Arduino sketch folder named “discover_fake_DS18B20”. The OneWire library is required, this should be part of the normal installation to compile OEM sketches.
The sketch runs repeatedly, changing the state of the on-board LED each time. Untick the “Autoscroll” box in the Arduino IDE to freeze the display.