Problem with DS18B20 sensor

Hello,

I have the problem that the DS18B20 sensors occasionally display -127 at runtime. I don’t poll the sensors cyclically.

I call the sensors in a FOR loop via “getTempC” + address. Even with a delay of 200ms after each call.

Based on the BIT resolution of 10Bit, I also note the processing time that is needed for this sensor.

In other words, with 3x sensors I even wait three times the processing time from the sensor before the values are called up again from the DS18B20.

What does it mean that these incorrect values occur at runtime. ?

greeting
MacToolz

This topic has been split from a much older one

Please do not hijack topics

Please do an auto-format your code and paste it into your reply with code tags. If you do not understand this, do not post your code incorrectly, ask for further help.

Hi,

this is a part from my project.

// ##################################################################################################################################
/*
 * Ruft die Temperaturen anhand der HArdware Adressen ab
 * Sensor: Messung triggern und wenn fertig Temperatur auslesen
*/
void FN_getTemperature()  
{
  unsigned long cycleTime     = 0;  // Temporäre Zwischenvariabel, wird zur Laufzeit überschrieben ...
  unsigned long actCycleTime  = 0;  //
  uint8_t   i = 0;          // SCHLEIFENZÄHLER ...
  
  // PLAUSI PRÜFUNG ob Geräte angelegt wurden ...
  if (indizesDataIO != false)
  {  
    // Zwischenrechnungen ...
    cycleTime     = millis();   // Aktualisierungszeit ...
    actCycleTime  = sensorTriggerZeit + settings::OFFSET_TIME_TEMP_SENS + settings::CYCLE_TIME_TEMP_SENS;
    
    if ((sensorTriggered == true) && (cycleTime >= actCycleTime))  // bei hoechster Aufloesung benoetigt der DS18B ~750 ms bis der Wert gelesen werden kann
    {    
      Serial.printf("------------------- FN_getTemperature --------------------------------------------------------------------\n");       
      Serial.printf("FN_getTemperature : Anzahl Temp.Sens : %d \n" , arPdtDeviceList.iDevCnt);     // PRINTAUSGABE ...
      Serial.printf("FN_getTemperature : Anzahl Temp.Sens : %d \n" , arPdtDeviceList.iDevCnt);     // PRINTAUSGABE ...      
      
      // SCHLEIFEN DURCHLAUFEN UND TEMPERATUREN ABRUFEN ...
      for (i = 0; i < arPdtDeviceList.iDevCnt; i++) 
      {  
        arPdtDeviceList.DEV[i].ACT_TEMP = DS18B20.getTempC(arPdtDeviceList.DEV[i].HW_TEMP_ADRESS);  // Temperatur in globaler Var ablegen                             
        delay(settings::delayTimeGetTempC);
                
        Serial.printf("FN_getTemperature : Addresse : ");     // PRINTAUSGABE ...        
        Serial.printf("0x%02x", arPdtDeviceList.DEV[i].HW_TEMP_ADRESS);       
        Serial.printf(" : Temperature : %f \n" , arPdtDeviceList.DEV[i].ACT_TEMP);     // PRINTAUSGABE ...
      }  

      sensorTriggered   = false;   
      Serial.printf("------------------------------------------------------------------------------------------------------\n");                    
    }    
  }
  else
    FN_SetErrorGotToSetup ("FN_getTemperature", ERR_INDIZE, _func_SETUP);         
}
// ##################################################################################################################################

Hi,
Welcome to the forum.

Have you written your code in stages?
If so where did you come across this problem?
What library are you using?

Have you got code that just reads one of the sensors and prints it to the serial monitor.

If not, then this would be a good place to start.
Have you got the 4K7 resistor between the signal wire and 5V?

Can you please post a circuit diagram?

Thanks… Tom… :grinning: :+1: :coffee: :australia:

if you get valid values most of the time and values -127 only from time to time the reason might be a wiring that rounds the signal too much.
Onewire-busses should be ideally on line with small stubs to the sensors. Even with such a topology the signal can be rounded too much.
In these cases a lower pull-up-resistor in the range of 2 kOhms will help.

So how does your wiring look like? Length of the wires? line-topology or star-topology?

best regards Stefan

Hi,

the wire length from DS18B20 there are 50cm. The sensors are connected as a star topology.
I ask how I can connect the OneWireBus differently?

I use the whole thing on a WEMOS D1, with a USB interface

