DallasTemperature lib (DS18B20 1wire) fails when interact with UDP stack

pberna

Member
Dear Developer

I've notice, using DallasTemperature lib (DS18B20 temperature sensor ) that function ds.getTempCByIndex() which at a lower level uses 1wire stack fails and return -127°C or a fixed value 25°C when the it interacts with the UDP stack. It is not clear if the problem is the DallasSensor library or in the 1Wire lib or even in the ESP 32 Arduino lib, so I would like to post the problem even here.

All details have been posted here

https://github.com/milesburton/Arduino-Temperature-Control-Library/issues/188

I was able to simplify the program at minimum to easily reproduce the problem with the reduced code example

TemperatureMonitor7MQTTClient_crash_2.zip

if you set EnableRemoteSensor to "true" the local sensor reading is wrong (now it returns to a fixed value even if the temperature change), while if you set it false the temperature returns correctly. If you need a NINA W102 board for free I can send it to you for the testing.
 

Attachments

  • TemperatureMonitor7MQTTClient_crash_2.zip
    3.8 KB · Views: 109
This sensor is very sensitive to the pull-up value. You should probably start there. I had one that never did work with a T4.0 but would with a T2.0. I later managed to kill the sensor and the replacement worked mostly fine with the same T4.0 but I would sometimes return the dreaded -127C error. Tweaking the pullup seemed to eliminate the problem. iirc I used 4K to start and then a 10K pot. Don't remember the optimal value.
 
This sensor is very sensitive to the pull-up value. You should probably start there. I had one that never did work with a T4.0 but would with a T2.0. I later managed to kill the sensor and the replacement worked mostly fine with the same T4.0 but I would sometimes return the dreaded -127C error. Tweaking the pullup seemed to eliminate the problem. iirc I used 4K to start and then a 10K pot. Don't remember the optimal value.

Sorry but it is clearly a software problem not an hw problem
 
On the github site you say:
Just changing the order of the include files the result (local temperature measurement) dramatically change
To me, this is a classic indication that your code is writing over the end of an array or in some other way clobbering ram. Changing the order of the include files changes the order in which the compiler will allocate arrays and variables in ram which in turn changes the symptoms of the bug.

and in this thread you say:
Sorry but it is clearly a software problem not an hw problem
I agree completely, but you are wholly focussed on a symptom rather than finding the cause. It is a bug in your code.

Pete
 
What options are available on a teensy to do bounds checking? Ie, what's the easiest way to find the above error?
 
Not aware of anything inbuilt - note below about GDB debugger.

It would be custom based on the code at hand.

perhaps : Do a review of the code looking that all is correct as intended - making note of any vulnerable elements and suspect areas that could be abusing them.

Put in some prints asserting those expectations are met - verifying the indexes involved. Perhaps extend the arrays and put a known value there and code checks for that value being correct and stopping when something over writes it, if that happens.

The is a GDB thread ( Using-GDB-with-Teensy-without-hardware-debugger-first-Beta ) and working debugger setup that when configured can break and do stack call traces and other typical things. Knowing what or where the problem may reside that might help with getting to the bottom of it.
 
Having dug through the DallasTemperature library again, I see that if getTempCByIndex returns -127, it is an error indication which means that the specified device did not respond. You should look for and handle this error.

I also note that there is a bug lurking in your use of the Temperatures array. You declare it to hold a maximum of 10 (local) temperature sensors. But you also use it to store a reading from the remote sensor too which means that if you happen to have 10 real local DS18B20, the reference to the remote sensor in this array will be off the end of the array. It is also possible that you have got the indices muddled when referencing the array for local vs remote temperatures. I think you would be better off to have a separate variable (or array) for the external sensor(s) so that there's no room for confusion over which you are accessing.

Pete
 
Having dug through the DallasTemperature library again, I see that if getTempCByIndex returns -127, it is an error indication which means that the specified device did not respond. You should look for and handle this error.

I also note that there is a bug lurking in your use of the Temperatures array. You declare it to hold a maximum of 10 (local) temperature sensors. But you also use it to store a reading from the remote sensor too which means that if you happen to have 10 real local DS18B20, the reference to the remote sensor in this array will be off the end of the array. It is also possible that you have got the indices muddled when referencing the array for local vs remote temperatures. I think you would be better off to have a separate variable (or array) for the external sensor(s) so that there's no room for confusion over which you are accessing.

Pete

Hi Pete

There are no bug in the code. The number of remote sensor is 1 as is 1 the number of the local temperature sensor. The idea is to create a single Temperatures sensor to create e uniform data structure for all sensor.

I've notice also that DallasTemperatre ASYNC read temperature approach to measure the temperature is very sensitive and become unstable if the complexity of the program increase (there are problems also if I don't include UDP stack), however SYNC reading temperature approach has also problems (less) if the complexity of the program increase.

Are you able to test my last examples TemperatureMonitor7MQTTClient_crash_4.zip just to confirm the problem ?


Is not clear for me how the onWire lib manages the onWire bus timing. I've understood that the timing are managed by software, but are they effected by the call back length functions or by interrupt functions ?

Thanks
 
I someone has the possibility to debug the TemperatureMonitor7MQTTClient_crash_4.zip test example I can send hiom a NINA board for free. Unfortunately I'm not able to use the GDB debugger.
 
I use these sensors as well and found only 4K7 pullups work, not sure what you are using. I've used on ESP-32.

I also have switched to this lib linked below--as I had issues with the lib you use.

https://github.com/milesburton/Arduino-Temperature-Control-Library

you will need
#include <OneWire.h> as well.


I'm using 4.3Kohm pul-up, but I'm using the full VCC+GND+Data 3 pins configuration. I'm using NINA B102 board (ESP32 based).
Did yoo find similar problems before switching to the lib you suggested ?
 
Last edited:
Back
Top