reef-pi has suddenly stopped recording temperature

[MichaelA18454]

reef-pi has suddenly stopped recording temperature​

Issue first detected with Version 5.2 two months ago
Current Version 6.0 issue persists

this issue occurs every other day, but up until then the temperature has not failed for many years.

error message:
"temperature sub-system. Failed to read sensor 8 - Heater. Errorpen /sys/bus/w1/devices/28-d9b9151e64ff/w1_slave: no such file or directory"

I disconnect the sensor that appeared to have stopped working, I reconnect it after a few hours and it usually works again, but tonight the entire database disappeared completely and needed to be reloaded. Once I uploaded the database, the sensor is now read by the Pi-Zero

Tomorrow I will install 5.2 and start again unless anyone has other ideas.
Cheers

 

[Sral]

For completeness sake, here my answer from the other thread:

Nevertheless, that error shows that the system failed to communicate with the sensor, if it was working before it’s likely an electrical error disturbing signal integrity. Might be outside or inside interference, might be wet or corroded contacts, might be a lot of things.

I’m currently working on a different project reading „DS18B20“ sensors , I think @theatrusjust mentioned that they are quite often not original and can show slightly unexpected behavior, and when I handle the just 150 mm short cables I often get read values of -1000, e.g. a communication error. When I resample the sensor a maximum of 10 times after these errors, I mostly eradicated the issue, although I’m working with a Pi Pico microcontroller and the library there works probably slightly different.

I would try if a smaller pull-up resistor solves the issue, like a 2.7k for example. You can also try two 4.7k in parallel, should result in the same pull-up strength.

 

[Sral]

@MichaelA18454‘s answer:

I reduced the Pullup resistor to 3K6 but without change.
The sensors I have are from old stock purchased many years ago, and have not experienced this before. I bought another 10 sensors in the past month and they didn't resolve the issue.
I reviewed the data sheet and it states VCC to be 3V3 to 5V5 and I use 3V3 as per the instructions. Regardless, I find this bizzarre that it all of a sudden I am seeing the issue persist.
There has to be a reason.

 

[Sral]

My reply:

3k6 might not be enough, but then again, this might not be the solution either. I’m currently running 1k6 on my Pico setup with 3V3, but also couldn’t tell you if there would even be a difference to 3k2 or even larger. Cable lengths are important as well.

Although reading you say that completely new sensors (with new cable as well ?) behave the same, I‘m somewhat suspecting a software problem or hardware issue between PI Zero and the plug and everything in between (including the pull-up, although we might rule that out if you tried a different one).

How is the second Pi progressing ?
Do you have another system available for testing, like a Pi Pico, Arduino or ESP32 ?

 

[Sral]

Aaand @MichaelA18454‘s response:

I am not thinking the 4K7 resistor is the issue because the Pi-Zero (V.5.2) has been running for 4 ~ 5 years without issue using 4K7 pull-up, but your comment on cable length has merit .

When the issue started, I had soldered joints for the cable extension, and found the extension cable was plain copper and had become oxidised black and was not solderable any more. So I changed the extension cable out for a screened sheath with a larger cross section tinned copper cores, and changed to the 3.5mm stereo jacks, and now I think back, the issue occurred more often. I also changed out the Pi-Zero to a new one loaded with Version 6.0.

As for the second Pi-Zero?

It is the Pi-Zero (Version 5.2) that had been running for all those years without issue,
I changed it out for a new Pi-Zero (Version 6.0).
It is still running after 3 weeks, the test does not include the extension!!!

So my take away is, your comment of electrical noise and cable impedance needs to be addressed. I will terminate the screen to ground at the Pi and add a 100N cap to the SIG - GND and see how that goes, and get back to you.

Much appreciate your support.

 

[Sral]

Hm, personally I think both the pull-up and the cable length are very similar in effect:
- a longer cable adds more capacitance, so the signal rises slower, possibly too slow to make the timing required in the OneWire protocol.
- a longer cable also adds more length where outside interference might enter the line, also disturbing the timing, etc.
- longer cables also interfere with timing in the sense that the timing must be within specs at all sensors at the same time, so that the largest length between all possible bus participants (sensors and the master) is not too long, otherwise the furthest sensor might think communication is over and starts transmitting his signal over the other participant.

- a lower resistor value pulls up the signal line stronger to VCC, so the signal rises faster, improving the timing towards staying within the specs.
- a lower resistor value possibly also thereby decreases the influence of outside interference.

