-
Notifications
You must be signed in to change notification settings - Fork 486
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
18B20: blocking time to time #230
Comments
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>
|
I have a peridioc reading temperature on my ESP32 do this : 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. |
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. But in general I find it strange that a library of a sensor can block the program. Does anyone have a solution? |
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? |
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>
|
OK, What voltage do you power your Nano? What resistor do you use, for 1 meter I would use a 2200 Ohm. Can you run the example Timing.ino and post its output? Do you have a multimeter? |
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>
|
Yes, that will pull the level to 5V roughly twice as fast.
timing .ino is an example of this library.
Not uploaded correctly apparently |
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>
|
I need to see the actual output.
Timing should give different results for different resolutions.
No images again. |
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>
|
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>
|
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 |
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>
|
Please post the full output of
These test several things and help to classify the sensor. |
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>
|
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.
The text was updated successfully, but these errors were encountered: