Hi Trevor
Think about your input to the GPIO. If you are going to monitor, it is the small pulses (motor running) you are going to have to amplify and monitor. These are going to have to be amplified to a useable level at the GPIO input. The large pulses produced by the inrush current are a fact of life and will be amplified also. I can’t think of any way around this. These are something like 10 times the running pulses (as per your scope screen shot) which is pretty normal so will finish up way to big.
I would suggest connecting the resultant positive voltage from the capacitor to the GPIO via about a 10k resistor, deciding on the voltage the GPIO will tolerate and fit a Zener diode of the appropriate value from GPIO to ground. Cathode to GPIO. This will catch anything above this voltage and shunt it to ground. The 10k will prevent excessive current.
As the nature of this sensing can be somewhat spasmodic and can change with motor load this sort of insurance is pretty mandatory and will enable you to set the gain so you get a reliable signal at all wanted situations.
You should be aware that should something happen like a mechanical pump malfunction which causes the motor to stop turning with the power still on the current will rise to something maybe a little more than the inrush current and will appear at the sensor like the larger signal. Your monitoring system will not see this as a fault and know the pump has actually stopped so I assume some provision has been made to cut power under these conditions. Any form of fuse or circuit breaker needs enough delay to allow the normal inrush current without tripping.
I don’t know how far the ESP32 goes up the reliability scale but with Pico etc you are dealing with hobby stuff here and should maybe think about how critical your use is.
Cheers Bob
I have had some iitial thoughts about the reliability issue… although much of my time has been spent just figuring out how to make this stuff work at all! Now I am closing in on the basic functionality being ticked off, I’ll have more time to develop the higher level code. I have already built in setting off alrams if the pump keeps running when my tank is full for example, and plan to have all this hooked up to Home Assistant in due course… but still, the issue remains of what happens if my entire system simply fails?
I have two pumps… one, filling my holding tank (referred to as the bore pump), the other is a pressure pump feeding the house from the holding tank.
If the bore pump does not turn on… my tank empties. Not the end of the world, taps stop supplying water. I’ll notice soon enough! Of greater concern is what if that pump does not turn off? The way things are constructed, the tank silently overflows and it is extremely unlikely anyone would notice… the bore could be running for days, or even weeks. NOT GOOD! This is really the only significant risk of automating this setup. Of course, building things to fail over to OFF will help. I think second level monitoring in Home Assistant (another thing I need to build and learn) will hopefully be able to provide a suitable alarm if this pump is running for an extensded period, ie way longer than it takes to fill my tank (about 5 hours).
The other pump is the one I have the current sensor deployed to detect its status. Why? Well, running when it shouldn’t be is an indication of trouble, either a leak, or perhaps a toilet cistern that has not messed shut off. Again, not life and death crisis, but alerting me to the fact would be sweet. Currently, sometimes in the middle of a still night I can hear this pump running or cycling… sometimes I might not hear it. Sounding a piezo or whatever should do the trick!
Anyway, this is all system logic, above the “maker” stuff that I really needed help with. Still not enough hours in a day to absorb everything, this project has already dragged on way more than I anticipated… I am keen to complete it! Nearly there… I should receive my ESP32 with onboard transceiver and a Pico transceiver for my main unit next week, and I can (almost) bring things to a close.and move on. At last…
Glad to hear you’re reaching a conclusion with this, always good to hear someone has learned something/completed a project.
Re: the tank overflow issue. I think setting an alarm for an appropriate length of time is probably the best solution you’ll get without spending a bunch more time/energy on this. You could always play around with a water sensor of sorts, such as this one, but I generally feel like avoiding parts near water is your best bet. I can’t think of a good spot for a sensor like that where it would be safe from corrosion/the elements (provided I am envisioning your setup properly), which will just lead to extra maintenance and less reliability in the long run.
Well done with this, having it hooked up to home assistant will be pretty neat!
Pretty close to it though. I can see your problems when on tank water. No waste is very preferable. I sort of grew up on tank water but had plenty of rain in the Southern Highlands.
Everything failing SAFE requires some thought. I think just as important is some sort of override system to bypass automation so you are not completely out of water.
If you were looking for something more robust I personally would think small PLC or the very useful Mitsubishi “intelligent relay” Alpha Series programmable devices (the “relays” can be open collector or contacts, optional) or similar. I know of an establishment where there quite a lot of these things winding coils, varnish dipping, baking oven control, Auto welding control and general test automation. All have proven extremely reliable and I do not know of any failures for over 20 years now.
Puts the old grey matter to the test what?
Cheers Bob
Hi Trevor
Got to simulate the relevant part of your circuit. I used the following circuit with the values you show.
The pulse I set was period = 20mSec, width = 10mSec , rise and fall times 3mSec to look something like a half sine wave with the following result.
The thickening of the red trace is a few mV of ripple which should not bother you.
The bit I don’t understand is I set the pulse amplitude to 5V and according to my reckoning the result should have been (allowing for the voltage divider effect of the 2 resistors) 4.8 to 4.9V. But as you can see it is just below 3.2V.
This simulator is the inbuilt into KiCad so if I get a chance over the week end I will repeat with Tina and see what that result is.
Cheers Bob
Interesting. Agree you would expect the final voltage to be higher.
The advantage I have with a trimpot in the circuit is I can just tweak the gain of the op amp so that my output voltage, measured on the CRO, is around 3.3V… which is what I did, of course.
Again… remember that for my purposes, I only need to reliably distinguish between on and off. A bit of a no-brainer. Thanks for sharing the simulation, I’m interested to follow up. but don’t knock yourself out!
I did get KiCAD, for now I am persisting with fritzing, as it does seem well-suited to folk messing with Arduino/Raspberry boards etc, ie, it has a whole suit of boards, sensors etc all pre-defined. KiCAD is no doubt more sophisticated, not sure if it covers this aspect as well as fritzing.
When I have more time (hah!) I intend to return to KiCAD…
Hi Trevor.
I think I have found the problem with that simulation. The series diode (D2 in your circuit) is required to prevent the cap discharging back via the source. In my simulation I did not include this and the final voltage is the AVERAGE of the pulse train. which for a sine wave is 63.7% of the PEAK value. For 5V this is 3.18V which is about what you see. This would be about right for my very bad square wave with 3mSec rise and fall time, more like a sine wave approximation which is what I meant to do. If it had been a square wave the average would have been 50%.
I don’t seem to get any sort of diode recognised in that (pretty basic) KiCad simulator but will try TINA later on when I get home.
But I will get to the problem of no diode recognition. Just for interest if nothing else.
Cheers Bob
Correction: The AVERAGE voltage of a half wave rectified sine wave which is what I was trying to simulate (and what you have) is 31.83%. So back to square one with simulation. But the result is rather suspicious. For interestt I will do a bit of sleuthing.
Hey Bob… just reviewing things, I see I missed your post about the PLC… sorry.
I finished messing about in fritzing… and did go back and take another look at KiCad… seems it does PCB, but I didn’t see anything equivalent to fritzing’s breadboard view, which for me as a beginner, is actually qute handy, during development/experimentation.
Anyway… latest development is today I received a couple ESP32 WROOM boards… and finally got one talking. The plan is to replace the wires from my opto-relay pump control with RF transmission. But… it looks like I’m in for another learning curve now deveoping software on the ESP platform. Dang… I feel more late nights await me… ;-( I have no idea about the ESP… got an example program running… in C, from the Arduino IDE. I was programming in C back in about 1981 (on one of the first Unix systems in SA) so am fine using C… or Python.
The water detector you referred to won’t cut it for my purposes, but thanks for the suggestion.
Briefly, I have rigged up a 90mm PVC pipe connected to my water tank, and can detect the water level in it using the VL53L1X sensor… but, there were issues. Initially, it would only read to a distance of about 450 mm or so before it gave up. I need it to detect nearly 2 meters…ie, when the tank is low/empty.
The solution I found: spray paint the INSIDE of the PVC pipe matt black !! Boom… VL53L1X now detects my little white floaty “reflector” all the way down! Sweet. I’m back in business…
Anyway… that little problem was solved several weeks ago. SInce then, focus has been on monitoring a pressure pump… Bob has helped a lot with that!
It’s all coming together now… but I dont want to run cables from my tank to my switchboard… so thought RF Transceivers sounded the way to go. Which brings my to my next challenge… get my Pico (soon to have a Transceiver board tacked on) talking to an ESP board… with built-in RF thingy.
