Remote pump control ideas.

[Dannyx]

Re: Remote pump control ideas.

Good idea. I DID plop a single diode in series with the supply to the board + a single electrolytic, but I guess I should be increasing that capacity, add ceramics too and switch over to a FULL BRIDGE RECTIFIER ! Not sure what the values of the caps should be though...

[stj]

Re: Remote pump control ideas.

solar charge controllers are usually pulsed dc and they regulate current rather than voltage.

you should make a small board with a bridge rectifier and some smoothing caps - electrolytics for bulk and film/ceramic for speed.
put it between your power and the nucleo and any other electronics your running.
use a bridge instead of a single blocking diode because it gives you full blocking together with protection from some dick in the future putting a replacement battery in the wrong way!!

and dont power from the solar - those panels can go well over 30v on low load.

[Dannyx]

Re: Remote pump control ideas.

Thinking the power situation at the tank side is a bit funny with that whole "power coming on at night and going out in the morning", I thought I'd update on how I ended up working around that too. Thing is, this solar controller uses common positive, also confirmed by its instruction sheet and by measuring (all + terminals are tied together), so I had no choice but to toggle the negative wire between the cell and the supply I added via a relay. It works, but I noticed the charge controller doesn't actually regulate the output to the load - same voltage that goes in to the "cell" terminals, goes out to the "load" terminals. So if I set my power supply to put out 15v, 15v come out the "load" terminals, which concerned me a bit, since it means it's also being pumped directly into my Nucleo board, which although IS set to use the onboard regulator which can tolerate it, it has to work harder and dissipate more heat. I was hoping the charge controller would do some regulation of its own, so I could raise the voltage on my SMPS a bit more to like 15v+, while still getting stable 12v at my load terminals and enough juice to charge the battery, but I can't quite do that without stressing the onboard reg......

The reason I'm even mentioning this is because I'm more concerned about this behavior occurring due to power issues and the "server" may be locking up...

[stj]

Re: Remote pump control ideas.

CUBE is bloat.
what most people use is OpenCM3
https://libopencm3.org/

[Dannyx]

Re: Remote pump control ideas.

technically you should be using GCC and a text editor - but nobody has time for bare metal programming anymore

True - I noticed in Cube or whatever, you have to define EVERYTHING, every "device" like SPI or Ethernet requires explicit code to be added - NOT beginner friendly indeed, but a lot more powerful in the long run indeed....I WILL persevere with this and try to do it the way the smart guys over at ST intended to !

[stj]

Re: Remote pump control ideas.

technically you should be using GCC and a text editor - but nobody has time for bare metal programming anymore

[Dannyx]

Re: Remote pump control ideas.

As a refresher, to bring this discussion up to date again, we are using two Nucleo144 boards. The chip on them is the STM32 F767ZI. We're doing the code in Arduino's IDE. I know ideally we should be using Cube32 (or was it Eclypse ???) to play with ARM boards, but the time was rather short and since I was the one who started this whole ordeal, we committed to Arduino for now, at least until this crisis is over and we can actually start learning Cube....

I'm not sure how well these boards were "ported" to the Arduino, so there may be bugs right there, since they're NOT meant to "work" with the Arduino IDE - it's mostly a shorthand for us beginners

[sam_sam_sam]

Re: Remote pump control ideas.

This might be a stretch but depending on what type microcontroller that you are using
There is a difference between endif and exit commands so if there are different ways end a programming loop and then you want to exit the loop because a input is true or false depending on what you want to do try different way to jump to another command line or loop until the statement is true or false depending on what you want it to do

I have had this kind of issue before and some time one command works better than other command depending what you are trying to do

I hope this helps you

[Dannyx]

Re: Remote pump control ideas.

