DS18B20 Dallas Temperature readings jumping high at random intervals

Thanks @bko
I fixed that. Shouldn’t that have caused a compile error?
Could that have caused the issues? So far, even without that fix, it has not generated a random higher-temp reading since loading 0.4.4
I’ll check it with the OneWire lib next.

Hi @MisterNetwork

No, it is difficult to make a compile-time error for that case and it is a very common fault. And yes, it could easily explain the symptoms you were seeing since the Spark (Particle) variable was reading from a location in memory that was not correct.

The issue of using & with strings comes up very often. I wonder if some C++ template magic can help check this at compile time. Currently the variable is of type void* which gives us no checks…leave it with me and I’ll try to make this better.

1 Like

Done. Attempting to use &string with a STRING variable produces a compiler error. This will be in 0.4.6.

2 Likes

Cool. The OneWire Lib seemed pretty solid, too, so I’m loading 0.4.5 and we’ll see what happens.

Wow! Not 2 minutes after upgrading to 0.4.5 it threw it’s first jump from 80 to 136F.
Hmmm…

Just to be sure we’re on the same page, can you point me to the github repo containing the library you’re using. I’ll take a look when I have time.

Hi Mat,
Currently using the OneWire Lib listed under Libraries on the Web IDE. Prior, I was using https://github.com/cdrodriguez/Particle-OneWire.

I’ll let this one cook for a while and see it does any more jumping.

  • BTW - Mat @mdma and Brian @bko as well as everyone else:
    Thanks for your continued help. This forum is such an incredible community!! :smile:
1 Like

I’ve been experiencing this same issue with my DS18B20 on 0.4.5 using https://github.com/Hotaman/OneWireSpark. Pretty much took my routines straight from his examples.

Temperature reads 76 most of the time, I was getting the occasional 131, and have been seeing 31 recently. I had chalked it up to a weak connection on my breadboard :smile:

Update - After letting it run on 0.4.4 and only getting a few high jumps in a weeks time, I just updated to 0.4.6 and already gotten 2 jumps at 134F in the last 2 hours with room temp @80F. not even using floats
:frowning:

Report from pushingbox, you can see frequency of temp jumps. Jump temp is always 58F greater than current temp.

I have a few DS18B20s laying around, I’ll throw my core code onto a photon and see if I get the same results. I use the libs on @krvarma’s github.

Updated history …

I’ve had mine running for a bit today and no jumps but getting 31.89 or -0.06 which I believe is no data. It is fairly regular so going to have to dig…

Here are the CRCs from a good read and a bad read. Really need one of the smart guys like @bko or @peekay123 to help decipher this though. I also get random FFFFFFF which becomes 31.89 as well, more common than the high value for me.

CRC=8D
71.37
Publishing now.
5E 3 4B 46 7F FF 2 10 8D

CRC=F7
128.98
Temp is high: 128.98
17:51:36
5E 1 4B 46 7F FF 2 10 8D

… and there’s the +57 degree difference! :smile:
I get a very occasional 30F reading. I only check for a high temp, and don’t check for a low temp so it may only be when the bad read immediately precedes my 30 second publish.

Could it be that the photon is just too fast compared to the core for the same loop?

Hi @LukeUSMC and @MisterNetwork

The way the CRC works in these parts is that you calculate the CRC of lasered address and compare it to the last byte and they should match. You can see in your two examples that in the first one, 8D matches 8D but in the second one, F7 is calculated because the second byte has been changed from 0x03 to 0x01 and the calculated CRC does not match 8D.

The best thing to do is have your software discard any data where the calculated CRC does not match last byte of the address.

I am thinking you have an electrical problem.

  • Are you using parasitic power with two wires data/power and ground to temp sensor? If so, you should try with three wires, power, ground and data.
  • You should also try a different pull-up resistor value–they recommend 4.7k so the approximately 40k pull-up built-in by setting pinMode() is not really the best choice.
  • If you have long wires to sensor (more than say 0.5meter), you might need to take other steps to reduce interference.
2 Likes

@bko I’m using 3 wire power/ground/data @ 4.7K res. Same way I have it on my core.
Wouldn’t an electrical problem have been showing consistent errors in all the firmware builds?

Same for me. 3 Wires, 4.7k resistor. I’m just going to throw a CRC check in my code and move on. It’s random and doesn’t persist so I’ll try three times in a single sample and if that doesn’t get good data, I’ll throw a fixed number that people can catch and do something with.

I’ll share a more tolerant ds18b20 Lib tomorrow. Not for everyone but it’ll work for me and I’m sure others.

Maybe or maybe not. It sounds like your electrical set up is pretty good. Are you staying away from the WiFi end of the chip? The RF output can cause problems too. Power supply is OK? Have you tried putting the Dallas part on +5V?

There is nothing I know of in the system firmware that changed from 0.4.4 to 0.4.5 or 0.4.6 that could even remotely account for this, but I have been surprised before.

I still think the first level answer is to discard any results with a bad CRC. If you want to dig deeper, by all means go for it. Step one in that dig for me would be to put a scope or logic analyzer on the data line and try to captured a failure.