Thanks for the tip! I tried exactly this, using latest 0.1.11 library, but I could not discern a difference in sensor read reliability.
Setting the retries to “1” in the DS18B20 library example sketch for a single drop really shows how hit-or-miss the system is.
What’s the next suggested step for improvement? Should I submit an issue for the underlying OneWire library, based on @ScruffR’s thought that the underlying OneWire library could use some work?
A little bit of digging on the Inter-webs has shown that there are, apparently, fake DS18B20 sensors out there. To try and normalize my testing, I went ahead and ordered a batch direct from Digikey. I will report back, likely towards the end of next week with the results.
I ordered two from Adafruit (rather than the bundle of 10 from Amazon) and they worked immediately.
Thank you!
Sorry for the delay in replying but I have been offline for a few days. While you are waiting for your new DS18B20 sensors, if you have an Arduino lying around you could try setting up you old sensor and see if you get similar problems.
I received my new Digikey-supplied DS18B20 sensors last week. After a few days of testing, I note the the following results on my Boron (single-drop config, using a 4.7k pull-up):
Genuine DS18B20 sensors work better than my Amazon / Ebay supplied sensors. Fewer “invalid reading” and “nan” reports.
Increasing the number of retries (as per the example app for the DS18B20 library) decreases the proportion of non-reported temperatures 1), above.
Changing the temperature resolution from nine bits to 12 bits, including in between settings, does not affect the reading consistency much, if any.
When the app first boots and reports to the serial monitor, the first one or two readings from the sensor are often bad. Subsequent readings are more consistent and representative of the pattern exhibited by longer-duration execution periods (such as hours or days).
Sensors on long leads ( 6 ft, flat phone wire, connected to my breadboard with an RJ-11 connector) perform as well as a sensor plugged directly into the breadboard.
Conclusions and forward-looking assumptions:
There appears to be more work to be done with respect to how the Boron reads and processes readings for the DS18B20. What is the best way to proceed / flag to those who can help?
The immediate improvement in the quality of the readings after a cold boot of the Boron is interesting – perhaps there are background ops on board still executing (?), or a power circuit on the Boron / capacitor in the sensor have not yet reached a steady state. If I’m able to get time in the next several days, I will put my scope on the sensor during the boot / first-reads phase and see if there’s anything of note there. Input welcome.
Hi, Peet,
My sensors – both the Digikey (assumed to be genuine Maxim) and cheap-o Amazon sensors (possible knock-offs) perform well on the Hologram Dash and Arduino MKR 1400 boards.
Are these other boards 3.3V devices or 5V devices? It changes the available noise margin quite a bit. I am pretty sure Dash is 5V device but I don’t know about MKR 1400.
Also I would definitely not use flat phone cable of any length for digital signalling. It is a very low quality cable meant for non-digital applications. Use CAT5 cable if you need long runs and pay attention to the manufacturer’s app notes (Dallas/Maxim has great notes on one wire–I have linked to them here in the past).
It sounds to me like your sensors are not getting powered well. As a test, you can power the sensor from an independent +5V supply and just tie GND and data with a pull-up to 3.3V back to the Particle device.
Hi, bko,
Great points / comments. Here’s a bit more background:
I powered the sensors on the Dash from the 3.3 V pin, although they have a V-USB pin available. Multiple sensors worked fine powered by 3.3 V. The Arduino 1400 is likewise a 3.3 V device.
I hear you loud and clear on the issues and risks of using flat phone cable, and an RJ11. I was probably as amazed as anybody when it worked as well as it did on the Dash and earlier Arduino units! :-). I’ve probably built 20 sensor sets with the flat phone cable, soldered and epoxy potted on the sensor and, and phone-cable tooling terminated on the other end. Out of these, not one has had a single issue with reading consistently and accurately, despite the fact that I now believe these to be knock-off sensors. These same parts work every bit as well as, in fact sometimes somewhat better than, genuine DS18 B20 sensors plugged directly in to the breadboard 1 inch away from the boron.
Regarding the above paragraph: the working “as well as” part I could maybe understand, but the “working better than” part? I have to ask if there isn’t some type of reflection going on with the sensor that close to the Boron, that maybe does not occur with the longer leads. As mentioned above, I’m going to put the scope on it and get some screenshots in the next week or so. It may also be a simple case of some genuine DS18B20 sensors being included on the leaded set I’m currently testing! 
I join your suspicion that the issue may be one of poor power, particularly given that the device consistently has more issues within the first seconds of boot/1st sensor readings than subsequently. I’m probably not interpreting your note correctly on how to power this from a 5 V source, so I was hoping I could beg your indulgence and ask for a bit of elaboration (or diagram) on that, as I’m more than happy to test that configuration.
Thanks!