Peaks on my temperature graphs

[wickedbeernut]

@Rodrigo_Cavalheiro

You won’t believe. As I put my hands in the hardware it stopped spiking. That way, I suspect some kind of bad pins connections .

Your hands likely served to ground it.

[Toro_Blanco]

Or perhaps a loose connection, that when the door opens/shuts wiggle the wires going to the board?

[kostas]

Just to share a few info about DS18B20.
As it has been already mentioned, temperature measurement is effected in two stage.
Temperature conversion
Reading of the result
When temperature conversion is not successful, reading the result always returns a +85 result (this value is hardwired into DS18B20’s logic).
This explains the rising spikes.
Main cause of unsuccessful temperature conversion is insufficient power supply, either when DS18B20 is parasite or externally powered.
I guess crc error checking is already applied into OneWire as well as DallasTemperature libraries.

[wickedbeernut]

@kostas

I guess crc error checking is already applied into OneWire as well as DallasTemperature libraries.

CRC is supported by OneWire, but I wouldn’t say it’s already applied. The application needs to invoke OneWire::crc8 to check CRC.

[distans]

@Rodrigo_Cavalheiro

You won’t believe. As I put my hands in the hardware it stopped spiking. That way, I suspect some kind of bad pins connections .
What’s weird: why would the hardware work well during night and spiking in the morning/afternoon?

“Say hello to my little friend!”

@Rodrigo_Cavalheiro

@wickedbeernut Great point. What’s not running during night: fluorescent lights, motors (it’s a industrial kitchen), some computers (6 or 7).

Isn’t there a very big noisy motor driving the cooling system?

@kostas

When temperature conversion is not successful, reading the result always returns a +85 result (this value is hardwired into DS18B20’s logic).
This explains the rising spikes.

I’m not sure about that. According to the datasheet, that’s the power-on reset value, and his spikes are only 12-15 degrees anyhow. So it doesn’t fit

Just to elaborate on my previous post and the “-127 C” error. It’s also true if the scratch pad can’t be read successfully (from DallasTemperature.cpp):

// returns temperature in degrees C or DEVICE_DISCONNECTED_C if the
// device's scratch pad cannot be read successfully.

When you have eliminated all possible EMI sources, try moving your ESP8266 a foot or two away from the board. Or learn to live with it

[Rodrigo_Cavalheiro]

@distans

Isn’t there a very big noisy motor driving the cooling system?

Actually, 3 of them, but they work at night too. So, the interference might not be from them.

[wickedbeernut]

@distans

ESP8266 a foot or two away from the board.

Bingo! I use a panel-mount waterproof enclosure the size of a large matchbox. I have a custom board which the NodeMCU plugs into, mounts to the bottom of the enclosure on standoffs. Stick the whole darn thing in the cold chamber. This is in the true spirit of IOT. Have a third cold chamber? Stick an enclosure / ESP8266 / DS18B20 in there, too. All of the devices function completely independent of one another. Less than $10 for the entire assembly.

[distans]

Don’t get me wrong, I’m all for a sound electronic environment with minimal interference from other sources. But as I wrote before, it’s $10 of hardware you’re working with. And I think it’s strange that your values only jumps 10-15 degrees and not giving you the “-127” as a real error…

If you have a florescent lamps, change the glow switch starters to those electronic versions. It fixed my problems with a black screen every time someone turned the light of in the bathroom

[kostas]

@Rodrigo_Cavalheiro
his spikes are only 12-15 degrees anyhow. So it doesn’t fit

Consider that graph values are per minute.
If you send to the server more frequently, server records the one minute average.

[wickedbeernut]

He’s sampling the temperature every 5 seconds. A spike of 12 degrees over a one-minute interval with a running average temperature of 6 degrees corresponds to one bad sample of 78 degrees,

(6 degrees x 11 samples + bad sample) / 12 samples = 12 degrees
bad sample = 78 degrees

Pretty darn close to 85 degrees.

[brazirl]

Definitely appears to be a grounding or interference issue. Look for a cold solder connection. Also, filtering bad measurements is poor practice because it hides problems. You always want your raw measurements to be correct. Just my opinion.

[wickedbeernut]

@kostas

When temperature conversion is not successful, reading the result always returns a +85 result (this value is hardwired into DS18B20’s logic).

I’d like to revisit @kostas’ assertion and my observation as it relates to a temperature of +85 degrees …

@distans

In the DallasTemperature.h you can see that a loss of communication results as these values as an “error code”:

// Error Codes
#define DEVICE_DISCONNECTED_C **-127**

and expand on @distans’ assertion and include a second observation related to a temperature of -127 degrees.

My observations are based on @kostas’ assertion that what we’re looking at in @Rodrigo_Cavalheiro’s charts are one minute averages.

@kostas

Consider that graph values are per minute.
If you send to the server more frequently, server records the one minute average.

This chart depicts a steady state temperature of 6 degrees. As is the case with @Rodrigo_Cavalheiro, the temperature is sampled once every five seconds. I’ve inserted two “temperature spikes”. One spike is -127 degrees and the other is +85 degrees,

