18B20: blocking time to time

[loraraspi91]

I use your library to read periodically the temperature with a 18B20. its works fine but after some time (few hours) the reading is block and I need to reset the 18B20 by calling a reset on the OneWire Bus: _wire->reset() to be able to restart and to read again the temperature.

I think it could be a good idea to add a new "Reset" function, so we can call it to reset time to time the temperature device to prevent possible blocking.

[milesburton]

Could you explain a little further? Of an address registers a certain metric it would automatically reset?

…

On Wed, 19 Oct 2022 at 20:11, loraraspi91 ***@***.***> wrote: I use your library to read periodically the temperature with a 18B20. its works fine but after some time (few hours) the reading is block and I need to reset the 18B20 by calling a reset on the OneWire Bus: _wire->reset() to be able to restart and to read again the temperature. I think it could be a good idea to add a new "Reset" function, so we can call it to reset time to time the temperature device to prevent possible blocking. — Reply to this email directly, view it on GitHub <#230>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAJGHM3KE4G2BTD7KE5HMPDWEBBWFANCNFSM6AAAAAARJNRSYI> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.*** com>

[loraraspi91]

I have a peridioc reading temperature on my ESP32 do this :
while (1) {
vTaskDelay(5000/ portTICK_PERIOD_MS);
sensors.begin();
sensors.requestTemperatures();
tmp = sensors.getTempCByIndex(0);
esp_task_wdt_reset();
}

for your information: DallasTemperature sensors(&oneWire);

And for unknown reason, the reading is blocking (the watchdog is activate after 40 seconds), so I need to kill the task, reset the device (_wire->reset()) and restart the task to be able to read again the temperature of my 18B20 device.

[Frans412]

The program in which this sensor is used keeps crashing.

In a small test setup, I removed various connections one by one several times, including the pullup resistor. The program may then crash and become impossible to restart. Only a reset made the program start again.

What I did do is to place the pullup resistor near the sensor. This was located on the circuit board near the processor (arduino nano). There is a 1 meter cable between them. By placing the pullup resistor near the sensor, I have closed the cable with low impedance, and therefore made it less susceptible to interference, I hope.
I have not yet been able to do a long-term test.

But in general I find it strange that a library of a sensor can block the program.

Does anyone have a solution?
Frans412

[RobTillaart]

The program in which this sensor is used keeps crashing.

I cannot see your code(sketch), your hardware setup (board, parasite power, power supply? how many sensors?) or environment (noise? shielded wires?) so it is difficult to investigate the cause.

As this is one of the most and longest used (and therefor tested) libraries in the Arduino ecosystem I doubt it is a library problem. However that in itself is no guarantee there are no bugs left in it or in the underlying onewire library.

How frequent do you read the sensor? resolution?
Can you identify the blocking call in the library?
Do you have an oscilloscope to analyze the signal quality of the pulses on the data line?
Do you have a logic analyzer to see where the communication stops?

[Frans412]

Dear Rob, Thanks for your reply. To start with I use an Arduino nano V3. Parasite power supply: no (three-wire) Precision: 12 bits Use normal cable. 1 meter long. Pullup resistance at the sensor. So it is therefore closed with low impedance, and therefore less sensitive to interference. I can't check the one-wire. As a rule, I read the sensor once per minute, but my test setup reads once per second. I have completely filled the original program with test prints to locate the fault. But that is not in the library. I do indeed have a small oscilloscope. I'll see if that gets me further. There is no memory in the oscilloscope, so it is impossible to see incorrect data. I don't have a logic analyzer. I have been having the problem lately that I have to change the management of the library because there are suddenly no more readouts. There are several options for letting the library do its work. There will always be one that works. This alone makes me view this library with suspicion. Could it be that if the readout gets stuck somewhere in the library, it gets stuck there? Can this be resolved with a timeout in the library? I don't know if you'll get any further with this. The more examples I look at, the more complicated it all becomes. Parasit mode is not clear to me. Should it be on or off with a 3-wire connection? Also there is a "disconnected" item somewhere to test. Does this prevent crashes? The example "simple" should be simple... I must also admit that sometimes a program does not send data (to a network Software Serial). There will be more to it. But also a stuck person. A blink of the LED buildin every second in the loop just stops. This is what I call the hang-up. I'm inclined to build a system with remote reset. (I have a network of 11 stations, each with an arduino). I can select the station to reset using a shift register. I don't dare use a watchdog, because there are bad reviews here. Yours sincerely, Frans Goeman ***@***.*** Op za 27 jan 2024 om 09:30 schreef Rob Tillaart ***@***.***>:

