Forum Rule: Always post complete source code & details to reproduce any issue!
Results 1 to 12 of 12

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

  1. #1
    Junior Member
    Join Date
    Dec 2020
    Posts
    6

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

    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 -127C or a fixed value 25C 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/Ardui...ary/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.
    Attached Files Attached Files

  2. #2
    Senior Member
    Join Date
    Mar 2016
    Posts
    318
    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.

  3. #3
    Junior Member
    Join Date
    Dec 2020
    Posts
    6
    Quote Originally Posted by PhilB View Post
    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

  4. #4
    Junior Member
    Join Date
    Dec 2020
    Posts
    6
    I've further reduced the complexity of the program

    please see the TemperatureMonitor7MQTTClient_crash_4.zip example

    here

    https://github.com/milesburton/Ardui...ary/issues/188

  5. #5
    Senior Member
    Join Date
    Nov 2012
    Posts
    1,568
    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

  6. #6
    Senior Member
    Join Date
    May 2015
    Location
    USA
    Posts
    845
    What options are available on a teensy to do bounds checking? Ie, what's the easiest way to find the above error?

  7. #7
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    13,704
    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.

  8. #8
    Senior Member
    Join Date
    Nov 2012
    Posts
    1,568
    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

  9. #9
    Junior Member
    Join Date
    Dec 2020
    Posts
    6
    Quote Originally Posted by el_supremo View Post
    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

  10. #10
    Junior Member
    Join Date
    Dec 2020
    Posts
    6
    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.

  11. #11
    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/Ardui...ontrol-Library

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

  12. #12
    Junior Member
    Join Date
    Dec 2020
    Posts
    6
    Quote Originally Posted by KrisKasprzak View Post
    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/Ardui...ontrol-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 by pberna; 01-05-2021 at 11:47 PM.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •