Remote pump control ideas.

[Dannyx]

Good day folks. A task was given to me to redesign the control system for a pump system in a remote location. The idea is that there's a tank which has a float or some sort of switch/sensor to detect when it's full/empty and this runs some pumps accordingly. The trouble is the pump and the tank are like 4km apart, from what the chap who inspected them on our behalf told me, so the way this currently works is by using some unknown boards based on SIM cards (see the pictures). From what I can assume, when a contact closes at the "client side" (the tank), it calls up the "server side" (the pump) and tells it to switch on one of its outputs. The problem is they've been having really bad reception in the area and there were times when the float switch failed to tell the pump to stop, which caused the tank of overflow, hence they want to switch to a wired connection which our company will provide, but first we have to redesign this to work over ethernet.....

Not wanting to reinvent the wheel but also not wanting to blow a fortune on PLCs and equipment that's not needed and possibly exaggerated for such a purpose, I was thinking of making my own system from scratch, though I don't know much about programming I DID play with this example for the Arduino a while back, as some of you may remember when I was working on reading sensors remotely from those sewage treatment vats we were working on.

I got it working up to the part where I was able to send commands to my arduino "server" just like in the article, by using that "Hercules" client program. What I need to happen in this case is to have an arduino on one side acting as the client and another one on the other side as the server, talking to each other over ethernet. The way I picture it, the server side which is to sit at the pump, is technically functional (the one above), so now I need to design the client end which replicates the commands sent by the Hercules client. The client would read the input from our float switch or whatever on one of its pins (or several, if there's multiple floats - not sure yet) and send a string out over ethernet which the server would pick up, strip down and identify what it's supposed to do....at least that's the idea.

This is the most basic version. A more advanced one would also have a webpage which can actually monitor the status of the pump/tank level and also have protection features. I worked on this too at some point, but I stopped part-way because I couldn't get the SD cards to work and I just gave up at that time. Thoughts and suggestions please ? As always, thank you for your time to put up with a noob !

[Spider1211]

https://www.controllino.biz/ might be worth a look. Why not add a capacitive level sensor as redundancy?

[diif]

Does the antenna exit the metal cabinet ?

[Dannyx]

Originally Posted by diif

Does the antenna exit the metal cabinet ?

Haven't seen it myself, though that would be pretty stupid....plus I expect SOMEONE had some brains there

[stj]

ethernet? why?

ethernet has a 100m range before you need a repeater.
better to use armored fibre-optics
or twisted pair running high voltage like RS485

[Dannyx]

Originally Posted by stj

ethernet? why?

ethernet has a 100m range before you need a repeater.
better to use armored fibre-optics
or twisted pair running high voltage like RS485

Ok, ethernet is indeed incorrect. INTERnet would be more like it - there's isn't actually a cable running between the two - each box has its own internet connection and we have to make them talk. Ethernet would only be locally inside the box, between the GPON or router or whatever and the device we'll use, so I was wrong there.

[stj]

btw, in your first photo - some asshole has cut a lot of the strands on the battery cable.
was that intentional to fit the terminal - or just fucking careless??

[stj]

Originally Posted by Dannyx

Ok, ethernet is indeed incorrect. INTERnet would be more like it - there's isn't actually a cable running between the two - each box has its own internet connection and we have to make them talk. Ethernet would only be locally inside the box, between the GPON or router or whatever and the device we'll use, so I was wrong there.

then you just need a microcontroller board with ethernet.
i would use a nucleo board from ST - they are really cheap and you can use the arduino compiler with them.

[Dannyx]

Originally Posted by stj

btw, in your first photo - some asshole has cut a lot of the strands on the battery cable.
was that intentional to fit the terminal - or just fucking careless??

Seeing how the positive lead next to it seems intact and it's the same thickness, I'd say it was simply a case of "mneh - good enough" approach and they just left it like that...I'll be sure to solve that issue too when I go there.

That board looks interesting. Since I already have SOME example codes, I wonder if they work directly on that board too, aside from the pin numbering (registers).

[stj]

Originally Posted by Dannyx

Seeing how the positive lead next to it seems intact and it's the same thickness, I'd say it was simply a case of "mneh - good enough" approach and they just left it like that...I'll be sure to solve that issue too when I go there.

That board looks interesting. Since I already have SOME example codes, I wonder if they work directly on that board too, aside from the pin numbering (registers).

well the nucleo series are a bit like arduino - only 3.3v and MUCH faster.
so you also need to design a board to buffer the inputs and provide some relays - judging by what is in the foto.

it may be good to design an io with a small mcu and talk to the main board over i2c.

[Dannyx]

Originally Posted by stj

it may be good to design an io with a small mcu and talk to the main board over i2c.

This could get complicated, though it makes sense.....I have a limited amount of time to come up with a viable solution

[diif]

Originally Posted by Dannyx

Haven't seen it myself, though that would be pretty stupid....plus I expect SOMEONE had some brains there

Yes, it would be stupid but not surprising, looking at that photo.
What's the thin cream cable at the bottom of the photo if not the antenna ?

[Dannyx]

Originally Posted by diif

Yes, it would be stupid but not surprising, looking at that photo.
What's the thin cream cable at the bottom of the photo if not the antenna ?

Probably that's where the wires exit the box...

[stj]

the joke is that at those frequency's your getting huge losses in the cable.
they should have flipped the board and mounted the socket against the case top for a direct antenna connection.

[Dannyx]

Not to mention I don't know how long the cable is outside the box either, so a couple of more meters there too

[redwire]

I have:
1. Used private radios with yagi antennas at each end. Like 900MHz band.MDS TransNET
Only works if you have a clear line-of-site. Any hills or valleys in the way and you can't do it without a repeater. Once I put that on a cell tower that would lease the space.
Tree leaves cause problems because water in the leafs absorbs microwaves. So every spring the network would go down when the leaves came out. You need need a tall antenna mast to clear the tree line, it's a hassle over 20ft due to lightning and wind etc.

2.
RS-485 coms. The difference in earth-ground potential caused problems. Lightning surges always zapped the transceivers. I had to add RS-485 isolation, and then the network was reliable.

3.
Used cellular phone modems. With a yagi pointed at the tower (not pump house lol), they can have good signal. The problem is if the network goes down, or SIM card account not paid up, it's not that reliable.


You really need the ability to call out and tell someone the communication link is not working. It should ping and check often.

Trenching and laying underground cable is very expensive.
With buried metal pipe, you can use a VLF radio signal on the pipeline, just like data over powerlines.

[Curious.George]

Originally Posted by Dannyx

Ok, ethernet is indeed incorrect. INTERnet would be more like it - there's isn't actually a cable running between the two - each box has its own internet connection and we have to make them talk. Ethernet would only be locally inside the box, between the GPON or router or whatever and the device we'll use, so I was wrong there.

Ethernet is a particular hardware communication scheme.

*An* "Internet" is an interconnected group (typically of) computers.

THE Internet is the global network of interconnected computers.

Note that an internet need not use ethernet, at all.

And, an internet need not use the TCP/IP protocol suite.

There's little need for ethernet on a shorthaul between devices in a box -- unless the hardware (and software) was effectively free.

[momaka]

If there is clear line of sight between the two sites, what about implementing some kind of laser comms? Though I imagine that would require at least periodic checking of the laser alignment between transmitter and receiver. And there are some other difficulties around laser comms too... but yeah, just throwing an idea out there for fun, if nothing else.

[Dannyx]

Naah, our company already ran the necessary cables (or maybe even fiber - don't know yet) to hook up each site to that town's network, so we'll have to stick with whatever can be done over a LAN/WAN.

[stj]

it's piss-poor security to use a public network.
typical corporate scumbags.