This is a follow-up to a lengthy discussion I initiated last December. Based upon all the outstanding advice and counel I received from forum members back then, my application for measuring and reporting the number of gallons of water in a 1771-gallon storage tank has been performing miraculously well. Until recently, that is.
My code has been populating a Google sheet every 15 minutes with the comma-delimited concatenated values of gallons, inches and percent full (you will also note a 4th value - a '0' - but you can ignore that in the attached screenshot as it is not germane to the issue at hand).
As shown in the screenshot, on August 8th at 13:49, the logged values are way out of whack and have continued as such ever since then; those values are proven invalid. Neither the firmware, the hardware nor the tank itself had been touched at that time. I plan on another 600-mile round-trip to the site this weekend to try to identify the cause of the bad data but I am hoping that maybe someone here has either seen something similar or can hazard an informed guess as to what is going on.
My first suspicion was that the underwater transducer had failed but it has been functioning perfectly in the current production environment and it also did so during all the testing I'd done with it ver the months since last December. I know that the sensor ports are not clogged by any silt or debris since it is suspended 2 inches above the bottom of the tank.
The Photon 2 that drives the whole setup is on-line and all of its other functions defined in firmware are working flawlessly. The firmware has a built-in reset function and I have rebooted the device from afar a few times with no affect. I had someone locally cycle power to it; no affect. I have flashed a slightly-modified firmware file in an attempt to address the issue but although the firmware update was successful the issue remains unresolved.
My current suspicions include: a bad Photon (although its brand new) that perhaps has an issue with analog port A0 or maybe the current-to-voltage converter is defective. Note that although not indicated on the diagram, the converter output is limited by jumpers to 3.3 volts.
Luckily, I have a spare of every component - Photon, current converter and transducer - and I will be taking them on the road trip. But if anyone reading this post has any thoughts as where best to focus my diagnostic efforts first, please let me know.
The GPIO and I2C pins are not 5V tolerant. From your schematic it looks like they might be at least exposed to voltages above 3.3V, though it looks like your A0 measurements are usually within range of the ADC.
I am aware of the 5-volt limit (already destroyed one Photon!), but the output from the current to voltage converter is limited by jumper to no more than 3.3 volts. BTW James, the firmware is pretty much the same has you helped me build last year; thanks again for that!
Do you also have a level shifter for the I2C pins? I just want to make sure because over-voltage issues can manifest in weird ways that aren't obvious. You had an earlier post about unintentional restarts as well, which could also be a symptom of something exactly like this.
Does the screen still show the same value that you're reading remotely? Also, can you have the operator confirm that the bottom resistor of your voltage divider is in place and not loose? If that were disconnected you'd see the values pegged at the max like you're seeing. Maybe also be useful to print the raw counts somewhere to be sure that it is actually reading the max ADC value if the max is higher than the clamped/converted value that you see in the sheet.
As I suspect you already know James, my knowledge of things electronic is limited, so when you mention 'level shifter' I have no idea what you are talking about. Can you clarify? Regarding the earlier restarts issue: that was relative to a seperate Photon and application - the one that monitors the float switch - and the restarts never stopped. I replaced that Photon and the problem has not reoccured, so that device was kaput.
Yes, the small LCD screen is showing the same values as are logged in the Google sheet. I also added a couple of Particle functions to my code to query the inches and gallons parameters in real time and those, likewise, return the same values.
"Bottom resister on the voltage divider": do you mean the voltage converter that I'm using to drop from 12 volts to 5 volts? If so, the only thing that looks like it could come loose - might not be soldered, but can't be sure - is right by the "VIN-" screw terminal. Is that what you are referring to (attached photo is of my spare unit)?
Level shifters are used to convert between two voltages, such as 5V and 3.3V so that they can play nice without operating outside of their operating conditions. I just want to ensure that you're seeing 3.3V on SDA, SCL, and A0 if you were to measure them with a voltmeter.
I guessed that you used a resistor divider to get the A0 voltage from 5V to 3.3V, and that it was hidden under the Photon. I don't actually know what you're doing to lower the voltage.
I'm not referring to the 12V->5V converter here. How are you getting the voltage on A0 from 0-5V to 0-3.3V?
I will be taking my multimeter to the site this weekend to confirm, but the current-to-voltage converter is the device that also caps the outbut voltage at 3.3 volts.
Got it. Well, I would still be concerned that the I2C lines are not running at 3.3V. All things you can check when you get there, but a bummer that you have to make the trip.
Thing I might check:
Poke around for loose wires and see if the values go back to normal on the screen.
If other analog inputs show near-zero readings or are they also showing high values
Remove the output from the current to voltage module and see if A0 go to near-zero or stays high
Loose wires are, indeed, a target for investigation. I'll do that first to be followed by a swap-out of the Photon (my backup unit already has the same firmware file on it). I'll let you know what, if anything, I find.
Here's a screenshot from Amazon. It's been working all along, before the transition to beserko readings and since. The display matches the variables in my firmware.
Adafruit (and I'm sure others) sell a copper PCB with traces laid out like a protoboard for easy conversion. You just move everything over exactly the way it was and solder it on the back. They can be had in several sizes:
Another quick comment/question before start my 5-hour drive James:
Among the variables that I have built into my code is the query of the voltage parameter as calculated by your code from last year. Since the current problem arose, that query has returned a zero. Does that tell you anything? I don't know what that might have been before the issue appeared.
"double voltage = PHOTON_VOLTAGE_COEFFICIENT * averagedRaw;"
I don't really remember the details of your system, but if a low voltage reading corresponds with a high pressure reading then that would make sense. May be more likely to just be a loose wire too.
FIXED!! A 600-mile round trip to discover that the red jumper wire in the attached photo had come loose! No more 24 gauge jumpers; replaced everything with 20 gauge! Thank you everyone - yet again - for all your input. You can rest assured I feel pretty stupid.
In case it is of any interest, the last value in each 4-value comma-delimited string in the log - the zero or the one - indicates the last command sent to the pump (0 = off, 1 = on). I fixed the jumper issue between 2:19 and 2:49 yesterday afternoon when the float switch was still "satisified" with the amount of water in the tank. At 8:18, it "asked" for more water - sent a 1 - and it took an hour to refill.
