Photon2 | DS18B20 does not work - Bug in Device OS or maybe a Library Update required?

I continue to play with the new Photon2 module. Today was starting to work through what it takes to migrate my main Boron based code to the Photon2. Some things worked some things didn’t. As I investigate each item I’ll make a post in the community.

Issue 2: A standard DS18B20 temperature sensor does not work as tested on the latest deviceOS 5.3.2.

So I also use a DS18B20 standard run of the mill temperature sensor. When trying out to Photon2 on the carrier board, I noticed I was not getting any data for temperature. I’m not sure if this is an issue with the DS18B20 library or something else. I went back to the basics of a breadboard, a DS18B20 and the example sketch from the DS18B20 library and it just returns ‘nan’.

Here is the sketch:

#include "Particle.h"
#include <DS18B20.h>
#include <math.h>

void setup();
void loop();
void publishData();
void getTemp();
const int      MAXRETRY          = 10;
const uint32_t msSAMPLE_INTERVAL = 2500;
const uint32_t msMETRIC_PUBLISH  = 10000;

const int16_t dsVCC  = D2;
const int16_t dsData = D3;
const int16_t dsGND  = D4;

// Sets Pin D3 as data pin and the only sensor on bus
DS18B20  ds18b20(dsData, true); 

char     szInfo[64];
double   celsius;
double   fahrenheit;
uint32_t msLastMetric;
uint32_t msLastSample;

void setup() {
  Serial.begin(115200);
  
  pinMode(dsGND, OUTPUT);
  digitalWrite(dsGND, LOW);
  pinMode(dsVCC, OUTPUT);
  digitalWrite(dsVCC, HIGH);

  delay(1000);
}

void loop() {
  if (millis() - msLastSample >= msSAMPLE_INTERVAL){
    getTemp();
  }

  if (millis() - msLastMetric >= msMETRIC_PUBLISH){
    Serial.println("Publishing now.");
    publishData();
  }
}

void publishData(){
  sprintf(szInfo, "%2.2f", fahrenheit);
  Particle.publish("dsTmp", szInfo, PRIVATE);
  msLastMetric = millis();
}

void getTemp(){
  float _temp;
  int   i = 0;

  do {
    _temp = ds18b20.getTemperature();
  } while (!ds18b20.crcCheck() && MAXRETRY > i++);

  if (i < MAXRETRY) {
    celsius = _temp;
    fahrenheit = ds18b20.convertToFahrenheit(_temp);
    Serial.println(fahrenheit);
  }
  else {
    celsius = fahrenheit = NAN;
    Serial.println("Invalid reading");
  }
  msLastSample = millis();
}

Here’s the basic hardware configuration:

Particle Boron using the same pin D3 for data: Works properly. Returns the correct temperature

Particle Photon2 using the same pin D3 for data: Does not work. Returns “NAN”

I spent a little time poking through the library. The OneWire.H has reference to PLATFORM_ID for something about setting fast pin access (I’m not sure what this is). Is there something in the library that needs to account for P2 or what will it take to allow P2s to work with DS18B20.

I also tested the two different example sketches in the OneWire Library Address Scanner and DS18x20 and both worked on Boron but neither one found any OneWire device on P2.

What am I doing wrong or what needs to change???

@ScruffR - Looks like you publish the original library. Any ideas or things I can try?

2 Likes

I have not enough experience with the Photon2 to pinpoint the reason. But I know that the Photon2 GPIOs act way slower than the ones on Gen3 devices (where Gen3 is already less agile than Gen2 was :pensive:).
The fast pin (aka low level) GPIO access cuts out a slew of sanity checks and hence made already “safe” code much faster on Gen2 but didn’t have as much impact (at some point it was even much slower :see_no_evil:) on Gen3 and IIRC isn’t implemented on Photon2 at all (yet).
That’s also the reason why there never was a SoftSerial on Gen3 and won’t be on Photon2 either.
Unfortunately I also cannot find any note about the usefulness of these low level GPIO calls per platform in the reference docs :pensive:

However, there is Rick’s OneWire library which also features some DS18x20 sample code.

2 Likes

Yeah, I heard rumblings about that with P2 but honestly I never dug into the details. I never needed to understand the inner workings of some of this stuff especially OneWire. I just took the libraries, used the example code to get started and it just worked until now…

I also tested that same OneWire library from Rick and the two examples included in it that you referenced. “Address Scanner.INO” and “DS18x20_Temperature.ino” and neither one worked with the P2/Photon2. Am I stuck in finding an alternative temperature sensor and P2 won’t work with DS18B20?