So the pull-up might be the issue if, for example, cable length or capacitance has increased, Inside or outside interference has increased, or water has entered the system/cable/plug introducing a parasitic pull-down resistor that slows the communication.
[Amendment]: You are right about impedance, increasing impedance within the signal line and GND line, does the same thing, e.g. slowing down communication. So it behaves similar to increasing capacitance.

Could you elaborate more on what you mean by „extension“, your „screen“, terminating that to GND and why you think adding a capacitor between SIG and GND will improve things ?

Especially the last is confusing to me, as you DON‘T want more capacitance on the signal line. That slows down communication, possibly to the point of the bus failing more.

 

[Sral]

@MichaelA18454
I would also CAUTION A LOT against even trying that capacitor. It will present a significant capacitive load to the sensors and when they try pulling the signal line down to communicate, the current surge might be way to high for the sensors AND the Pi. If it doesn’t kill the pin outright it might do so over longer periods of stressing them this way.

Typical cable does, if I’m not mistaken, range in the several dozens of Pico Farad. Your intended 100 nano Farad would be several orders of magnitude higher, also resulting in current spikes several orders of magnitude larger than typical.

 

[theatrus]

@MichaelA18454
I would also CAUTION A LOT against even trying that capacitor. It will present a significant capacitive load to the sensors and when they try pulling the signal line down to communicate, the current surge might be way to high for the sensors AND the Pi. If it doesn’t kill the pin outright it might do so over longer periods of stressing them this way.

Typical cable does, if I’m not mistaken, range in the several dozens of Pico Farad. Your intended 100 nano Farad would be several orders of magnitude higher, also resulting in current spikes several orders of magnitude larger than typical.

Exactly this. Has a high chance of damaging everything attached to the pin, and making every problem just as bad (no way you’ll hold the needed rise and fall times).

It’s hard to guess without the proper measurement equipment here. A single bad connection on the bus can wreck havoc.

 

[MichaelA18454]

You guys are amazing, your input is fantastic, thank you so much.

The DS18B20 come in various cable lengths and up to 15', so I wasn't considering the cable length would be an issue, and initially I used a very similar cable to that of the sensor to increase the length of the standard 3' cable length another 4', and when I started having the issue, I found there was corrosion of the O volt core and it could not be soldered any more.

I changed the cable to a tinned 3 core shielded cable like that used for microphones.

In the past I have experienced interference, affecting impedance and signal integrity when the shield was not grounded at the point of control. I prefer not to ground both ends as I found this causes undesirable current between 2 points, and at one stage I had to reduce the pull-up resistor to very low values to overcome the signal noise in the high voltage environment.
The data sheets specify the 4K7 pull-up regardless of 3V3 or 5V0, and have not found an issue for the years of service. So from my point of view the Shield was the only change that could be an issue because I didn't ground it.

As for the 100N cap, yes you are right it shouldn't be used because of the high speed switching with data read. I mixed this requirement with he optical level sensor, and in this case I do have a cap on SIG to GND.

So, I did not make the changes today, but rather decided to monitor the connection, because the sensor decided to work again, after a power cycle required because of the 3.5mm jacks.

I am still not convinced why the temp sensor stops being read, is it the Pi or the sensor and what causes the read to restart.
This time I didn't change the sensor out but have disconnected it and power cycled the Pi several times and the third time proved lucky, it started reading and is still running OK after 24 hours.

Cheers

 

[Sral]

You guys are amazing, your input is fantastic, thank you so much.

The DS18B20 come in various cable lengths and up to 15', so I wasn't considering the cable length would be an issue, and initially I used a very similar cable to that of the sensor to increase the length of the standard 3' cable length another 4', and when I started having the issue, I found there was corrosion of the O volt core and it could not be soldered any more.

I changed the cable to a tinned 3 core shielded cable like that used for microphones.

In the past I have experienced interference, affecting impedance and signal integrity when the shield was not grounded at the point of control. I prefer not to ground both ends as I found this causes undesirable current between 2 points, and at one stage I had to reduce the pull-up resistor to very low values to overcome the signal noise in the high voltage environment.
The data sheets specify the 4K7 pull-up regardless of 3V3 or 5V0, and have not found an issue for the years of service. So from my point of view the Shield was the only change that could be an issue because I didn't ground it.

As for the 100N cap, yes you are right it shouldn't be used because of the high speed switching with data read. I mixed this requirement with he optical level sensor, and in this case I do have a cap on SIG to GND.