…

The program in which this sensor is used keeps crashing. I cannot see your code(sketch), your hardware setup (board, parasite power, power supply? how many sensors?) or environment (noise? shielded wires?) so it is difficult to investigate the cause. As this is one of the most and longest used (and therefor tested) libraries in the Arduino ecosystem I doubt it is a library problem. However that in itself is no guarantee there are no bugs left in it or in the underlying onewire library. How frequent do you read the sensor? resolution? Can you identify the blocking call in the library? Do you have an oscilloscope to analyze the signal quality of the pulses on the data line? Do you have a logic analyzer to see where the communication stops? — Reply to this email directly, view it on GitHub <#230 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BFUKWSH4J3K4MBQISI3UCYTYQS3KTAVCNFSM6AAAAAARJNRSYKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMJTGA3TMNJRHE> . You are receiving this because you commented.Message ID: <milesburton/Arduino-Temperature-Control-Library/issues/230/1913076519@ github.com>

[RobTillaart]

OK,

What voltage do you power your Nano?

What resistor do you use, for 1 meter I would use a 2200 Ohm.
If the resistor is too large, the signal will not be "square" enough and 0's and 1's could get mixed up.

Can you run the example Timing.ino and post its output?
NB there are counterfeit versions of the DS18B20, some of them can be detected by their timing.

Do you have a multimeter?
Can you measure the voltage at the sensors end?

[Frans412]

Hello Rob, Thanks again for your response. The nanos are supplied with 5V on the 5V pin via a voltage regulator from 12 volts from the connection / data cable. The signals to and from the nano are almost all 5V. The resistance is standard 4k7. Should I lower it to 2k2? Yes, I have a multimeter. The voltages are easy to measure. The sensor will receive 5V with a tolerance of at most 2%. All sensors are handled by the nearby processor. The stations pass their data on to the mother processor, which processes it further, including for storage. To get an idea of the whole thing: I built a weather station with all kinds of separate "sensors" that have their own processor. They are in and around the house. I can control more or less processes from the base station, and the stations themselves send their data to the base station. [image: image.png] Here is a photo of the data from the SD18B20. The period time is approximately 70usec, which equates to approximately 14kHz. A search for timing.ino on the arduino website yields nothing. I can't find anything on Google either. Is it still necessary that you need the information from Timing, now that you know that the frequency is approximately 14kHz? Otherwise, where can I find Timing.ino? Until then again. Yours sincerely, Frans Goeman ***@***.*** Op za 27 jan 2024 om 14:08 schreef Rob Tillaart ***@***.***>:

…

OK, What voltage do you power your Nano? What resistor do you use, for 1 meter I would use a 2200 Ohm. If the resistor is too large, the signal will not be "square" enough and 0's and 1's could get mixed up. Can you run the example *Timing.ino* and post its output? NB there are counterfeit versions of the DS18B20, some of them can be detected by their timing. Do you have a multimeter? Can you measure the voltage at the sensors end? — Reply to this email directly, view it on GitHub <#230 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BFUKWSC66GQWGQYORJLH34TYQT34ZAVCNFSM6AAAAAARJNRSYKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMJTGE2TENBQHA> . You are receiving this because you commented.Message ID: <milesburton/Arduino-Temperature-Control-Library/issues/230/1913152408@ github.com>

[RobTillaart]

The resistance is standard 4k7. Should I lower it to 2k2?

Yes, that will pull the level to 5V roughly twice as fast.

A search for timing.ino on the arduino website yields nothing. I can't find
anything on Google either.

timing .ino is an example of this library.

[image: image.png]
Here is a photo of the data from the SD18B20.

Not uploaded correctly apparently

[Frans412]

Hello Rob, I have included 2 attachments. IMG_5247 is with pullup of 4k7, IMG_5249 is with pullup of 2k2. The flanks of the scope are a bit steeper with a pullup of 2k2. Overshooting is also less, both up and down. And more stable after overshooting. But I doubt whether this makes it all better. A 1 is and remains a 1, and a 0 also remains a 0. They do not appear in critical values of the logical levels. I also turned timing. Current for you: SetResolution 4 or 8 microsec. Time are constants. Current time is always approximately 751 millisec. Gain 800%, 400%, 200% and 100%. +/- 0.2% I'm now going into the endurance test. See what it does in the longer term. I'll be in touch. Yours sincerely, Frans Goeman ***@***.*** Message ID:

