[1-wire DS18b20] How to restart the 1. wire BUS after DEVICE DISCONNNECTED

Hi ,

I have a heater control up and running using arduino Mega 256 and several digital temperature sensores from Dallas DS18b20.
All DS18b20 are connected to a 5V supply, I use 4k7 resistors and the application in generall works fine but..

...after a few days running I start receiving DEVICE DISCONNNECTED for all sensors, permanently.
After receiving the first DEVICE DISCONNNECTED the bus is some how broken and i cant read from the bus anymore.
Cutting the power supply of Arduino and perfoming a restart does solve the problem but this approach would need a monkey or similar (me) permanently located in my basement.
I can detect and count the errors but I have no idea how to "heal", reset, restart the bus or the application.

-> What I am looking for is a way to restart the 1-wire bus or to reset the state of the Bus when receiving errors.

My src:

#include <OneWire.h>
#include <DallasTemperature.h>

#define ONE_WIRE_BUS 3 		        // data wire (temperature sensors) is plugged into port 3 on the Arduino
OneWire oneWire(ONE_WIRE_BUS);         // 1 wire bus
DallasTemperature sensors(&oneWire); 	//  Pass oneWire reference to Dallas Temperature.


// this function is called to read temps

 void measureTemp(){
   
    //  --- This way of resetting the bus does not work  but here i could add some src code -----
    if (SensorErrorCount > 10)   // If i receive 10 x DEVICE DISCONNECTED do the reset
    {
      oneWire.reset();                        // function of 1-wire.h
      SensorErrorCount = 0;                 // reset counter and start waiting for DS18b20 errors
      LogGLDC("rst 1W");                    // Log error on display
      Serial.println("Reset 1 wire bus");
      delay(1000);
    }
    
   // read Mix1 Sensor temperature
    float checkTemp = 0.0;                                                   // check the returend sensor value  for -127 DEVICE DISCONNECTED
    if (sensors.isConnected(mixer1Sensor)){                             // check if sensor is available
      Serial.println("DS18b20: Sensor 1 available");
      sensors.requestTemperaturesByAddress(mixer1Sensor);       // request temperature
      delay(75);
      checkTemp = sensors.getTempC(mixer1Sensor);                // read temperature
      if(checkTemp <= 1.0){
       // error: DEVICE DISCONNECTED - once receiving this error, all read will fail
        Serial.print("there might be a error with Sensor 1: ");
        LogGLDC("error S1");
        SensorErrorCount++;                                                    // error found and counted
        Serial.println(checkTemp);
      }
      else{
        tempMix1 = checkTemp;
      }
    }
     else
    {
       // error: Sensor not available - this does not happen
       LogGLDC("S1 na");
       SensorErrorCount++;
       Serial.println("S1 not available");
    }
}

In my opinion, the application somehow fails while communicating on the 1-wire bus (some colose 220V xtalk, glitch due to relais switching,..) and thats why the bus breaks.
Any Ideas how to reset ?

br,meis

What are the values being returned when you report device disconnected? You should be checking if the value returned = -127 to determine if there was an error. Maybe it's just really cold in your basement lately? :wink:

From the commnents in the library (DallasTemperature.cpp):

// returns temperature in degrees C or DEVICE_DISCONNECTED if the
// device's scratch pad cannot be read successfully.
// the numeric value of DEVICE_DISCONNECTED is defined in
// DallasTemperature.h. It is a large negative number outside the
// operating range of the device
float DallasTemperature::getTempC(uint8_t* deviceAddress)

The definition of DEVICE_DISCONNECTED in DallasTemperature.h:

// Error Codes
#define DEVICE_DISCONNECTED -127

willnue

Thanks for the reply,

i did change the src code accordingly and the returned value is -127. Anyhow, values below 1 degrees are very unlikely, the sensors are mounted on my heat pipes. Thats why I reduced the range of returned values.

As you can see, i already added some additional delays for reading the sensors -> delay(75);
Dont know if it helps, the error occurs ~ every 3-4 days. Anny comments on improved robusteness by adding delays?
I really dont care about some delay since water temperature control is a slow process any how.

My gut feeling is that there is rather a long wires, 220 V xtalk, cats in the basement issue then a SW issue.

I was also thinking about a full reset of the arduino when facing the 1-wire error but there are some risks when using the WDT of the ATMega as far as i understood. To be honest, a full reset feels like cracking a nut with a sledgehamme.

-> I am still looking for a "soft" reset of the 1 wire bus if communication fails. The reset method of the 1-wire library does not solve the issue.

Anyone else facing similar prolems? Reading temperature values of DS18b20s fails after some time and only -127 values are received.

br,
meis

HHmmmm....

I've run DS18b20's for weeks at a time..

? Are you powering the DS18B20's with 5V? Or running parasitic mode?
? All on same I/O pin??

