Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Unreliable DS18B20 Readings
#1
Hi:
I recently set up a robo-tank with this configuration:
  • Reef-pi Deluxe Aquarium Controller Fully Assembled
  • 'pi zero w
  • the recommended Alarmpore Power Adapter from Amazon 
  • one 0-10V LED channel driving Mean Well ELN-60-48P supplies (my white LEDs)
  • another 0-10V LED channel driving Mean Well ELN-60-48P supplies (my royal blue LEDs)
  • one DC channel driving a return pump via a Digital Loggers, inc IoT relay     
  • a second DC channel driving a return pump via another Digital Loggers, inc IoT relay
  • One DS18B20 1-WIRE Waterproof Digital Temperature Sensor Probe - 3 meter cable  in the display tank, one sample per minute
  • A second DS18B20 1-WIRE Waterproof Digital Temperature Sensor Probe - 3 meter cable measuring ambient temperature, one sample per minute


With the system assembled, configured and running upstairs in my office, the temp sensors seemed to be working reliably and the pump and lighting controls behaved as programmed/expected.  When I moved everything into the fish tank room and hooked it up, the temp sensors became unreliable.  Specifically, after a variable and inconsistent amount of run time (sometimes many hours, sometimes only a few minutes), they will begin to read some small negative value, and produce an error like:
temperature sub-system. Failed to read sensor RoomTemp. Error:open /sys/bus/w1/devices/28-3c01d075740d/w1_slave: no such file or directory
occasionally, the system will recover from this and begin to produce accurate readings, but that's more the exception than the rule.  Powering down the entire system, including removing the supply power from the Robo Tank and waiting a couple of minutes will restore correct operations upon reboot.

Evidently, this is a know issue w/raspberries, and is discussed in this thread:
https://www.raspberrypi.org/forums/viewt...p?t=164059

To begin to diagnose/resolve this issue, I have established that two of the conjectures/issues thought to exacerbate the problem are not central to my case.  In the cited thread, it is suggested that long sensor leads are problematic, and that some counterfeit 'Chinese' DS18B20 parts are inferior.  I had a couple of DS18B20 samples that were shipped directly to me from Maxim, so I screwed one of those directly into one of the green plastic couplers, and the problem persists.

Any thoughts about how to debug/diagnose and resolve this issue would be appreciated!

Thanks for reading,
Phil
[-] The following 1 user Likes pwest's post:
  • Rob F
Reply to top
#2
Hi Phil, sorry to hear, yeah unfortunately this can be a problem but as far as I know people who were affected got if fixed one way or another. When you tried the Maxim sensor did you unplug the other DS18B20's? They share the same pin so if one hangs the bus the others are effected. With a little mod you can use a sensor port as another 1wire bus so they are on separate lines but doesn't fix the issue.

Other possible causes can be electrical noise affecting the sensor, for example a pump turning on. In one case someone had this issue and after plugging the controller into a different AC circuit in the house the problem went away. As it appeared to work until you moved it to fish room maybe it's something sharing the same power line creating too much electrical noise.

Another source of noise can come through the aquarium, adding a ground probe to the tank could help. If you have a piece of wire you could add a temporary probe, place the wire in the tank and other end in the Ground of an AC outlet. You could also simply leave the probe out the tank to see if problem goes away.

Unfortunately I've never experienced this nor has the people who develop the software so it's hard to troubleshoot. A little while ago I was told about the trick of cutting power to sensors via GPIO but that requires changes in reef-pi to perform the reset.

Any chance you have another SD card and you could load up my software to see if the problem persists? On my test setup I'm running 3 sensors, when I started I would get 186 or -1 sometimes on a sensor or two, never locked up though. I added some checks in the code to skip on different errors and no longer get false readings but in log can see it still happens just it's caught now. I'm wondering if catching the errors when it happens will prevent the bus from locking.
Reply to top
#3
(06-19-2021, 02:34 PM)Rob F Wrote: Hi Phil, sorry to hear, yeah unfortunately this can be a problem but as far as I know people who were affected got if fixed one way or another. When you tried the Maxim sensor did you unplug the other DS18B20's? They share the same pin so if one hangs the bus the others are effected. With a little mod you can use a sensor port as another 1wire bus so they are on separate lines but doesn't fix the issue.

