DS18B20 Temperature sensor and correct library for Boron?

[tremmert]

Hello,
I have a DS18B20 temperature sensor that I am wanting to use on a Boron. Basically ready the temperature every 15 minutes and publish it to the particle cloud. I have been reading through the forums and see people using 3 different libraries:

1. DS18B20 library
2. OneWire library
3. Spark-dallas-temperature library

I have been unsuccessful in getting any of these to work. The #2 and #3 I get compile errors, while #1 is giving me strange readings, 32deg every time.

Any thoughts on which library is correct and possibly any sample code that is working on the Boron?

[nrobinson2000]

I haven’t tried using a DS18B20 with gen 3 hardware yet but here is my library port that I’ve used successfully with gen 2 hardware for years. Could you try it and post any compile errors?

nrobinson2000/spark-dallas-temperature

[tremmert]

Nrobinson2000, thanks for the update! So I just added your library via the webIDE and when compiling it is throwing the following:

lib/spark-dallas-temperature/spark-dallas-temperature.h:27:36: …/OneWire/OneWire.h: No such file or directory

I did nothing special, but only included the library. I suppose I could go in and edit the file?

[nrobinson2000]

Yeah you’ll probably need to edit the files.

I’d also suggest trying the original library that I forked mine from:

tomdeboer/SparkCoreDallasTemperature

@ScruffR’s fork should work too.

ScruffR/SparkCoreDallasTemperature

[rickkas7]

The DS18B20 library works with mesh devices. That's what I recommend.

However, it's not 100% reliable. You'll probably have to do more retries than you would on the other devices. I think there's a timing/interrupt issue in the OneWire library that causes it to drop bits occasionally, especially with multi-drop.

DS18B20 library on Boron has trouble with multidrop to get sensor addresses

I was able to reproduce some inconsistent behavior but I don’t know the cause at this time. I used two TO-92 DS18B20s in a breadboard with a 4.7K pull-up resistor. Power was 3.3V. Boron 2G/3G with 0.8.0-rc.27. From the output of my test program, the first test ran perfectly. Then the no devices could be scanned for a while. Sometimes only one of the two would be found: 0000197261 [app] INFO: DS18B20 addr=0x2899040b08000097 found (index=0) 0000197280 [app] INFO: DS18B20 addr=0x288b210b08000088…

The Particle OneWire library version 2.0.3 has mesh device support. Any other library that depends on that version instead of an earlier version should at least compile on the mesh devices.

[michaelm]

I’ve read all the DS18B20 threads and ended up here after breadboarding up a known-good DS18B20 on a Boron for the first time. Like many of you here, I find these to be great sensors for a variety of applications, and I’ve been working with them for years on various Arduino devices and the Hologram Dash.

I’m seeing the same CRC fails here, and so far I’m just using a single sensor/single drop/4.7k pull-up.

So where do we think we are headed with this? Is Particle working on, or likely to work on, a library that addresses the apparent timing and/or interrupt challenges presented by the GEN-3 devices?

And yes, I do know how it goes: “The difficult we do immediately, the impossible takes a little longer.”

[Jeppedy]

I’ve been doing a lot of deep dives into DS18B20 library on Argon/Xenon. I have over more confirmation I need to do on the library, but I believe I’ve found a key issue.
They assume the devices address starts completely NULLed out at construction, but it’s NOT. This results in random behavior based on random memory storage cruft.
By making a single change in the constructor, I’ve dropped errors dramatically. I’ve also added checks for successful “select” operations, and return value indication when it fails.
I’m thinking the DS18B20 lib isn’t the most tested/dependable at this point…

[ScruffR]

@Jeppedy

I’m thinking the DS18B20 lib isn’t the most tested/dependable at this point…

Can you test DS18B20 v0.1.10?

@Jeppedy

They assume the devices address starts completely NULLed out at construction, but it’s NOT.

Actually the DS18B20 library would expect the underlying OneWire library to return a nulled out address after ds->search().

@Jeppedy

By making a single change in the constructor, I’ve dropped errors dramatically. I’ve also added checks for successful “select” operations, and return value indication when it fails.

You can always file a pull request on the library repo

GitHub - eliteio/DS18B20: Dallas One-Wire temp sensor DS18XXX Particle Photon

[Jeppedy]

