DS18B20 + Photon Odd Temp Spikes

I am taking readings about once every 15 seconds right now. Did you see a difference in the Dallas library from the OneWire?

I haven't really tested the differences between different DS18B20 libraries.

Got it. I’ll play around with the “spike mitigation” code and see if I can just know them out of the reading like you doing!

Thanks Again!

1 Like

You want to make sure whichever Library you are using validates the CRC of the data. Sometimes you get a bad reading with a bad CRC.

2 Likes

I am looking at my Arduino code and I am using the Dallas library. Unfortunately that does not seem to be available as a working version within the WebIDE for Particle. I guess I will try a different IDE.

If you don’t mind me asking, waht IDE do you use for your Particle boards?

Yes it is.

There is some bug according to the forum here. When you try to compile it calls …/OneWire/OneWire as opposed to just OneWire.

So you cannot do it on the WebIDE since you cannot modify the library.

That is why I was asking what you were using as your IDE. I use the Arduino IDE for everything related to the the boards and PyCharm for all of my Python stuff.

I guess I have to download their desktop IDE to be able to manage my own libraries…

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

I use po-util within Atom for my IDE.

My fork of the dallas library works well in po-util.

You could get it to work in the official Particle desktop IDE.

Ah…got it…

YEah, I am trying the Particle workbench plugin for Visual Studio Code right now, never used VSC before so not sure how much (if at all) I will like it.

I thought the WebIDE was pretty cool until I hit that Library snag. :slight_smile:

The "old" desktop IDE is Atom based and still works pretty well. (Cloud compilation only though.)

I might give that a try as well and see how well it works. According to the Particle.io website they are going to stop using that and go with Visual Studio Code so I downloaded it and I am playing around with it. Seems to run pretty good under Linux for a M$ product…

Since you’re on Linux I would recommend po-util because of how smooth the installation is and because it does all compiling locally.

Po-util can be used from within terminal, Atom, or even Visual Studio Code.

I use this library
https://build.particle.io/libs/DS18B20/0.1.8/tab/example/ds18b20_SingleDrop.ino

The example also shows how to use the CRC check.

4 Likes

Thanks. The code that I am using already does a full CRC check:

ROM = 28 8F DF 6A 1F 13 1 98
  Chip = DS18B20
  Data = 1 91 1 4B 46 7F FF C 10 70  CRC=70
  Temperature = 25.06 Celsius, 77.11 Fahrenheit

But even with the CRC enabled and returning good, I still get spikes for no reason:

ROM = 28 8F DF 6A 1F 13 1 98
  Chip = DS18B20
  Data = 1 91 1 4B 46 7F FF C 10 70  CRC=70
  Temperature = 25.06 Celsius, 77.11 Fahrenheit
No more addresses.

ROM = 28 8F DF 6A 1F 13 1 98
  Chip = DS18B20
  Data = 1 D1 1 4B 46 7F FF C 12 70  CRC=85
  Temperature = 29.06 Celsius, 84.31 Fahrenheit
No more addresses.

ROM = 28 8F DF 6A 1F 13 1 98
  Chip = DS18B20
  Data = 1 91 1 4B 46 7F FF C 10 70  CRC=70
  Temperature = 25.06 Celsius, 77.11 Fahrenheit
No more addresses.

And more drastic:

ROM = 28 8F DF 6A 1F 13 1 98
  Chip = DS18B20
  Data = 1 91 1 4B 46 7F FF C 10 70  CRC=70
  Temperature = 25.06 Celsius, 77.11 Fahrenheit
No more addresses.

ROM = 28 8F DF 6A 1F 13 1 98
  Chip = DS18B20
  Data = 1 95 81 4B 46 7F FF C 10 70  CRC=F2
  Temperature = -2022.69 Celsius, -3608.84 Fahrenheit
No more addresses.

No more addresses.

ROM = 28 8F DF 6A 1F 13 1 98
  Chip = DS18B20
  Data = 1 91 3 4B 46 7F FF C 10 70  CRC=A
  Temperature = 57.06 Celsius, 134.71 Fahrenheit
No more addresses.

ROM = 28 8F DF 6A 1F 13 1 98
  Chip = DS18B20
  Data = 1 91 3 4B 46 7F FF C 10 70  CRC=A
  Temperature = 57.06 Celsius, 134.71 Fahrenheit
No more addresses.

