Avoid spikes in temperature data #9
Comments
|
CRC is already checked when parsing the file. A failed CRC check should result in a class ParserTest extends Specification {
"Fails to extract temperature with failed CRC check" >> {
val output =
"""|72 01 4b 46 7f ff 0e 10 57 : crc=57 NO
|72 01 4b 46 7f ff 0e 10 57 t=23125
""".stripMargin
Parser.parse(output) must be_-\/.like {
case error: CrcFailure => ok
}
}
}case class RecordTemperature(host: Host, input: TemperatureReader, output: TemperatureWriter, error: PrintStream = System.err) extends Runnable {
def run(): Unit = {
input.read.fold(error.println, temperatures => {
output.write(Measurement(host, now(), temperatures)).leftMap(error.println)
})
}
}case class CrcFailure() extends Error("CRC failure, this could be caused by a physical interruption of signal due to shorts, a newly arriving 1-Wire device issuing a 'presence pulse' or gremlins.") |
|
Not quite as high as the above but the datasheet says 85 is a starting temp. Probably worth filtering out 85 degrees.
|
…t will ignore spikes in temperatures
|
If enabled, ignore temperatures with a +/-25% fluctuation. Enable and configure by adding |
|
I'm adding, as requested, an image of a spike with the corresponding csv file. The spike was at 23:09, but due to the time code difference (I suppose) on the csv file it shows at 22:09. |
|
One more, and this is weirder. I have two machines, a server named PiZero, and a client named PiOld. Until now, only PiOld had been subject to the spikes, so I installed the "temporary fix" as described (both are running the latest version). The server had never shown any spike, so I did not do the fix there. Now I got this. A spike on BOTH machines at exactly the same time. But on the server (which doesn't have the fix) the reading went down to zero. On the client, ad EXACTLY the same frame, it went down only about 15% (so it's not wrong that the fix didn't catch it). Now I'll apply the fix to the server too, but how can it be that 4 different sensors all had the problem on two separate machine at exactly the same moment? Must be something server-side...
Cristian |
|
Sorry, I should have made it clearer: the (possible) fix only runs on the server. The server stores the values and so the fix works by looking at previous values that are received to work out the % difference, discarding if it's too big. I didn't consider not sending, if the same is true on the client. Not sure if it's meaningful, but I see similar spikes across a spread of machines at about the same time. I have like 5 running and anywhere between 1 and all 5 may spike at the same time. That's why I kind of started thinking about environmental problems (like maybe my microwave freaking the wifi signal out). |
|
Ah ok, I thought the value would just be discarded without being sent. |
|
You can always lower the threshold to say 15% to try and catch the minor spikes. You might need to experiment a little. Good points. I'm struggling to debug it atm so reaching a little 😉 |
|
I'm assuming that in your most recent example, there's nothing in the log at around 19/01/2018 07:56 ? |
|
Just thinking... To debug it, maybe you could set a low threshold (like 5%) and when a spike occurs, the machine could also log somewhere the actual scratchpad from the sensor, and any intermediate processing that was done on that data? I don't believe the sensors actually read a spike, so something must happen along the path that the raw data follows, so logging all intermediate points might show where the problem is... |
|
👍 |
|
Nothing on the log around that time. I have many errors at other times, mainly "CRC error" and "error in RequestLoop()"... By the way, I just had another spike. Do you want me to keep sending screenshots and CSVs? |
|
Curious about the CRC error, can you share? The Maybe hold on the CSVs for a bit. |
|
Here's the current log from the server. There have been spikes at 7:55, 10:03 and 11:41 (though the recorded times might be off by an hour due to the time zone difference). |
|
Not sure if this is meaningful, but spikes here tend to happen when I'm doing something else with the pi (mainly compiling). I've left it alone for about 10 hours, and had no spike whatsoever; after coming home I updated the source and recompiled, and got like 10 spikes in an hour... Cristian |
|
OK, with the help of the new document, I installed the "temporary fix". Installation was successful, as indicated by the log: But I still see spikes. Even major ones, up to above 400 degrees.
|
|
I just realized that every spike that I've ever seen, only ever affects one single frame, i.e. one reading is wrong, and is surrounded on both sides by good values. So, since the "temporary fix" does not appear to be working, at least for me, have you ever thought of checking the readings, and discard any reading that is different from the surrounding ones, if the ones before and after show the same value (or almost the same value)? |
|
I was experimenting with the fix (since I still get spikes occasionally) and I thought of something. |
|
Thanks for the thoughts. It's very difficult to gauge cause and effect here. I'm planning to tidy a few other things up just in case they are causing problems (like making sure no exceptions could be thrown causing weird behaviour), then I think I'm going to log every measurement and cross reference that to what's in the RRD database. That way I can see if the cause is with RRD. I'm also thinking of changing the way its logged to RRD as there's a slim chance more clients could increase the odds of spikes... not sure yet. To answer your question though, everything is in centigrade and the comparison is between the last value and current. You can see it in the CSV and the % difference. |
…it out before switching to a branch)
|
Closing for now as recent work seems to have fixed this... at least, I haven't seen it for a while. If I see it again or it's reported, I'll reopen. |
I'm not sure why it started happening but I'm seeing extreme spikes in temperature data.
Potentially ignore volitile readings or check the CRC when reading (as suggested in the Arduino forum).
The text was updated successfully, but these errors were encountered: