DS18B20 / Dallas Temperature - unreliable results

[ScruffR]

Can you try this library DS18B20?

[jed]

Downloaded that library, getting NANs… but the scope still looks good.

[jed]

I added some code to publish the serial numbers… all zero.

[jed]

OK… rebooted and now it’s got one of the two.

It’s unreliable… only finds that sensor, and only about 1/2 the time. However, once it’s got the sensor, the temp read is very reliable.

[bko]

Hi @jed

Argon (and all gen3 devices) have 3.3V only I/O–they are not 5V compatible.

Assuming your haven’t blown the pin out, I would try moving the pull-up resistor for the 18b20 to 3.3V instead of Vusb.

[jed]

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.

[ScruffR]

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 )

[bko]

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.

DS18B20 error "-0.06"

If you are getting all F’s, you are reading the pull-up resistor, not the DS18B20, I think. Are you sure the CRC is correct? Lots of libraries read the CRC but you have to turn on the part where you check the CRC. Some people have had better luck using a 2.2k or 1k pull-up to +5V but you need to use a 5V tolerant pin. There is a Dallas (now Maxim) document that talks about one-wire on long wires and your wires definitely long! They recommend using an active pull-down element (MOSFET) with s…

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.

[ParticleD]

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.

[Jeppedy]

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.

[ScruffR]

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.

[Jeppedy]

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.

[ScruffR]

Do you have a link to the new lib I can perhaps view on GitHub?

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

[michaelm]

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.

[EmmEff]

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.

[jed]

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.

[peet]

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.

[michaelm]

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?

[michaelm]

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.

[jed]

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

Thank you!