I apply the sensor line to 3.3V.

I have already used a 2K Ohm resistor.

I use the following LIBs

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

I read out all the sensors with a small test example. The same problem here too. After a certain time, the -127 keeps appearing as a value.

A friend has the same problem with his own source code, only the whole thing on a NodeMCU.

What is absolutely strange is that if the Füherl do not change their temperature, then the error value -127 does not come.

If I take the feelers in my hand, the -127 comes after a very short time after a few seconds.

I have also tested other sensors.

What can I still change somehow, or try, etc. Unfortunately, I can’t find the problem.

greeting

Hi,
Have you just tried ONE sensor on its own, to see if the problem occurs?

Can you post some code that we can run that has the problem?

Füherl == sensor ???

Tom… :grinning: :+1: :coffee: :australia:

Hi,
This might help explain.
https://www.maximintegrated.com/en/design/technical-documents/tutorials/1/148.html

Precautions with Star Topologies
Testing has shown that unswitched star-type network topologies
 (i.e., those with several branches
 diverging at the master) are the most difficult to make
 reliable. 
 The junction of various branches presents highly mismatched
 impedances; 
 reflections from the end of one branch can travel distances
 equal to nearly the weight of the network 
 (rather than the radius) and cause data errors. 
 For this reason, the unswitched star topology is not 
 recommended, and no guarantees can be made about its 
 performance.

Tom… :grinning: :+1: :coffee: :australia:

Hi,

so first of all, it is always a star line. And the master is always the focus or star. The point here is to what extent impedances appear over the different cable lengths.

Good shouldn’t be the topic because I wrote that my sensors are straight with a length of 50cm.

I will then reveal my entire source code and then see how far others can work in to understand what is going on.

Thanks …

greeting

deleted …

Hi,
Thanks for your code.
I can see you ae doing a lot, possibly trying to make a generic DS18B20 system, that adapts to different numbers of devices.

But, the fact that other codes do the same thing,
Can you please post your SIMPLE code that reads and outputs and posts to Serial.print.

If all cable lengths are star, when a request to a specific sensor goes out over all star wires.
While the senor is responding, the master receives that signal as well as the reflected request from the end of the other cables.
The fact that they are all of equal length or not is not the problem.
That is the way I see it.(But correct me if anyone sees a fault in the logic.)

Have you looked at this link, where it has a code for ESP32 and multiple DS18B20.

Is there a reason for star connection?

Tom… :grinning: :+1: :coffee: :australia:

Hi,

So I tested the same structure / wiring with the sketch from one of your links. In fact, all sensors work even if the waiting time is not set to 5 seconds.

Still, I don’t understand where the problem lies.
I use the same methods to read the sensors.

I have the feeling that the microcontroller cannot handle it. Which I can’t imagine, because the program itself is still small, without MQTT, web server etc.

I dont see my problem.

greeting

Hi,
Why a star connection?

So the Random Nerd worked with no problems?

Tom… :grinning: :+1: :coffee: :australia:

Hi,

ok then i don’t understand. Then please tell me what a OneWireBus should look like. A different wiring as I have built it is not possible for my understanding.

Yes, the NErd program works.

Again to the value. No temperature changes. There are no mistakes. If I take the sensor in my hand, so that the values change, the error value comes to -127.

greeting

Hi,

Then I would be working with that code to develop my own, testing when each major change is made.

Top diag is star, bottom diag is daisy chain.

Tom… :grinning: :+1: :coffee: :australia:

Hi,

yes moment. The OneWireBus only works as a star wiring.
The picture below is a parallel connection.

I just have no explanation as to why the program doesn’t work that way.
As I said, if there is a change on the sensor, the error value -127 appears shortly afterwards.

Strange, or I’m operationally blind.

greeting

Hi,
Where did you get the OneWire Library from and its documentation?
Any reason why you didn’t use Wire.h library and the code from Nerd?

Tom… :grinning: :+1: :coffee: :australia:

Hi,

uh like now. Both projects have the same OneWire.h LIB.
Or do I have tomatoes on my eyes :slight_smile:

I got the lib from the library manager.

greeting

Random Nerd Tutorials says that

In case the sensor is not able to get a valid reading, it returns -127.

From author’s comments under the tutorial:

That usually means that there’s some issue with the wiring or power.

No more information was found on this issue.
Check your breadboard, it sometimes has weak contacts.