My buddy messed with the code some more today, mostly on the "client" side, though this mostly consisted of adding "checks" here and there, in the form of Serial.println(""); to imitate a debugger (since the Arduino IDE doesn't have one) to see where the code halts or what some of the functions return, so it wasn't meant to be a "fix" by any stretch of the imagination, but ironically today it started working after he added a "client.available();" after the "reply" the "server" sends over to the client. It makes no sense, because he added this line AFTER the reply the server sends out, so it makes zero sense as to how this affects resuming from a connection drop ! Even if the function HAD some sort of relation to this, the server would not be able to send it to the client, because they're already disconnected at that point (either by unplugging the network cable or cutting the power to the server) !

I DID notice one thing: while we were stress-testing this, still not quite sure how it just managed to fix "itself", I started contemplating the possibility of noise or electrical interference again ! To check if the client manages to connect back to the server after a connection drop, I of course unplugged the "server" board from the USB charger we were using. Sure enough, the connection dropped, the "client" went into its "comErr" loop, then I plugged the "server" back in, it did its thing, grabbed an IP and the client reconnected ! I did this by unplugging the micro-usb cable from the board end, but left the charger itself plugged into the power strip. However, when I attempted the same power-cut thing by unplugging the whole charger from mains this time, the connection didn't resume ! Instead, the "client" once again detected the drop, went into its "comErr" loop where it's supposed to try to reconnect every x seconds to the server as it should, but when I plugged the charger back into the mains and powered the "server" back up, the "client" board froze ! This time though Ethernet continued working and I could still ping the board ! Still, the main loop was frozen, as we were no longer seeing the Serial.println("FAIL"); message which was supposed to roll after each failed attempt at connecting to the server ! In other words, when if (client.connect(server, port)); is called, we get either a fail or a success and this is inside a loop, so if the connection fails, my buddy added a Serial.println("FAIL"); to the "else" part of client.connect, to let us know if the code is at least looping and trying to connect. This time, we were not getting ANYTHING in the serial monitor ! I think what happened this time is the "client" board (which WAS attempting to connected to the "dead" server as it should), was a little too close to the power strip and the spark that occurs naturally when the plug of a SMPS is inserted into a mains plug MAY have just messed it up enough to halt the code, so even though my "server" was now up and running, my "CLIENT" was not even attempting to connect to it !

The same thing happened yesterday: we had both boards plugged into the same desktop PC via USB. I'm not sure if some sort of ground-loop occurred or whether it had something to do with the switch we had the LAN patch cords plugged into (which is the same one we used today, so NVM) or whether there was some software bug related to having two COM ports going on at the same time, but basically it DID - NOT - WORK - AT ALL that time: it'd only get like 1-2 replies from the "server", then the "client" would quit, to the point where not even pinging it would work ! Today, this chap brought in his own laptop to work on, so one of the boards was plugged into his laptop.....This is grasping at straws, but again: maybe there IS something going on there beside just code bugginess.......:|

[Dannyx]

Re: Remote pump control ideas.

Ok, my bad: I missed an important detail: we're trying it out on ANOTHER set of boards in the shop - not "the real deal", so the only think I got attached is a dumb toggle switch on the "server" and a multimeter on the "client" to read when various pins change states - not even LEDs, since we don't have them on hand We're powering them via USB, though it's worth mentioning they're powered from the same PC....not sure if this would cause stuff like ground loops or other electrical nasties that may cause ONE of them to freeze - always the client though !

For reference, THIS is the thread I launched over at Arduino to see if someone pitches in. I haven't yet updated it with these last findings though, since they all happened today as we speak...

[stj]

Re: Remote pump control ideas.

so it freezes after changing io state.
look at what your driving and if it can create a spike or voltage drop.

[Dannyx]

Re: Remote pump control ideas.

Ok folks, here's the situation with this project: I thought I was all done with it, but then I started having a lot of issues where the "client" board (at the pump end) would just stop responding and freeze entirely ! I enlisted the help of a friend of mine who's way better at programming than I am and we managed to - in a kinda-sorta way - isolate the issue, at least partially: we noticed the "client" board likes to freeze right after it receives a reply from the server.......but not always ! It's very sporadic and hard to pinpoint ! At this point we concluded it's probably a library issue and I'll try getting in touch with the creator....

Long story short: board freezes sometimes, but NEVER before actually getting a reply back from the server, so the problem workflow is like this: client starts up > client obtains DHCP address > client connects to server > client sends out a "POLL" message > server gets "POLL" message and sends a reply with the state of the switch (ON/OFF) > client gets the ON/OFF message > client GPIO pins act accordingly > client board freezes.

Other times it does it several times, but still ends up freezing ! The lock-up is so bad that the client board can't even be pinged from a command prompt at this point ! It's like the ethernet stack quits or gets stuck somewhere in the background. Not even the main loop runs ! NOTHING ! It just sits there mocking us ! It's not a hardware fault - I swapped the boards around

[stj]

Re: Remote pump control ideas.

lol
yea, been there - done that!
nothing better than having to put loads of caps and resistors back!

[Dannyx]

Re: Remote pump control ideas.

nice - getting the pins aligned must have been a bitch!

No - it wasn't nearly as bad as I was expecting it to be (especially since I'm recently coming from a failed ITE chip replacement on a laptop board). I'd call the pitch "generous", as opposed to that ITE chip which is way finer. The tool which helped the most was a vacuum IC picker which I recently acquired, which made sure I wouldn't drive the chip sideways into any components when attempting to pull it off - it happened on that laptop board and I pulled my hair out !

