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.
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:
- 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])
- compare the 3 readings and validate or invalidate them if they are > or < than 5 degrees apart.
- check the readings for consecutive 32 or 185 Fahrenheit values (could mean that the data pin is shorted to GND or VCC)
- if any sensors have readings that are invalid, take all the readings again until they pass the test
- 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.
- add a timeout feature (depends on sensor resolution you’re using) just in case something hangs
- make sure this entire routine is encased in SINGLE_THREADED_BLOCK() because the bit-bang of the DS18B20 is timing-sensitive.
- 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.
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.
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
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.