Other possible causes can be electrical noise affecting the sensor, for example a pump turning on. In one case someone had this issue and after plugging the controller into a different AC circuit in the house the problem went away. As it appeared to work until you moved it to fish room maybe it's something sharing the same power line creating too much electrical noise.

Another source of noise can come through the aquarium, adding a ground probe to the tank could help. If you have a piece of wire you could add a temporary probe, place the wire in the tank and other end in the Ground of an AC outlet. You could also simply leave the probe out the tank to see if problem goes away.

Unfortunately I've never experienced this nor has the people who develop the software so it's hard to troubleshoot. A little while ago I was told about the trick of cutting power to sensors via GPIO but that requires changes in reef-pi to perform the reset.

Any chance you have another SD card and you could load up my software to see if the problem persists? On my test setup I'm running 3 sensors, when I started I would get 186 or -1 sometimes on a sensor or two, never locked up though. I added some checks in the code to skip on different errors and no longer get false readings but in log can see it still happens just it's caught now. I'm wondering if catching the errors when it happens will prevent the bus from locking.


Rob F asks: When you tried the Maxim sensor did you unplug the other DS18B20's? 
Yes: right now, it's the only sensor and the error has appeared.

Rob F comments: As it appeared to work until you moved it to fish room maybe it's something sharing the same power line creating too much electrical noise.
I have 3 independent AC circuits in the fish room.  All my systems (lights, pumps) are dual to get redundancy, plus there is one other circuit that has no fish room stuff (pumps, lights, heaters, etc) on it.  Originally I had plugged the controller into that one, but I moved it to one of the others and got no improvement.

Rob F comments: 
adding a ground probe to the tank could help
I had already considered that and sealed the metal thermometer bulb in heat shrink and RTV to preclude any potential ground loop/common mode issue: no improvement.

Rob F asks: 
Any chance you have another SD card and you could load up my software to see if the problem persists? 
I don't understand what you are asking here.  I'm sure I could find another SD card, but this controller is now running my reef.  Is the software you want me to load some custom version of reef-pi, or something else?  What's involved with giving it a try?

One other thing I noticed this afternoon is that the PH probe stopped working a while ago, with a similar error:
ph subsystem: Failed read probe:PHError:pin 0 on analog input 1 has no driver: driver 1 for analog input pH not found: driver by id 1 not available

Thanks for helping out,
Phil
Reply to top
#4
Is it locking up with just the single sensor or only the error? Errors can happen if reef-pi looks for a sensor ID that happens to not be seen on the bus for whatever reason, shouldn't lock up though.

I forgot to ask if you unplug the sensor/s and plug back in after 10 seconds does it start working again or do you need to cut power to controller?

If it's locking with only the transistor directly in the screw terminal connector it seems like noise could be the culprit. Obviously not ideal but if you unplug everything from the controller except the temp sensor what happens?

Yeah if you have the controller running things it would be difficult to run the other program as it's not ready to control everything, I just would love to see the results but it's ok. The program is an app I'm working on for controller, it's getting closer to ready but still some to go. If it's loaded on another SD card you could swap cards and having things running with reef-pi again. It installs without much trouble.

What's the status of the pH now? I don't know if I've seen that error, the errors I've had in the past are I2C related and say so in the error. This seems to be saying it can't find the driver id 1 so I'm thinking it's a database issue.

If pH isn't working type the following command in the Pi SSH terminal window. It should print a list of addresses, 40, 70 and 63.

i2cdetect -y 1
Reply to top
#5
Typically, I have to cut power and wait to get the sensors working again. Sometimes even that seems not to work.

Here's the i2cdetect: it looked the same a few days ago when I was setting it up.
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: 40 -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- 63 -- -- -- -- -- -- -- -- -- -- -- --
70: 70 -- -- -- -- -- -- --

And, right now, I have only the 'bare' DS18B20 connected, and I see a bunch of these messages in the log:
6/19/2021, 7:16:58 PM UI ERROR {"error":"open /sys/bus/w1/devices/28-3c01d075740d/w1_slave: no such file or directory"} | HTTP 404

For some additional diagnostics, as you suggested I removed all external cabling, plugged in a second 'bare' 1820, rebooted and got NO temp readings. So, I removed both temp sensors from the configuration and re-added them, and they started fine and have been reporting and graphing for 15 mins, or so. I need to hook the lights and pumps back up--we'll see what happens w/those connected. Clearly there is an issue where the pi somehow decides to de-register the driver after some kind of a failure.