…

<milesburton/Arduino-Temperature-Control-Library/issues/230/1913224433@ github.com>

[RobTillaart]

Can you run the example Timing.ino and post its output?

I need to see the actual output.

Current time is always approximately 751 millisec.

Timing should give different results for different resolutions.

I have included 2 attachments.
IMG_5247 is with pullup of 4k7,
IMG_5249 is with pullup of 2k2.

No images again.

[Frans412]

Hello Rob, I keep getting an error message that our emails are not being sent properly. I received a message from Google that they will try for another 45 hours, but then stop. I have been having some trouble with Google Chrome for a while now. It is possible that something is not working properly here, including the emails. I'm going to check this out first. Then we continue with our posts. Greetings, French.

…

Message ID: <milesburton/Arduino-Temperature-Control-Library/issues/230/1913518693@ github.com>

[Frans412]

Hello Rob, I don't know what is going on that blocks the transfer of JPG, both local and attached. I will send the result in plain text to the email. Yours sincerely, Frans Goeman ***@***.*** ***@***.***> 21:44:07.331 -> DallasTemperature Library version: 3.8.1 21:44:07.378 -> 21:44:07.378 -> Test takes about 30 seconds for 4 resolutions 21:44:07.424 -> RES TIME ACTUAL GAIN 21:44:07.424 -> 62788 21:44:07.471 -> 62548 21:44:08.690 -> 9 94.00 59.40 63.2% 21:44:08.737 -> 62604 21:44:08.783 -> 62496 21:44:10.002 -> 10 188.00 59.40 31.6% 21:44:10.049 -> 62616 21:44:10.142 -> 62504 21:44:11.314 -> 11 375.00 59.45 15.9% 21:44:11.361 -> 26884 21:44:11.361 -> 26760 21:44:12.580 -> 12 750.00 59.40 7.9% 21:44:13.564 -> Op zo 28 jan 2024 om 09:47 schreef Rob Tillaart ***@***.***>:

…

Can you run the example Timing.ino and post its output? I need to see the actual output. Current time is always approximately 751 millisec. Timing should give different results for different resolutions. I have included 2 attachments. IMG_5247 is with pullup of 4k7, IMG_5249 is with pullup of 2k2. No images again. — Reply to this email directly, view it on GitHub <#230 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BFUKWSFADPK6T7OH6BPK2TLYQYGCBAVCNFSM6AAAAAARJNRSYKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMJTGUYTQNRZGM> . You are receiving this because you commented.Message ID: <milesburton/Arduino-Temperature-Control-Library/issues/230/1913518693@ github.com>

[RobTillaart]

It looks like the sensor is constant in 9 bit mode, it could be counterfeit.

Please have a look at - https://github.com/cpetrich/counterfeit_DS18B20

[Frans412]

Tekst printing is: DALLAS 18B20 2331C4 +807AB Liking a good one. ??!! Op ma 29 jan 2024 om 22:19 schreef Rob Tillaart ***@***.***>:

…

It looks like the sensor is constant in 9 bit mode, it could be counterfeit. Please have a look at - https://github.com/cpetrich/counterfeit_DS18B20 — Reply to this email directly, view it on GitHub <#230 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BFUKWSER2TYO4N4CTZTBGA3YRAG53AVCNFSM6AAAAAARJNRSYKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMJVGU4TAMJUGM> . You are receiving this because you commented.Message ID: <milesburton/Arduino-Temperature-Control-Library/issues/230/1915590143@ github.com>

[RobTillaart]

Please post the full output of

• discover_fake_DS18B20.ino and
• classify_fake_DS18B20.ino

These test several things and help to classify the sensor.
According to https://github.com/cpetrich/counterfeit_DS18B20 the place where you bought it is also an indication.

[Frans412]

Timing.ino. Op di 30 jan 2024 om 09:30 schreef Rob Tillaart ***@***.***>:

…

And the sketch running is ????? — Reply to this email directly, view it on GitHub <#230 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BFUKWSDLT52YPOZYHVPPYETYRCVTRAVCNFSM6AAAAAARJNRSYKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMJWGMYTIMBXGM> . You are receiving this because you commented.Message ID: <milesburton/Arduino-Temperature-Control-Library/issues/230/1916314073@ github.com>