Looks like the latest version, with the initializers in the constructor, is the main fix I saw. Great turn-around time!
One remaining issue I saw was that when SingleDrop and no device set in the class yet, you do a ResetSearch and a Search, but don’t confirm the search worked before proceeding.
That asssumption is a problem. I added a check for valid search, then returned Boolean (where possible) to identify if the operation run validly or not.

[ScruffR]

I’ll add that when I get round next time.

---

Update:
I have now incorporated your suggestion and published v0.1.11
However, reliability on Gen3 is still far of what we are used to from Gen1&2.
To get better results I’d expect the underlying OneWire library needs some attention.

[michaelm]

Thanks, @ScruffR – and make that double-thanks for giving up your Friday nite / Saturday morning.

Results across the board are indeed much improved for the 4 sensors I’ve just tested. Like many others here, I’m sure, Boron LTE + DS18B20 are the core of what I’m trying to do.

[michaelm]

Um, so stupid question here…

Based on this, found in DS18B20 0.1.11 header,

// device resolution
enum DS18res   : uint8_t
{
  TEMP_9_BIT   = 0x1F, //  9 bit
  TEMP_10_BIT  = 0x3F, // 10 bit
  TEMP_11_BIT  = 0x5F, // 11 bit
  TEMP_12_BIT  = 0x7F, // 12 bit
};

I’ve included in my .ino

#define TEMP_9_BIT // 9 bit temp resolution

Am I doing it right?

I won’t be surprised to hear I’m not, since the smallest jump I see between temps is about 0.11/0.12 F, or 0.07 C, regardless of whether I chose 9-bit or 12-bit.

[ScruffR]

No, you shouldn’t define that but rather call sensor.setResolution(sensorAddress, 9) to set the the resolution to 9 bit this should in turn apply the respective resolution code.
But you need to consider that higher resolutions mean longer conversion time

      { // lower resolution means shorter conversion time, low bits need masking
        case 0x00: _data[0] &= ~0b111; break;           //  9 bit  93.75 ms
        case 0x20: _data[0] &= ~0b011; break;           // 10 bit 187.50 ms
        case 0x40: _data[0] &= ~0b001; break;           // 11 bit 375.00 ms
        default: break;                                 // 12 bit 750.00 ms 
      }

[michaelm]

Thank you! It looks familiar, based on how I did it back in the Arduino / Dash days.

I do indeed want to “lock it down” to 9-bit to keep that faster conversion time, maybe even a tad more reliable?

I see 0.1.11 now appears to be using 9-bit as a default, but it’s nice to know that 12-bit is available if desired.

Looks like you gave that library a very thorough going-over.

“I learn something here everyday.”

[michaelm]

I am inching closer to the solution, but it appears I am doing so asymptotically!

I put this in my setup{}; app is the DS18B20_SINGLEDROP example.

ds18b20.setResolution(9);

I was not sure how to put the sensor address in; and I’m hoping that it will just take the bit resolution value and apply it. It compiles and runs, but I’m not sure if I’m actually changing the effective resolution here.

This is a “thought and testing exercise” more than anything – meant mostly to help in my general understanding of working with these sensors in the Particle environment.

[ScruffR]

Yup, for single drop the last found address will be used by default, so your ds18b20.setResolution(9); should work.
But I must admit I haven’t actually tested the effect of different resolution settings.

[michaelm]

Update: I put two DS18B20 buses on the board; this configuration gives me easy “plug and play” possibilities for leaded sensors.

Result: works great, no decrease in performance on sensor reliability, still at about 95% or so “good” reads after using the latest DS18B20 library (0.1.11).

[boneskull]

I’ve gotten whatever the latest version of the “singledrop” example to work with my Xenon and a single DS18B20. Curiously, I was not able to get it working with D2, but it works with D0. I’ve had no success getting any other library available on the web IDE to detect the component.

Problem is the temperature reading is off by 4-5 degrees F. Maybe it’s a Chinese knockoff, who knows…

[livesource]

I’d like to use multiple DS18B20s on a mesh enabled Xenon. I am a noob… But could a work around be to connect something in between the Mesh enabled Xenon and the Sensors? Like an I2C GPIO Expander? Or failing that, what about a non Mesh enabled Photon connected to the Xenon via I2C or UART? Do either of these workarounds have any merit? Thanks