I'll report back when I've got some new data.

-Phil
Reply to top
#6
Thanks that looks good with the addresses, I don't think the pH was a hardware issue but keep me posted.

Hmm, that's seems odd on the restart, for the heck of it maybe increase how often the sensor is checked to 5 seconds.

By default the Pi can take up to 10 seconds to detect a new sensor and about 60 seconds before it de-registers on the Pi.

Not really clear on the no temp readings when you plugged in the new sensor. In case you are unfamiliar, each sensor has an internal ID, this is the 28-xxxx number you see when you add one to the temp tab. If you already had that 2nd sensor added to temp tab and there was no temp then yeah that's not right. If you unplug a sensor reef-pi will continually report errors until you disable the sensor on the temp tab, at that point it doesn't look for the sensor folder the Pi creates for each ID.

What's different on my program and why I hope it clears up the issue, I changed how quick the Pi sees and de-registers sensors. Instead of taking 60 seconds it only takes a little over a second. The Pi creates a file for each sensor, this is what disappears very quickly now. Every time the sensors are read it firsts scans what the Pi has on the bus and it only reads them, the program doesn't specifically say read sensor 28-029128. Because of this periodically on my dashboard I'll see a sensor disappear and then reappear the next reading meaning it wasn't active for whatever reason during that cycle. There's other checks in place as well.

Well let me know how it goes and if any other errors appear.
Reply to top
#7
Here's an update on this.
Using the two 'bare' temp sensors (and no PH probe), the system ran for several hours last night with the lights on, and with at least one return pump on/off cycle with no problems. With this success, I replaced one of the bare sensors w/the 3 meter probe in the tank. Both sensors worked well all night long, but about an hour after the lights came on at 14:30 today, they ceased to report with these errors:
Jun 20 15:46:19
temperature sub-system. Failed to read sensor TankTemp. Error:open /sys/bus/w1/devices/28-3c01d07560a8/w1_slave: no such file or directory
X
Jun 20 15:46:27
temperature sub-system. Failed to read sensor RoomTemp. Error:open /sys/bus/w1/devices/28-000000c262f6/w1_slave: no such file or directory

I'm going to pull the tank sensor and put the bare sensor back on.

-Phil
Reply to top
#8
Did you have to repower system to get them working again or was it a one time error and they continued?
Reply to top
#9
When I noticed the problem, the system had completely stopped reading the sensors. Then, I powered down the pi from the admin tab, unplugged the power supply, unplugged the tank sensor, plugged the bare sensor back in, reattached the power supply, and then re-added the sensor in the 'temperature' setup configuration. Since then, all has been fine. I'll see if this continues for a few days.

-Phil
Reply to top
#10
Oh that's not good. Any chance you have another 12v power supply to power up controller? It draws less than .5 amps without DC ports so a small one would work for testing.
Reply to top
#11
As a solid data point, I inserted the two 'bare' DS18B20 sensors onto the controller which is also configured to manage the lighting and the return pumps (just a manual pumps off for 5 mins for feeding). The temp sensors ran all week w/no errors.

This morning, I powered down the controller and replaced one of the bare sensors w/the 3 meter cable which runs over to the display tank, but is currently not immersed. We'll see how that goes.

-Phil
Reply to top
#12
Sounding good, hoping it continues.
Reply to top
#13
Photo 
(06-26-2021, 02:52 PM)Rob F Wrote: Sounding good, hoping it continues.
Unfortunately, we have results already.  I did the swap over around 11:00 AM and all was fine for a couple of hours.  The lights start to ramp up at around 2:00 and are at 50% intensity at 3:00.  Shortly after that, I started to see -1 readings and got errors like these:
Jun 26 18:18:24
temperature sub-system. Failed to read sensor TankTemp. Error:open /sys/bus/w1/devices/28-3c01d07560a8/w1_slave: no such file or directory

Jun 26 15:48:05
temperature sub-system. Failed to read sensor RoomTemp. Error:open /sys/bus/w1/devices/28-000000c262f6/w1_slave: no such file or directory


   
Reply to top
#14
The fact it happened so quick makes me think the sensor with cable is bad or noise is getting into cable. Is the sensor cable running close to other cables?

