PH probe issues

[Inamo]

So I finally got my EZO board and PH probe. I got it all hooked up, detected on the bus no issues. Got it calibrated with 7, and 10. Put it into my sump and while getting it integrated into Home Assistant, I noticed it kept randomly throwing out a -0.19 reading in Reef-Pi charts. It was almost systematic. I pulled it out and put it in a cup of water to ensure it wasn't interference and same thing. I'm hoping someone has some ideas before I enable and try the second I2C bus. Only things I have on the current bus are a RTC(DS3231). If I run the sample code from the Atlas website it will give a few readings, then errors as if it fell off the bus, then it returns, rinse and repeat. The close bunch just before 18:10 is when the script was running.

 

[Sral]

Sounds like a standard I2C instability.

What Pi are you using, what voltage are you running the I2C system on, do you have additional pull-up resistors, how do you power the EZO board and to what voltage ?

It's typical that when the network fails, that the sensor reads as 0. Since you calibrated the sensor, this gets converted to -0.19 pH

I hope that @Ranjib has the time to fix this in one of the next updates, so that erroneous readings of "0" get discarded instead.

Strange though that the Atlas script increases the amount of erroneous readings. I think the script and ReefPi might sometimes read at the same time and depending on the timing, they might work well, or one might aquire BUS-access just before the other tries to read, thereby blocking the other from reading, so he just reports "Error" or "0".

 

[Inamo]

I have a Pi 4B, the i2C is on the 3v(does 5v help?) power from the Pi. I have the 5v 3a plug powering the Pi and do not have any voltage errors kicking out. The temp sensor does not drop out like this. I did not add any resistors and I have the ezo going straight to the last 3v pin I had available, but I do have a PCB board I could solder to a 5v rail if that would help.

Well, the script and Reef-Pi could have been interfering with each other as I think about it. I think I had RP at 1 sec, and the script was default at 1.5. Before I stopped messing with it for the night, I couldn't even get the script to connect to the sensor, kept saying it wasn't an Ezo. This morning it worked, but still got the errors and despite me changing the poll to 10 sec in RP you can see when I ran the script on the right side. While it did have less issues that I can see in the chart through out the night.

Do you think moving it to the second bus or back to UART mode would help?

Also, what is the second chart, and it shows a lower PH reading.

I appreciate the help.

 

[Sral]

I have a Pi 4B, the i2C is on the 3v(does 5v help?) power from the Pi. I have the 5v 3a plug powering the Pi and do not have any voltage errors kicking out. The temp sensor does not drop out like this. I did not add any resistors and I have the ezo going straight to the last 3v pin I had available, but I do have a PCB board I could solder to a 5v rail if that would help.

Well, the script and Reef-Pi could have been interfering with each other as I think about it. I think I had RP at 1 sec, and the script was default at 1.5. Before I stopped messing with it for the night, I couldn't even get the script to connect to the sensor, kept saying it wasn't an Ezo. This morning it worked, but still got the errors and despite me changing the poll to 10 sec in RP you can see when I ran the script on the right side. While it did have less issues that I can see in the chart through out the night.

Do you think moving it to the second bus or back to UART mode would help?

Also, what is the second chart, and it shows a lower PH reading.

I appreciate the help.

I would not change it to 5V too rashly, since that entails thinking a lot about not frying anything. The Pi board should have a built-in pull-up resistor on the I2C lines. I think it was about 1.8k. So that should be fine ...

You can not easily change the network to 5V, as that would pull up the signal to 5V, which activates the protection diodes trying to keep the I2C signal at the PI at about VCC, which for the Pi is 3.3V. So you would need a level changing circuit in between that shifts the signal back to 3.3V to protect your Pi.

Although having a network at 5V signals makes it somewhat more resistant to outside noise than a 3.3V network. Might not be enough to fix your issue though.

Switching the sensor to the second BUS might help, since that decreases the amount of wire, although I imagine you don't have that much wire to begin with if you only run a RealTimeClock and the pH sensor, right ? So personally I don't think it's worth the effort.

I would not bring it to UART mode since that would make interfacing it with ReefPi a bit more challenging.