ROM = 28 8F DF 6A 1F 13 1 98
  Chip = DS18B20
  Data = 1 90 1 4B 46 7F FF C 10 33  CRC=33
  Temperature = 25.00 Celsius, 77.00 Fahrenheit
No more addresses.

All of which passed a CRC check so I don’t think it is a CRC issue.

While I don’t have an answer as to what’s causing these spikes, I use an error-checking routine that I wrote in my temperature data acquisition, which detects these anomalies and like @nrobinson2000, I rule them out. I’ve used many DS18B20’s with a few different ATmega chips and never had any of these spikes. I’m guessing that there’s something funny happening in the 1-wire protocol between the photon and the DS18B20’s that makes these intermittent spikes occur. Relying on only the CRC to get rid of these spikes is clearly not enough based on your findings. I think you need your own error checking routine. For example, my routine polls all sensors 3 times consecutively, and if any of the readings are too far from the others (suggesting an error), then the Photon will try again until it finds a good reading on all sensors. It’s important to use a timeout feature just in case your program hangs in the function. I also power the DS18B20’s with 5V and use 4.7k resistor pullups.

2 Likes

Tommy_Boy -

Thank you. I am beginning to see the same thing and I am working on a bit of code to correct the situation:

/**
 * validate that the provided temperature is within acceptable bounds.
 */
boolean temperature_in_range(float temp)
{
  // Only accept the reading if it's within a desired range.
  float minimumTemp = -40.0;
  float maximumTemp = 125.0;

  return temp > minimumTemp && temp < maximumTemp;
}

I do, however, like your idea, do you have your code up somewhere where I could take a look…?

My error-checking routine is very long, and because I use it in a couple commercial products, I don’t have it posted anywhere. I’ll summarize it here in pseudo-code though:

  1. grab 3 consecutive readings from all sensors and store them in a 2d array (if using 3 sensors, then something like… float values[3][3])
  2. compare the 3 readings and validate or invalidate them if they are > or < than 5 degrees apart.
  3. check the readings for consecutive 32 or 185 Fahrenheit values (could mean that the data pin is shorted to GND or VCC)
  4. if any sensors have readings that are invalid, take all the readings again until they pass the test
  5. if any readings are invalid after 10 cycles, then set a boolean flag to notify the application. its very unusual for this to ever occur as I’ve found this error-check routine to completely solve this issue for me even with very long wire runs.
  6. add a timeout feature (depends on sensor resolution you’re using) just in case something hangs
  7. make sure this entire routine is encased in SINGLE_THREADED_BLOCK() because the bit-bang of the DS18B20 is timing-sensitive.
  8. add Particle.process() at the end of every loop of this routine so things don’t pop offline in case a sensor fails. if you’re using 750ms resolution, then this loop can take almost 2.5 seconds just to take 3 readings from all sensors. if it runs 10 times because of a failed sensor, then it will take 25 seconds. if your application can afford the resolution reduction, use the 375ms setting so things get sped up.

If you’re still having problems after using something like this, you can always set up an ATtiny85 or ATmega328 as your data acquisition front end and communicate with them over I2C so the Photon can grab all the sensor data. Like I mentioned before, I’ve found that the AVR chips don’t have the same symptoms that the Photon does with the DS18B20’s. Maybe that has something to do with the 5V tolerance of the GPIO pins on the Photon where the AVR chips’ high input maximum is VDD + 0.5V. Also, since the Photon does not have a hardware watchdog, they also serve as an external watchdog because they regularly handshake over I2C.

Hope that’s all helpful. If you need further assistance or you get stuck, happy to help guide you.

3 Likes

Thanks! Great information.

I rewrote my code using the ideas (and libraries) from code I did for some Moteinos (arduino clones) and that took care of the spikes. Not sure what was causing them before, but the problem has resolved itself now!

I like your idea, I think I will poke around and see about implementing your idea about the consecutive readings. For now, it seems the code and/or library change did the trick.

https://go.particle.io/shared_apps/5bc0cee357f8280d92000a60

2 Likes

And here all this time I’ve thought this anomaly was something I did wrong in the code for my fish tank sensor gizmo! Great discussion…

ParticleD

1 Like

I have no scientific data to back this up, but perhaps it has something to do with the exact timing within the Photon. I usually use a 16MHz crystal with the ATmega328 with the DS18B20’s, which is a very precise timing circuit. Just another thought.