I don't know if you're up to trying this, but maybe add some wire to a bare sensor and see how that one goes. If that continues to work we can assume the other sensor is bad.

Also if you are comfortable removing two resistors from board I can post a pic so you can setup a sensor port for DS18B20 and see if the bus the cabled sensor runs on continues. Like this one won't take down another.
Reply to top
#15
The sensor cable is not particularly close to any other cables or wiring. I think it's almost certain that EMI from the LED's and/or their drive circuitry is causing the trouble by coupling into the long sensor cable. While chasing this down, it would certainly be advantageous to get the two 1-wire devices on separate IO pins, so please send me the instructions for the mod.

I'm thinking that I should try the LPF shown in Appendix B of https://www.maximintegrated.com/en/desig...1/148.html.
Reply to top
#16
Yeah I've seen issues with various lights, sometimes power supply or driver circuit so that could be it.

As you've noted it's not idea being in a STAR configuration, running them in parallel is better but under 5 meters per line in star isn't that bad in my experience, I've tested three 15m and they ran fine for a couple days. On mine I'm running two 5m + 1 bare. Unfortunately I don't have as many GPIO's as I want that's why they share the same but I think I have to split them somehow as this is happening more than I like. Soon I'm also going to have a 8 port extension that could plug into a DB9, it would give 8 new 1-wire buses the way it should be.

Here's a pic to remove those resistors, these are a voltage divider that the DS18B20 can't get by. I circled the group of resistors for each sensor port if you want to change more, the blue resistor needs to be removed  and the pad is left empty, the yellow resistor needs to be removed and the pads for this resistor soldered so they bridge.

Sensor port jumpers should be set as follows. One jumper is on "OTHER" and 2nd jumper is on "P-U".

On the Pi you need to edit the /boot/config.txt file to enable the extra 1-wire buses

You will have the following line somewhere
dtoverlay=w1-gpio

Remove that line and replace with the following two lines.
dtoverlay=w1-gpio,gpiopin=4
dtoverlay=w1-gpio,gpiopin=17

The first line is GPIO pin 4 which goes to the 3 temp ports.
The 2nd line is the GPIO for the sensor port. You can add as many extras as long as pin number is different obviously.

These are the GPIO numbers for each sensor port.

Sensor Port 1 =  17
Sensor Port 2 =  27
Sensor Port 3 =  19

In reef-pi you'll want to delete the connectors for the sensor port/s you use. After doing that go to "admin" tab and press "reload" button. It's probably best to start with this step, then hardware, then Pi.

If you need more info let me know.

[Image: remove_voltage_divider.jpg]
Reply to top
#17
OK, I did this and put the two bare sensors back in. They seem to be working fine: I'll let them run for a couple of days and if they work reliably I'll re-connect the 3m DS18b20 using the recommended lowpass filter.

-Phil
Reply to top
#18
Sounds good, let me know how it goes.
Reply to top
#19
The two 'bare' sensors worked without error all week. This morning, I replaced the bare sensor on TEMP1 with the 3 meter DS18b20, with the lowpass filter installed, plus a 10uF bypass cap across the power supply pins. This has been working w/occasional bad reads (i.e. return temp of -1), but no errors or hang ups. The other sensor, now on sensor port 1 has continued to run without incident.

One question: is it the case that the recommended 4.7k pull up on the I/O pin is on the board?

-Phil
Reply to top
#20
That one with cable is sure being stubborn, it seems something might be up with it. As it returns -1 that is bad data, the sensor was seen on the bus but data was no good, normally that does point to a flaky sensor. I think it's also less likely that bus will lock up for that sensor as there's no extra resistance on the line from other sensors and of course the extra filtering could help although they don't do a whole lot unless located right at the sensor, the controller also has a bypass filter on the 5v rails to each port. So yeah that sensor may be no good with reef-pi as it doesn't seem to validate, hang on to it though for when you switch to my app at some point, if that happens it will just read the sensor again so you'll never know it's happening and it won't affect anything.

The 4.7k pullup is on the board, one for the 3 temp sensor ports and on the sensor port if one of the jumpers is set to P-U as you have that's a 4.7k pullup. The P-D means 4.7k pulldown.
Reply to top


Forum Jump:

Current time: 09-22-2021, 02:49 AM