I'm thinking a glitch made a DS18B20 'latch up' or something. Maybe if you ran them with +5 and ground power, with a .1 uf bypass near the DS18B20(s) that would help..

Dallas Sez:
" Dallas recommends passive devices that primarily serve to protect the DS18B20 from ESD damage or a latchup state resulting from ESD."
See: Mixed-signal and digital signal processing ICs | Analog Devices

Let us know! This one will be bothering me :roll_eyes:

Hi,
and thanks for your reply.
I have a 5V supply for each sensor and all the data Linies are connected to pin 3 of my arduino.
Low pass filtering sounds like a good idea, i will add some caps close to the DS18b20.

I would really like to improve my source code towards those read errors.
-> easy to detect and it should not be that big of a problem to reset the bus.

I am currently playing around with reseting 1-wire and driving the 5V sensor supply via I/Os to be able to deactivate it.

    if (SensorErrorCount > 10)                  // ongoing bus error
    {
      
      oneWire.reset();                                   // reset 1-wire using lib function
      digitalWrite(SENSORSUPPLY, LOW);          // disable sensor supply
      // log
      LogGLDC("rst 1W");
      Serial.println("Reset 1 Wire bus");    
      
      delay(5000);
      
      digitalWrite(SENSORSUPPLY, HIGH);        // enable sensor supply
      SensorErrorCount = 0;                        // reset count
    }

br,
meis

meis:
My gut feeling is that there is rather a long wires, 220 V xtalk, cats in the basement issue then a SW issue.

Have you looked at Guidelines for Reliable Long Line 1-Wire® Networks?

I have a 5V supply for each sensor

As in, if you have 5 sensors, each one has its own 5V supply?

meis:
Dont know if it helps, the error occurs ~ every 3-4 days. Anny comments on improved robusteness by adding delays?

Shouldn't - I believe the DallasTemperature library already adds a 750ms delay on the request.

I too am wondering how long your runs are and the topology you are using to connect them ie. Star, Linear, Stubbed. FYI - My network currently consists of about 200 feet of cable split between 5 nodes on a star topology and has been working fine for months.

Also, the 5V supply for each sensor has me puzzled, you typically would just send the 5V down the line connectecting the sensors to the Arduino.

willnue

Hi,

my sensors are conected in star topology, with 5 V supply from arduino. There is a single 5V supply from arduino for all sensors, the 5 V are connected to every sensor and no sensor is running in parasite mode.

The maximum length of wire i am using is about 8 meter to measure the outside temperature.
All other wires are ~ 2 meter long. Thanks for the guidelines, I will check my network setup.
My cables are twisted 0.5 mm cables without shielding.

s1 ------ Arduino --------s2
|
|
|
|
S3

The SW error did not occure during the weekend, I am still waiting to check if my reset works.

thanks,
meis

Hi,

yesterday I did the following updates and I am now testing the setup.

1.) replaced old sensor wires with new wires normally used for telefon networks (twisted pairs and shielded)
2.) added Cap's close to sensor pins
3.) Improved error log
4.) Upgraded 5V source (max 2.5 A)
5.) Seperated 220 V supply used for switching mixers / pumps (L1) and used for 5V supply of arduino (L2) to avoid glitches
6.) Added additional delays
7.) Reduced contol loop speed (less 1-wire read operation / t)

Thanks for all the feedback!

We'll be listening for the results.

I bet it works, unless the problem is Cosmic Rays :slight_smile:

-edit- Don't laugh.. I once spent months building a Cosmic Ray tester at IBM.. hundreds of DRAM chips, being written a pattern and then read 24-7. Interestingly the problem (random fails in mainframe memory boards) was traced to alpha particle radiation from trace elements in the ceramic substrate. Silicone in between solved it.

It was NOT Cosmic Rays.

1 Like

Hi *,

after 5 days without any problems ,... it is back: DEVICE_DISCONNECTED.
I really don't get it!

My last experiment:

  • I will now replace all sensors (have 50x DS18b20 backup)
  • I will replace my Arduino Mega
    (- Activate watch dog timer for device reset // this should not be necessary)

If it fails, I will bring thermal death to all DS18b20 and go back to a PT1000 in bridge with amplifier solution.

br,
meis

Hi all,

by replacing all sensors I finally fixed my problem.
-> Most likely a single defect DS18b20 did cause the device disconnected error during runtime.

Thanks for all the help and ideas!

Conclusion: When facing similar problems(almost random device disconnected error) you should also think about replacing your sensors.

br,
meis

Anecdotal reply (no answers from me)

I can support the apparent lack of robustness of the DS18b20. I have an outdoor weather-station (yes, protected from the elements as much as possible). I have had Dallas parts fail... All of them have been variants of DS18b20 after being in service beyond the 6 month mark to a few years. (24x7 service) I can't say why they fail more than the other parts I have ( DS2423, DS2438, DS2450, DS2760 all in similar environmental conditions)

Mine are all parasitically powered except for the DS2438.