Clearly, this isn’t what we’re seeing in @Rodrigo_Cavalheiro’s charts. However, if rather than charting each temperature sample every five seconds, what if we consider the average temperature over one minute intervals as @kostas claims? The chart looks like this …

Note the spikes. The one minute interval containing the -127 degree spike has an average value of -5.08. The one minute interval containing the +85 degree spike has an average value of 12.58. Does this look familiar? Compare this to @Rodrigo_Cavalheiro’s original chart (in orange),

In @Rodrigo_Cavalheiro’s chart, at the time of the spikes, the steady-state value is approximately 6 degress (as with my example). The one minute interval containing the first spike is damn close to -5 degrees. The one minute interval containing the second spike is damn close to 12 or 13 degrees.

Of course, if two spikes occur in the same one-minute interval, the average is roughly double,

Compare this to (in green),

Look familiar?

I think there may be some truth to the +85 and -127 theories.

[PeteKnight]

Nice work @wickedbeernut

@wickedbeernut

However, if rather than charting each temperature sample every five seconds, what if we consider the average temperature over one minute intervals as @kostas claims?

@kostas is basing his ‘claims’ on the Superchart documentation:

Superchart supports currently 2 types of granularity:

• Minute granularity - 1h , 6h , 1d ;
• Hour granularity - 1w , 1m , 3m ;

This means that minimum chart update interval is 1 minute for 1h , 6h , 1d periods. 1 hour for 1w , 1m and 3m periods. As Blynk Cloud is free to use we have a limit on how many data you can store. At the moment Blynk Cloud accepts 1 message per minute per pin. In case you send your data more frequently your values will be averaged. For example, in case you send value 10 at 12:12:05 and than again 12 at 12:12:45 as result in chart you’ll see value 11 for 12:12.

https://docs.blynk.cc/#widgets-displays-superchart

Pete.

[wickedbeernut]

So you’re suggesting, if I send,

10 at 12:12:00,
11 at 12:12:05,
12 at 12:12:10,

the result for time interval 12:12 is,

A. average(average(10,11) + 12) = 11.25

rather than my theory which assumes,

B. average(10, 11, 12) = 11

That would definitely throw a monkey wrench in my theory.

I think we can all agree, we must be looking at some sort of average temperatures. This is going to tamper the spikes. We’re not looking at the actual spike temperatures in @Rodrigo_Cavalheiro’s chart. With averaging method “A” above, the resulting average will vary depending on where the spike occurred in the one minute interval. We’re not seeing this. The spikes are very consistent. With averaging method “B”, it doesn’t matter where the spike occurs in the one minute interval. The spike will always have the same effect on the average value for the one minute interval.

@Rodrigo_Cavalheiro, you mentioned that you’re sampling the temperature every five seconds. Are you sending each sample to the server? Are you performing any averaging in your firmware?

[PeteKnight]

@wickedbeernut

So you’re suggesting, if I send,

10 at 12:12:00,
11 at 12:12:05,
12 at 12:12:10,

the result for time interval 12:12 is,

A. average(average(10,11) + 12) = 11.25

No, I think that what it’s saying is that if you send multiple values within a one minute period then they’ll be averaged. In your example of:

@wickedbeernut

10 at 12:12:00,
11 at 12:12:05,
12 at 12:12:10,

the three values would average-out to 11, as all three are sent within the 1 minute window and (10+11+12)/3 =11

Pete.

[wickedbeernut]

OK. That’s exactly what I was assuming and what my charts are based on. That implies the server maintains one minutes worth of samples (regardless of how many samples were received) in order to calculate the average.

[PeteKnight]

Yes, I’m guessing that it buffers them and averages the results once every minute then writes the result to the database and flushes the buffer.

Pete.

[wickedbeernut]

I just saw where @Erko used this code,

And then Googled it. Sure enough. 85 and -127.

[distans]

Good work by @wickedbeernut and @PeteKnight

@wickedbeernut

I just saw where @Erko used this code,

That code doesn’t make ANY sense (to me )?!

I mean, you don’t put that crap in the main loop(), it’s a recipe for disaster! And the vPin only updates if the temp reading is 85.0 OR -127.0. I don’t get it! (the complete code referred to is here)

We might be drifting away from topic… But I still believe that a +85.0 °C reading only occurs after cycling the power.

[wickedbeernut]

@distans

I just saw where @Erko used this code,

That code doesn’t make ANY sense (to me )?!

I mean, you don’t put that crap in the main loop() , it’s a recipe for disaster! And the vPin only updates if the temp reading is 85.0 OR -127.0. I don’t get it! (the complete code referred to is here)

It’s a do-while loop. You read and continue to re-read the temperature until it returns a value other than 85 or -127.

I’m not advocating that you apply this logic in the loop() routine with Blynk. Or that you even apply this logic at all. I’m simply pointing out this logic is used all over the Internet to address the problem @Rodrigo_Cavalheiro is seeing. It validates the theories around 85 and -127.

We might be drifting away from topic… But I still believe that a +85.0 °C reading only occurs after cycling the power.

(edit) Let me re-state this …

I’m 99% convinced the DS18B20 is periodically returning both 85 and -127. It may well be that @Rodrigo_Cavalheiro is having “power problems” and the DS18B20 is recycling.