The second graph is a long-term average. Since the last hour had more faulty values in between that pulls down the average displayed in the second graph.

 

[Sral]

Just to be sure, you are using the EZO-board together with an isolation circuit ?

 

[Inamo]

Just to be sure, you are using the EZO-board together with an isolation circuit ?

Yes, I am using the Ezo PH circuit with the isolation carrier board. I'll try moving it to the second bus tomorrow and see what happens. I appreciate the help this far.

 

[Sral]

Yes, I am using the Ezo PH circuit with the isolation carrier board. I'll try moving it to the second bus tomorrow and see what happens. I appreciate the help this far.

I wish you good luck !

Although I’m not sure if the second I2C interface has pull-up resistors included like the main one, which has one 1k8 soldered onto the board for both the main I2C Data and Clock pin.

If there aren’t, just hooking it up won’t work, even if you enable the second I2C BUS correctly (I think you need some modification of a settings file).

I could not find that with a quick search either for now.

 

[Inamo]

Thank you, I will look before doing it to verify. If not I'll add one

 

[Inamo]

So this morning, I looked and the graph didn't have any dropouts in the history in reef-pi, but when I poll the API "readings" I see some infrequent ones.
So I looked and I don't think the second bus has the built in resistors. I started with trying to make a short an more direct route to the i2c pins by making a Y-cable out of the Pi. Funny thing is once I got it reconnected and booted up, it started with the more frequent dropouts again. It seems it does "better" the longer it runs. At one point I even tried disconnecting the RTC just to make sure it didn't have anything to do with it.

Something I feel dumb for not trying first, was bypassing the bulkhead connector and going straight to the carrier board. No apparent changes.

So, the graph does show a basic pattern (see pic), even now that I have changed some things troubleshooting.

Right now in Reef-Pi have temp every 60 seconds, and for T-shooting I have PH at 3. When I pull the API for "Readings" and count between the zero reads, first will be 20 PH values (every 3 sec * 20 = 60). The next zero will come after 41 (which is about 2m 3s) which is close to the temp check. Could this be causing a collision and causing the PH to fail, hence the zero?

Below is a capture. I verified every API pull on "readings" from the arrows to the current point, and 20/41 is consistent.

I changed temp to 5m and PH to 60s. No issues in 12 minutes. Small sample size for a large time in between test, but wanted to try 3s PH and 5m temp. Which after 50m, zero issues. Did get one to pop up, but it was when I was changing the PH read from 3-12s, so that might be because of the change that caused it to drop.

So it seems to be narrowed down to the temp and PH reads when they are at the same time. Temp probe is DS18B20 to GPIO 4, which of course does show up on the i2c page.

Any ideas on this, or is this maybe just one of the i2c quirks? This is much better and I can offset read times between the two to help minimize the issue and easily deal with it. Just not sure if maybe I missed something that could fix it entirely.

Thanks again.

 

[Inamo]

Funny, if I change PH to 12s interval I start getting the errors again. Was a visual pattern in the graph, but counting them, they were 1-5 and 56-60. Not as exact as the first counted time, but on the graph almost looked exact. Since changing back to 3s it has gone 30m without a drop. If nothing else, I'll leave it like this, but would like to figure out why and correct it if it is on my end.

 

[Sral]

Funny, if I change PH to 12s interval I start getting the errors again. Was a visual pattern in the graph, but counting them, they were 1-5 and 56-60. Not as exact as the first counted time, but on the graph almost looked exact. Since changing back to 3s it has gone 30m without a drop. If nothing else, I'll leave it like this, but would like to figure out why and correct it if it is on my end.

Wow great progress !
I would not have expected that.

Although that’s heavily dependent on Raspbian’s and ReefPI’s Interface handling.

Would be interesting if you could remove this entirely by setting both to the same, let’s say 60s intervals, but starting them 10-30s apart. That way they might never see each other, if ReefPi handles the timing exactly.

 

[Inamo]

I will give that a shot today. I just checked the readings api and there were no issues in the little over hour of history.

 

[Inamo]

Just tested it, 10 secs each and enabled 1 at a time, at most 5 sec apart. It started again, similar pattern. Will try again with a longer delay to ensure it wasn't me taking to long to start each.

 

