Temperature logging with DS18B20


I started a temperature logging project like described in Particle Make. Nine DS187B20 sensors are connected to a Photon collecting and sending the data every 15 seconds to a 20x4 serial connected LCD and sending 9 temperatures every three minutes to a Google Spreadsheet via IFTTT.
With a small number of adaptations on the basic program, the system is working perfect except for one element : the stability of the temperature-data. 30 to 50 times a day I find -0.1 readings on my LCD and on my spreadsheet.
I already adapted the “wait” times in the program from 250 to 1000 and more. I also was adding a"wait" after the read-instruction etc… This changes have a positive effect but I still find -0.1 readings.

I tried varying the pull-up resistor from 4.7 K to 1 K and I have the impression this has the best result although it isn’t yet 100 % solving the problem. In the same sense,I can, of course further diminue the value of that resistor. But maybe this isn’t the best solution.

My question is : for the moment the DS18B20 sensors are fed with 3.3 V from the Photon. At the same time my LCD is fed by 5V from the VIN-pin from the Photon.

Could it be a good solution to power also the sensors with that 5 V pin as the specifications of the DS18B20 says the minimal feed-in power is 3.3, but this can go up to 5.5 V as described in page 2 of the specification sheet from Maxlm Integrated ?
In other words ; why should I further diminue the value of the resistors if I can highen the feed-in line ?
Thanks a lot for your suggestions.


I’d leave the pull-ups at 4.7K and switch to 5V for both what you are pulling up to and for the power to the DS18B20.

Also, make sure you are checking the CRC value after reading, and repeating the read or discarding the value if you get an error.

With the proper voltage, pull-up, and CRC check there’s no need to insert a delay anywhere.


THX for your answer !.
I made the suggested changes but this wasn’t giving the expected result :
Feed-in with 5 V was done without problems. But with a 4.7 resistor I became no readings at all.
Probably this is due to the cable-length of the sensors : 6 out of the 9 sensors have a cable-length of ± 20 m. 2 sensors have 4 m and one sensor has only 1 m. cable-length.
(by the way : I couldn’t confirm longer cable-length causes more false readings)
With 5V an a 1K resistor the system is again working as before. But in less than 15 minutes I already saw a couple of -0.1 C readings. So the 5V input isn’t giving the expected breaktrough even with 1K resistor.
Therefore I made another change : the line “float datatoTemp (byte[12])…” was modified to “… byte[10]…”.
As less data have to be transmitted, I suppose they have more time to pass through…
Wait and see…
As for your suggestion to use CRC : my knowledge of C++ isn’t so high I can program that change.


I have cables over 30 meters, 4.7K pull up to VIN, DS18B20 powered by VIN. It’s twisted pair cat5 cable, so it’s less likely to have noise issues, however.

