DS18B20 / Dallas Temperature - unreliable results

#9

Right!

Seems like the pin is still OK, as I am still sending receiving good data. But just in case, I moved to a totally different pin, and moved Vcc to 3.3V.

Still very unreliable. This code never sees more than one serial number, and it’s inconsistent as to which one shows up. For testing, I also cut down the lead on two of the sensors, from 3m down to 0.5m. No change. I also tried different resistors, from 300Ohm (too small) to 100kOhm (too large). No change.

(Scope sill looks good)

Next I am gonna rewrite the code to specify the serial numbers. But I’ll still have to have some search routine just to find them. Grrr.

#10

I have now tried the multidrop example with two sensors and a 2k2 pull-up resistor on D2 and I do get some good readings.
Not nearly as reliable as on a Photon but still some valid readings (once the ROM ID was obtained correctly - which is a bit tricky :wink: )

DS18B20: Inconsistent ID/ROM?
#11

Hi again @jed

You should read the Dallas/Maxim app note in this earlier posting. In particular I recommend using the resistors shown and something like the FET pull-down in Appendix A. You are asking for a lot of capacitance to be driven by that IO pin.

You may also want to try slowing down the software side to give more time since a few of the pulses in your scope picture are pretty short.

Just for completeness, I think you might want to pick up a Maxim DS18b20 from DigiKey or Mouser, just to be sure you have an authentic part to test with.

#12

The last time I hooked an Adafruit DS18B20 waterproof sensor to a Photon, I saw some similar behavior, where I would get random, totally wrong temperature results maybe 25% of the time. I seem to recall seeing something about this “somewhere” a while back. That project ended up getting shelved because the fish tank I was going to use it with no longer has any fish, but I was going add range checking to my code and just throw out stuff that was way out of bounds.

#13

Quick note: DS18B20 lib is unreliable, at least in the SingleDrop (One sensor on the signal line) mode.
IT has some defects that return invalid results in some-to-many power-on results.

#14

As said in reply to your other post, can you try the recently updated version 0.1.10?

If you have suggestions to improve the library, pull-requests and/or issue reports are welcome.

BTW, on Gen1&2 that library has been working quite reliably.

#15

Absolutely. Not here to complain, but rather to help improve.
I’ll report back the results. Do you have a link to the new lib I can perhaps view on GitHub? Away from my Particle devices.

#16

Certainly :wink:
https://build.particle.io/libs/DS18B20/0.1.10/tab/DS18B20.cpp

#17

That was my take as well on my several-year old Electron 3G – all worked well there.

0.1.0 didn’t seem to make much difference, sadly.

I do see some difference between individual 18B20’s: Fresh out of the bag, some work really well (1 CRC error on 20 reads), others seem to have The Plague (1 good read out of 10 or so CRC’s).

As @Jeppedy said, want to help diagnose / be part of the solution rather than loudly complain.

#18

I don’t see any mention of good supply bypassing on the 18B20. That would be good to try to clean up the device output. Using a moderate electrolytic along with a good mylar.

Saying “BYPASS” I was referring to the VCC or VDD, not a data or signal pin.

#19

Well, I’m about to give up.

I played around, and could not get reliable readings at all. Maybe what looked like accurate readings 1/25.

  1. The routines to search for serials only returned two correct serials ONCE over an hour of playing. Mostly it returned nothing, about 10% of the time it returned one of the two.

  2. Once I had the serials, I used getTemperature(SERIAL) to return data. I didn’t dig into the code, but it returned an error most of the time, BAD data some of the time, and good data maybe 10% of the time. BUT when I disconnedted one of the sensors, BOTH calls to different serials would return data from the single sensor on the bus- that is, the disconnected sensor call did not return an error if the good one returned data. It actually returned GOOD DATA that appeared to be from the remaining sensor.

So this is unreliable.

Also, I get that there may be some issues with just using a single pull–up… however I read through the discussion, and all the signals on the scope look good. None of the issues they discuss, and the signal appears to mimic what looks like a good signal, even with 2 sensors on the bus… and if I can’t get this working with just one…?

So maybe it’s my sensors. These are a batch of cheap ones off amazon. I may buy a couple of the IC packs and try again.

#20

Hi,
I had a similar problem with an older Photon device and fixed it by putting a SINGLE_THREADED_BLOCK() { sensor request code goes here } around the sensor read requests. This seems to stop interrupts during the sensor request code.

#21

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?

#22

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.

#23

I ordered two from Adafruit (rather than the bundle of 10 from Amazon) and they worked immediately.

Thank you!

#24

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.

#25

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):

  1. Genuine DS18B20 sensors work better than my Amazon / Ebay supplied sensors. Fewer “invalid reading” and “nan” reports.

  2. Increasing the number of retries (as per the example app for the DS18B20 library) decreases the proportion of non-reported temperatures 1), above.

  3. Changing the temperature resolution from nine bits to 12 bits, including in between settings, does not affect the reading consistency much, if any.

  4. 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).

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

  1. 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?

  2. 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.

#26

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.

#27

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.

#28

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! :joy:

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!