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 ?
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?
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:
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.
? 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..
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
  }
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.
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.
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)
-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.
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.