[Inamo]

Was just going to edit and update last post, but don't see an edit button.

I turned both off, set to 30s intervals, turned one on after the other, made sure to let a good 10s go before starting second. Same thing, drops out in a pattern. I'll just leave it on a 3s/300s intervL on the two.

I don appreciate the help, but not sure where to go from here and it isn't that big of a deal as I'm getting all the data required.

 

[theatrus]

Was just going to edit and update last post, but don't see an edit button.

I turned both off, set to 30s intervals, turned one on after the other, made sure to let a good 10s go before starting second. Same thing, drops out in a pattern. I'll just leave it on a 3s/300s intervL on the two.

I don appreciate the help, but not sure where to go from here and it isn't that big of a deal as I'm getting all the data required.

Interesting there is a timing component. The Pi has a few I2C shortcomings, but there shouldn't be invalid data returned unless there is no checksum in the data.

Edit: Looks like the Ezo pH just puts "text" over the serial link (I2C included).

You can try to see how things might get scrambled up using the i2c sample code from Atlas on the Pi.

Raspberry-Pi-sample-code/i2c.py at master · AtlasScientific/Raspberry-Pi-sample-code

Contribute to AtlasScientific/Raspberry-Pi-sample-code development by creating an account on GitHub.

github.com

 

[Inamo]

Well after all that and how I was able reproduce it when it wasn't set to 3/300 between the two updates. It is dropping like crazy again. I just tried to disable to temp in Reef-Pi to see if it stops or not. Well, as I was typing I saw another drop. So I'm at a loss. The wires are not very long to the Ezo or RTC. For the Temp probe all I did was add a 3.5mm plug to it, so no extension to it either.

I'm at a loss at this point. Could it just be a bad Ezo and/or carrier board?

Ezo is top, RTC is bottom left.

 

[Inamo]

A reboot and it is working fine again, for the past 1.5 hours lol

 

[Sral]

A reboot and it is working fine again, for the past 1.5 hours lol

Wow, the classic: „Have you tried turning it off and on again ?“

Not sure if that changes the timing, or whether that removed some runtime error in the interface handling. Glad it it working now, fingers crossed that it stays that way !

 

[Inamo]

Wow, the classic: „Have you tried turning it off and on again ?“

Not sure if that changes the timing, or whether that removed some runtime error in the interface handling. Glad it it working now, fingers crossed that it stays that way !

Lol I know right. From what I can see it is still running smooth. I did notice one drop lastnight before I went to bed, but that doesn't concern me as I know my temp probe has done that as well.

For now I'm going to leave it as is and finish with cleaning up the wire routing in the stand and such. Plus I believe one of my relays is already bad inside my outlet box. The return pump isn't switch on and off.

I appreciate the help with troubleshooting this. I'm sure I will have more questions or issues soon enough.

 

[Inamo]

Ok, so an update to this for anyone else that might be having this issue or for those who are yet to come lol. Well it kept giving me problems with dropping out and reboots and even the 3/300 was hit or miss. I'm am 100% ignorant on how the i2c bus works and talks, but there is some kind of a timing issue that causes the problem, guessing bus side. So I could look through the API "readings" and the drops were at specific intervals. At one point I changed it to 5m interval and looking through the log, it would drop every hour at the 9th minute, i.e 4:09, 5:09, 6:09. I tried to put the PH on i2c4, but could not get reef-pi to see it. Tried totally removing it from reef-pi and starting over. Now I need to recalibrate it lol. Guessing Reef-pi only searches on the primary bus, but @Ranjib could confirm that if that is the case. So I ended up putting it back on the primary bus, and disconnected my RTC. Verified the only thing on the bus was the PH and let it go. I added 2 statistic charts for testing purposes, one to show min, and other max. It is reporting as of 10:50pm last night (since it was alone on bus) the lowest report was 7.92 and highest 8.09. Today I will add the RTC to the second bus and get it set back up and hopefully everything will continue to be stable.

Ignore the temp dropouts, those were from the setup, testing, and troubleshooting (PH) of the entire build on my workbench.