The DS18B20 library in the community libraries is the one I recommend. Here’s a bit of the code and how to check the CRC with that library:

	if (!haveSensor) {
		haveSensor = search(addr);
		if (haveSensor) {
			Log.info("DS18B20 pin=%d addr=0x%02x%02x%02x%02x%02x%02x%02x%02x found",
					pin, addr[0], addr[1], addr[2], addr[3], addr[4], addr[5], addr[6], addr[7]);
		else {
			Log.info("no sensor found pin=%d", pin);
	if (haveSensor) {
		for(size_t tries = 0; tries < 5; tries++) {
			float tempC = getTemperature(addr);
			if (crcCheck()) {
				lastTemp = tempC * 9.0 / 5.0 + 32.0 + tempAdjustment;
				return lastTemp;
		Log.info("DS18B20 pin=%d addr=0x%02x%02x%02x%02x%02x%02x%02x%02x read failure",
				pin, addr[0], addr[1], addr[2], addr[3], addr[4], addr[5], addr[6], addr[7]);

That code is in a subclass of DS18B20, so if you’re calling it directly, resetSearch, search, and getTemperature will need to be on the DS18B20 object.


THX for your input.
It’s clear the quality of the wiring has an important impact on the readings. Unfortunately I’m not in a good situation for that. Six of my sensors are located in the heating room (=garage) and between that place and the Photon, I have to pass through three old electric bipolar cupper wires. Not ideal of course.
But it’s quasi impossible for me to replace that wires as I should have to drill walls and floors…

For further use of CRC, I need more time to check your proposal.
ps : also changing the accuracy from 12 bit to 10 bit seems to have a good effect : after three hours I only found one single -0.1 reading.


another question : where can I find that libvrary you’re speaking about ?


You could try this one

The sample supports 2 sensors, but can easily be changed for 8 by just changing these lines

const int pinOneWire = D2; // <-- substitute with the pin you want to use
const int nSENSORS = 8;    // originally 2
float celsius[nSENSORS] = { NAN, NAN, NAN, NAN, NAN, NAN, NAN, NAN };
  // adapt output string to fit your needs
  snprintf(szInfo, sizeof(szInfo), "%.1f, %.1f, %.1f, %.1f, %.1f, %.1f, %.1f, %.1f"
  , celsius[0]
  , celsius[1]
  , celsius[2]
  , celsius[3]
  , celsius[4]
  , celsius[5]
  , celsius[6]
  , celsius[7]


Hey,- I’m very happy about the possibilities given by the PHOTON. But I still have some problems.
As said before, I was ± copying the Temperature-logging from the Makers section. It is working for nine sensors, 6 are situated at ± 20 m from the photon. Two are 4 m away and 1 is at ± 1 m. The data are read every 15 seconds and projected on a 20x4 LCD screen. Every 3 minutes the data are going to Particle Publish, and via IFTTT to Google spreadsheet. Everything goes, but I don’t find a solution for two problems I still have. (per info : The sensors are now connected to the 5V of the Photon but this doesn’t seem better).
My problems :
1 : “-0.1” readings : they appair for ± 20 times a day. (< 3 % of the total readings).
I was said to add a CRC-check, and although I’m convinced this is a good solution, I didn’t use this yet because I first want to find and understand the origin of those false readings.
Strangely those “-0.1” readings do NOT appair with my program (slightly adapted) running on an Arduino Uno. Neither on an Arduino Mega. So I think this error has to do with the Photon specifications.

Maybe the “-0.1” reading isn’t a temperature reading but an error code from the DS18B20. (Somewhere on internet I read the “85” result isn’t a reading but an errror code from the DS18B20. Maybe “-0.1” is also something like that. Indeed, starting the program on an Arduino (Uno or Mega) gives "85"readings just ONCE by the start) I don’t see the same “85” mention starting on my Photon.
(the Arduino-data, of course aren’t sent to Particle-Publish)

2 : Per day, I have ± 5 readings “532” (less than 1 % of the readings). Also those readings aren’t appairing on Arduino.

The errors I mentionned, aren’t more frequent with the “far-away”-sensors than with the sensors in the proximity of the Photon. Those errors are distributed “at random” over all the sensors.

I was already trying to find a solution changing the pull-up resistor (from 470 ohm to 4.7 K-ohm without good effect. Also when I inserted “delay”-times after the read/ write or conversion action, the errors stay.

Does anybody has an explanation ?


I don’t have any magic bullets for you, but information.

The -0.1 C readings are due to reading back when there is no device sending on the data line. The binary encoding for -0.1C is 111…111 so you are reading back the pull-up resistor when that happens.

I don’t know what the 532 is.

If you are driving long wires (20+m you say) with the output from a Photon directly, you should look at the follow app notes from Maxim on a special driver and network topology problems:



The simple fix is to implement CRC checking and throw away returned results that are not valid. You are taking over 50,000 total measurements per day and around 0.05% of them are bad. I think you can spend a lot of time and money to improve your electrical problems or just discard the few problems.


THX for the fast answer. Now I see what the origin of the -0.1 error is !

Maybe my text wasn’t clear enough : I have somewhat like 750 readings a day that are sent to Particle-Publish. My wish is to have those without errors, for further treatment.

Errors on my LCD-screen disappair after ±15 sec. So that’s not so important.
(of course : also there a system without errors would be perfect)

I’ll read your articles and see what I can do
(i’m not an electronician)


Second reaction : why do I don’t have the same problems with Arduino’s ?
Maybe the Photon processor is faster (I don’t know)
IF this is the case, maybe I can slowdown a little bit with “delay”-lines ???
Just questions : I try to understand.
(as a newbe)


It depends on which library you are using for Arduino, but many have CRC checking on by default.

It could also be that the Arduino can provide more output current when sinking to ground or has a slightly more sensitive input. It is hard to say. If you had proper termination of all long lines and an impedance-matched driver on both, I would say they would be the same every time because you would have taken the processor’s electrical characteristics out of the equation.

There is a recovery time after finishing one bus transaction before starting the next as I recall. Most people don’t run into that because they only have one sensor or perhaps two. Arduinos come in all speeds but the Photon is much faster than the ubiquitous Uno by a factor of around 6, so yes, that could be another reason why.


My Photon is receiving 9 temperature-results every three minutes and sending them via IFTTT to Google drive. In the beginning I had a lot of reading-errors, but thanks to the suggestions of the community, I inserted a CRC-control and those errors disappear immediately.

Now I found another error : once a day (i.e. once out of ±500 readings ) I find one line with errors.
Example as given in the middle of the three following lines (out of 500)
24,1 8.8 23.1 21.3 23.3 25.5 14.6 20.3 22.9
24.1 8.8 23.1 8.8 23.1 24.6 22.4 23.8 22.4
24.1 8.7 23.1 21.1 22.9 23.1 14.6 20.3 22.1

As you can see, the fourth, the seventh and the eight figure don’t suit in the range.
Does somebody has an explanation and/or solution for that problem ?
THANKS on beforehand.


is/are the same sensor/s reporting erroneous temperatures or is it random sensors?


All sensors are affected with that problem, but some sensors more frequent then others.


as said before ALL sensors are affected but further analysis was showing me one sensor is ALWAYS present in the bad spreadsheet-row. It’s the sensor with the shortest cable lengt to the PHOTON; Does this can explain the error ? And if YES, what’s the way to solve that problem ?
Thanks !