So, I did not make the changes today, but rather decided to monitor the connection, because the sensor decided to work again, after a power cycle required because of the 3.5mm jacks.

I am still not convinced why the temp sensor stops being read, is it the Pi or the sensor and what causes the read to restart.
This time I didn't change the sensor out but have disconnected it and power cycled the Pi several times and the third time proved lucky, it started reading and is still running OK after 24 hours.

Cheers

Good to hear. I hope it persist.

Personally, I am using shielded USB-cables for my I2C network and I think I also don't have them grounded on either side. No serious problems so far, except a few spurious read errors a couple of times per day maybe. Nothing persistent anyway.
Although thinking about it and reading about it on Mouser, one should probably ground the shield on a single central point, probably the main controller.

So just for understanding, do you now use non extended shielded cables for your sensors all the way to your controller ?

Personally, I think I'm using non-shielded cables of 1,5m (60" ?) that came with the sensors from robo-tank.ca connected with JST connectors, so nothing fancy. Pull-up is done through an Adafruit BSS138 level shifter, which keeps my sensor side on 5V and pulls up with a 10k on the 3V3 and 5V signal side each, so about 5k on that one. Additionally I think I have soldered another 15k-17k or so into each cable, leaving me with 3k effective in total. Have been working fine so far.

 

[Sral]

@MichaelA18454 BTW, I would not count too much on the datasheet specifiying 4.7k for both 3V3 and 5V, since that heavily depends on cable capacitance, network length and controller voltage level.

The controller only cares about its HIGH level threshold, which should be around maybe 60-70% of VCC. That's fixed. If you now pull the network up with a 4.7k, this limit gets crossed faster with a pull-up to 5V, than with the same pull-up to 3V3.

 

[theatrus]

Also be cautious about pulling up to 5V when using devices with 3.3V IO - you'll be constantly moving current through the body diodes on the main chip (Pi processor, etc). There is a maximum spec for this on different devices (maximum current through the body diode), and its not good practice to continually rely on them, especially if you start dropping the resistor value which would increase this current.

 

[Sral]

Also be cautious about pulling up to 5V when using devices with 3.3V IO - you'll be constantly moving current through the body diodes on the main chip (Pi processor, etc). There is a maximum spec for this on different devices (maximum current through the body diode), and its not good practice to continually rely on them, especially if you start dropping the resistor value which would increase this current.

Should not be an issue though in my case, since I am using a BSS138 level shifter between the Pi‘s 3V3 IO and the sensor‘s 5V side, or does the same apply for the DS18B20 sensors themselves ?

 

[MichaelA18454]

Sral, all I have done is ground the screen of the extension cable at the Pi and haven't had another sensor loss since, so far so good.

 

[Sral]

Sral, all I have done is ground the screen of the extension cable at the Pi and haven't had another sensor loss since, so far so good.

Perfect, thanks for reporting !

That is perfectly in line with the report from Mouser. I'll probably have to ground my screens as well now

 

[MichaelA18454]

Perfect, thanks for reporting !

That is perfectly in line with the report from Mouser. I'll probably have to ground my screens as well now

Hi Sral, Today both the test device and active device failed to read the temperature sensor. I disconnected the physical sensors from both devices and after 2 hrs the sensors were reconnected only to find the Test device now reads the temperature sensor. The active device still not reading,. I removed the sensor on the aquarium and left for another 3 hours but it is not read. so I swapped the sensors around, the aquarium is now reading and the sensor from the aquarium is not read on the test device.
This is weird

 

[Sral]

Hi Sral, Today both the test device and active device failed to read the temperature sensor. I disconnected the physical sensors from both devices and after 2 hrs the sensors were reconnected only to find the Test device now reads the temperature sensor. The active device still not reading,. I removed the sensor on the aquarium and left for another 3 hours but it is not read. so I swapped the sensors around, the aquarium is now reading and the sensor from the aquarium is not read on the test device.
This is weird

Very much so ... sry for the delay.
Reading it now, have you dipped both sensors in water ? Maybe there is water creeping in that leads to shorts or increasing capacitance on the cable.
Although if both sensors on both devices failed, it might be interference. Have you run both devices on a common supply, or have they had different ?
Do you run a grounding probe or ground your PI ?

You might try higher-quality DS18B20 sensors, like @robsworld78 mentioned here, or improving yours with additional silicone and heatshrink, or an additional tube as described here.