DS18B20 Dallas Temperature readings jumping high at random intervals

Are these direct readings from the sensor or are you using filtering?

The sensor will reset to 88C (ca. 190F) on power up, and this can happen when doing a long conversion and you lose power. The sensor appears on the bus, since it’s able to use parasitic power, but as soon as you try to read a temperature it will fall off the bus.

Since the onewire protocol includes crc checks, a high reading seems unlikely from a firmware problem. (I don’t know the dallas library - so not 100% sure it has crc checks implemented.)

Hi @mdma (Do you prefer Matt or Matthew?)
I rolled back to 0.4.4 and doing some testing now.
Another footnote- I’m not sure if I may have been originally running v0.4.4-rc.2-photon.bin
Would the Web IDE bump it up to v0.4.4-photon if I had 0.4.4 selected in the build dropdown a few weeks ago?

Filtering? Not sure what you mean, but these issues just started this past week. Over the past few months I would occasionally get a false high-temp (maybe once in 2 weeks), whereas now I’m getting them randomly every 5 minutes to 3 hours.

*should this conversation be moved to a different heading?

Hi again, I’m happy with mdma, Mat (one t) or Matthew, thanks for asking.

For filtering, I wonder if you filter the temperature values through a low-pass filter - it can smooth out unepxected jump. You may not need it in your application - I used it at brewpi.com to help smooth over spikes and other anomalies.

Yes, let’s move this conversation to another thread since it’s no longer about downgrading! :wink:

1 Like

(This should have appeared at the top of the thread! mea cupla --mdma)

Thanks @mdma! I didn’t know rollback wasn’t working. I didn’t think it was the cause, but as a troubleshooter, I was looking to reverse all changes back to a time when it was stable. Is it at all possible that it relates to float conversion since it seemed fine using int16_t and no decimal point for Temperature when I modified it as a temporary fix last month.
Oddly - my Core with the same set-up and firmware using sprintf ("%2.1f") does not exhibit the temperature jump. Every now and again it may miss a read and then the value is a min or max value, but this is always around 138F with the at-rest temperature around 80F

    int16_t intTemp = ((MSB << 8) | LSB); //using two's compliment 16-bit
    float celsius =   ((double)intTemp)/16.0;
    float fahrenheit = ((celsius*9.0)/5.0+31.0);  // was +32

I’ll keep you posted as I dig further.

1 Like

@MisterNetwork, I’ll test later since I have an 18B20. I’ll be testing with a locally compile latest version of develop.

Power on value is actually 85C or 0x0550 in the wierd dallas number format)
Kind of annoying they choosen a value inside the valid range for powerup

Update - so far on 0.4.4 it has been stable for the last couple of hours using

    int16_t intTemp = ((MSB << 8) | LSB); //using two's compliment 16-bit
//    float celsius =   ((double)intTemp)/16.0;
//    float fahrenheit = (( celsius*9.0)/5.0+27.0);  // was 32

     int16_t celsius =  (intTemp/16);
     int16_t fahrenheit =  ((celsius*9)/5+30);

    sprintf(cTempF, "%d", fahrenheit);

and the Particle-OneWire Lib

I’ll let it cook for a while and then I’ll try it with the published OneWire Lib to try and narrow down if it’s a Lib or firmware issue.

I posted my code here:

Hi @MisterNetwork

I looked at your code and these jumped out:

            Spark.variable("cTempF", &cTempF, STRING);
            Spark.variable("multiSwitch", multiSwitch, STRING);
            Spark.variable("multiVal", multiVal, STRING);
            Spark.variable("highTempVal", &highTempValS, STRING);    
            Spark.variable("overTempVal", &overTempValS, STRING);    
            Spark.variable("remainTime", &remainTime, INT);

None of the STRING variables should have an “&” in front of them (all of the INT variables need it). So multiSwitch and multiVal are correct but cTemp and highTempVal and overTempVal are not.

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.


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.

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

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.