If so, any recommendations on something that comes with a 3’ cable? Was thinking TMP36 but in a quick search hard to find a 3’ cable version.

None of the existing DS18B20/OneWire libraries will work on the P2/Photon 2 (RTL872x). The GPIO on that MCU is very, very, slow and cannot read and write the data line fast enough for the OneWire protocol.

One option is to use a DS248
2-100 I2C to OneWire bridge. It’s inexpensive and there’s a library that works well on Particle. The caveat is that it’s been impossible to get during the silicon shortage, but finally Mouser will be getting a bunch in June 2023. Using a bridge chip removes all of the interrupt and timing-sensitive code and the library makes it non-blocking.

Another benefit is that you can use a PCA9306 or other I2C level-shifter to run the DS2472 at 5V on a 5V I2C bus. The OneWire protocol works much better at 5V over long distances.

In the future there could be a library that uses the SPI or UART peripheral on the P2/Photon 2 for OneWire, sort of like how the new NeoPixel support works, to get around the GPIO speed limitation.

The alternative I use now is to just not use DS18B20s. If you’re looking for a sensor with a cable the SHT30 is good. There are also cheaper clones, but the Adafruit one works well. Just make sure you get a SHT3x that has true I2C. The SHT1x chips use a proprietary protocol that will have the same problem as OneWire. On a circuit board (SMD) I use the SHTC3 because it’s easier to solder than the SHT30. Plus the SHT3x also has a humidity sensor and is cheaper than a DS18B20 and does not require a bridge.

To get around I2C address limitations, I’ve also added a TCA9548APWR which works well to split a single I2C bus into 8 busses when needed.

2 Likes

@rickkas7 Thanks for the guidance! As always it's much appreciated! As I'm sure others have voiced, it's a bit disappointing the latest and greatest hardware is taking a step back in GPIO performance and not natively supporting a simple DS18B20. I get it though, trade offs have to be made with any hardware design, hopefully the tradeoff that was made for slow GPIO was worth it...

Since it looks like I'll be requiring a new carrier board anyhow for the Photon2 or P2 due to my other post regarding A0 and A1 no longer being PWM capable, I suspect the most cost effective approach is going with the DS2482-100. I still need to look at the implementation details, but this would also save me a GPIO I believe.

I don't mind the SHT30 but I don't need humidity at all. They seem to be larger and more expensive than the DS18B20. I'm already using a TCA9546A for I2C multiplexing so that shouldn't be an issue to integrate in. Just was hoping to be closer to a final design without having to re-design a carrier board. Oh well... this gives a little encouragement to go right for the P2 carrier board I think.

Just to clarify, in your original reply you said

but the library is actually DS2482-100 correct? This is the part from mouser with 92K available in t minus 15 days? DS2482S-100+T&R I assume you just had a typo when you said DS2472-100??

That was a typo, which I corrected. The library supports the DS2482-100 and DS2482-800. I actually use those chips even on the nRF52 because even on that chip OneWire is not completely reliable, requiring multiple reads after CRC errors, and the libraries are blocking.

1 Like

Agree totally…I have been waiting for a chance to update my project with a Photon 2 (from a Photon) and was hoping for a fairly easy transition. Along with the fewer Analog channels, 5.5>3.3V conversion, and now this OneWire (lack of) support, it looks like it will be quite a bit more work. My initial project envisioned a one chip solution (Photon)… it didn’t end up that way but now I will have to add even more chips for the same functionality.

And of course, to top it off, Photon 2 availability for hobbyists like myself seems to be continually pushing out in time. Hopefully we do see some Photon 2 availability in the Particle store for what I believe is the latest forecast (that I have seen) of June?

BTW @jgskarda , thanks for finding out this problem and documenting it!

2 Likes

@Jonpcar yeah, I’ve been eagerly waiting as well for the photon2. If I’m putting in the time to design a new board/application mine as well do it on the latest/newest hardware for longevity.

As for Photon2 availability, I’d have to think it’s soon. Sign up for Spectra and maybe get a free one: Particle Spectra Registration is Open!

I personally ordered some P2s today as likely will go that route.

Glad I found this thread. I was pulling my hair out debugging this.

For others that stumble here, this is the full list of 3rd party libraries that don't work on the new photon 2s.

1 Like

This topic was automatically closed 182 days after the last reply. New replies are no longer allowed.