problem monitoring Dalas temp sensor

[BartSr]

Hi!

I am having two sensors hooked up to input of ESP Easy (NodeMCU V3) incl pull-up resistor.
I can read the temperatures but sometimes the first sensor gives value "nan".
Next time the 2nd does same. But mostly they both show right values.
What might be the reason? Bad NodeMCU? Bad sensors? Bad wiring?

Hope anywone has a suggestion.

Kind regards
-Bart

[mrwee]

Which kind of cable are you using, and how long?
Are you using parasite power / 3.3V /5V?
Which size is the resistor?
Are the sensors genuine?

[TD-er]

That last question about "genuine" sensors may seem a bit far fetched, but it appears to be a real problem.
Especially when using > 1 sensor, which is kind of the main use case for 1wire sensors in the first place.

Still you can try to work around this by making sure the sensors are not called at the same time.
One simple trick is to slightly offset the "interval" timer in the task settings.
For example you want to read them every 60 seconds. So set one to 60 seconds and the other to 61 seconds.
Then only every hour they will be read at the same second interval.

[Ath]

One simple trick is to slightly offset the "interval" timer in the task settings.
For example you want to read them every 60 seconds. So set one to 60 seconds and the other to 61 seconds.

It is a good practice to set those 'interfering' read intervals to prime numbers, so in this case 59 and 61 sound feasible.
You can find the first couple of prime numbers here: http://mathforum.org/dr.math/faq/faq.prime.num.html (or use Google)

[TD-er]

True, that does increase the periodicity quite a lot.
60 & 61 sec interval does "collide" about every 60 intervals.
59 & 61 sec interval does "collide" about every 59*61 interval.

[BartSr]

Replies to mrwee:

Using normal 4x0.5 cable. No parasite supply 3,3V and resistor is 3K3.
These are the cheap onces from China.
Have also a number (15 off in one string) of them in use with Arduino and Arduino sketch. Here I havenot seen any faulty values. Same supplies and resistor.

Reply on other answers: I set the delay as adviced to 59 and 61 secs. Will report back about results.

BTW: is there a way to save the log-file into txt file?


Best regards
-Bart

[ThomasB]

Maybe there is more to the story behind the Dallas NAN values. The finger is usually pointed to sketchy (non-genuine) DS18B20 chips from China. But maybe it's not always the chips' fault?

For example, I noticed in the P004 and P080 Dallas Plugins that the ESP8266's interrupts remain enabled. I expected that they would be disabled when reading/writing the one-wire data bits. It seems to me that leaving the interrupts enabled might corrupt the chip's time critical data I/O operations.

Perhaps this would explain some of the random NAN values?

- Thomas

[TD-er]

I do agree the P004 plugin may need some TLC, as we've had some 'fixes' in the past that were way too timing critical if you ask me.

[ThomasB]

Yup, some TLC might be needed.

I also found that the Plugin_004_DS_write_bit() does not follow the DS18B20 datasheet when it writes a logic high bit. The datasheet says that the bus should use the resistor pullup for logic high states. But the write_bit function is **driving** the high state using digitalWrite(). Similar in purpose, but not the exactly the same thing. Will this make a difference? Maybe, maybe not.

DS18B20 Write Bit Summary

ds18b20.png (202.42 KiB) Viewed 13038 times

Overall, I have a feeling that the random instances of NAN data would be reduced by code tweaks and hugs.

- Thomas

[mrwee]

Seems like the problem could have several root causes. I know for a fact that when I, years ago, swapped DS18S20 clones for geninue sensors, many of my sensor reading problem vanished. But if there's issues in the plugin, that's perhaps easier to fix, if someone knows how.

[TD-er]

I've enough experience with (digital) hardware + software to know the issues are often not "digital" or "discrete".
It is often more like analog.
A bit of this AND a bit of that. (bit being not a bit here )

About "driving" vs. "pulling".
It depends on how the GPIO's are connected internally.
Quite often a GPIO pin configured as output is a transistor pulling to GND and connected via a pull-up resistor to Vcc.
So adding an extra pull-up resistor then makes the signal stronger.
However the GPIOs on the ESP do seem to be able to source enough to power a LED, so I don't think it is that far off from using an external pull-up resistor.
What does make a difference is that the wire to the sensors (especially if you're using multiple sensors) does have its own capacitance.
So a lower current pulling "up" may become a rounded edge in the signal.
This does effectively make the time a pulse is "high" shorter.
When considering "fake" vs. "genuine" Dallas sensors, there may be a difference in capacitance of the sensor, the voltage level at which a signal is considered "high" and maybe also some difference in hysteresis.
Each of those parameters does have a negative effect on reliability, so it may differ per batch, or "brand" of fake ones.

I do believe Dallas does have a good quality control, which should result in smaller tolerances and thus a more reliable product.
However, if our code was perfect, then also the "fake" ones would work just fine. (although there are numerous reports online that some "fake" Dallas sensors do not work when used with > 3 on the same bus)

This means by improving our own code, we can probably make it more reliable regardless of using "fake" or "genuine" sensors.
And for sure when looking at the Dallas code, my code smell senses are tingling.

[BartSr]

Hi,

Thanks for all your insights!
Last 24 hours I havenot spotted any NaN value since I modified the delay to 59 and 61 seconds as suggested.
So it seems this solved my problem. If the NaN values will return I come back to you.
Anyway thanks for now.

KR
-BartSr