[stj]

Re: Remote pump control ideas.

nice - getting the pins aligned must have been a bitch!

[Dannyx]

Re: Remote pump control ideas.

I also fixed the STM board which had died. I replaced the main IC and it works, so I now have my own board I can mess around with

[Dannyx]

Re: Remote pump control ideas.

Back on this project, it just dawned on me that I can leave the solar system in place as it is as well, since it doesn't hurt to have an additional backup system in there....not sure where I should drop my mains power supply though.

I was thinking of wiring its output in parallel to the existing battery directly (first doodle), though I'm not sure the solar charge controller likes the voltage from the AC supply feeding back into its battery output. One of the power supplies I linked to apparently has a diode for the "battery" output already built into it, which is why I added one in red inside my "power supply" there. I'd set the output voltage of the supply slightly higher, to around 15v, and this would eliminate the need for a 12v regulator, since I'd be using the charge controller itself as a DC-DC converter.

There will obviously be a time of the day when BOTH the supplies would be "on" and try to pump current into my battery there....not sure if that's a good or a bad thing and whether I should use a small-ish value resistor in series with one of them to prevent killing the battery in some way.

Other examples even show the mains supply being fed into the solar cell input of the charge controller and toggling between which is being used via a relay (second doodle). The upshot of this is that the charge controller now also handles the charging of the battery when "on mains" too. The downside is that DC arcing may be an issue + the beefy wires coming from the solar cell in this particular case would be a nightmare to shove into a relay socket

[Dannyx]

Re: Remote pump control ideas.

Have you confirmed the power will be on and off with the lights ?

Yes, the chap called me yesterday to let me know of this project and said the power would indeed cycle on and off with the lights, plus these are some simple light fixtures perched on top of some concrete posts, on the outskirts of a village, not some proper lamp posts (which may house a contactor for switching, or however it's done), so I don't think they've got anything more than 2 simple wires running to each of them, so they'll just tap into these and run a pair to the shack too.

[diif]

Re: Remote pump control ideas.

Of course, this means that power to my shack will continue to go out and come back on, but at known intervals, along with the lamp posts in the village which also turn on and off at dusk and dawn respectively. So I still need that battery in there, but at least now I can charge it.....how ?

Have you confirmed the power will be on and off with the lights ?
UK street lights are switched inside the lamp post.

[Dannyx]

Re: Remote pump control ideas.

78s05 can supply 1.5-2A

so how much current at 5v do you actually need?

Realistically speaking, none - unless I switch the jumper on the STM32 to run on 5v instead of 12v....