Remote pump control ideas.

[Dannyx]

Re: Remote pump control ideas.

True - I found it: page 74. The regulator is U5, which is THIS, so it takes a max of 15v on the input.

[Dannyx]

Re: Remote pump control ideas.

My project hit a snag right off the bat: the F767 board I initially chose for the build is not in stock, so I'm trying to find a replacement

I found this Olimex thing which is more expensive, but looking past that, seem to be roughly the same thing - still STM32...

[stj]

Re: Remote pump control ideas.

but if the configuration is different then it may not work with your arduino ide
just use a different supplier.

[Dannyx]

Re: Remote pump control ideas.

but if the configuration is different then it may not work with your arduino ide

I had this worry even WITH the Nucleo, though I did find a library for the Arduino IDE which put my mind at ease a bit...I wonder if the code can be easily adapted for boards other than Arduino, so instead of trying to use the IDE, I use whatever the particular board works with natively...

[stj]

Re: Remote pump control ideas.

go look at https://os.mbed.com/

about boards,
you choose the best, not the one in stock.
if your employer is playing the stupid "prefered supplier" game that i'v seen too often then they obviously arent too serious about doing things properly for clients.

[Dannyx]

Re: Remote pump control ideas.

go look at https://os.mbed.com/

Looks interesting. If I understand correctly, it's an IDE for ARM-based boards, which supports multiple platforms, doing away with compatibility issues that arise when limited to Arduino's own IDE. Seems a bit excessive for very simple projects like this one, but I guess it's a good idea to look beyond Arduino for becoming a "big boy"

There's also RaspberryPi which I've been wanting to get into...in fact, there's so many solutions it makes your head spin I imagine the proper approach for choosing one is based on the project: you don't send an Arduino up in space, nor do you use a supercomputer to turn on some lights, so I think knowing a bit of everything is good. They all seem to share the same language, so moving between them should be feasible enough, even for yours truly who is clearly NOT the sharpest pencil in the box

if your employer is playing the stupid "preferred supplier" game that i'v seen too often then they obviously arent too serious about doing things properly for clients.

To a degree, they DO have preferred suppliers, but if the job calls for it and there's no other option, alternatives are accepted, within reason, provided shipping is not a killer. For this project, I have a full list of parts and materials which I tried sourcing from TME, so we only have to pay the single shipping fee. Trouble is the Nucleo's not on there...

I have another project underway which could benefit from some small Wi-Fi-capable MCUs. ESP8266 might be a candidate. The idea is similar to the pump-tank one (client reports stuff to server which does stuff), except here there's multiple clients - one in each room - which should hook up via Wi-fi and sit in a corner somewhere to avoid wires and junk as much as possible....what "rooms" we're talking about and what the system is supposed to do is beyond the scope of this discussion and should be its own thread

[stj]

Re: Remote pump control ideas.

if you mess with ESP chips then make sure you know what your buying, some have an antenna socket, some dont - and the ones that do, you often have to enable it by moving an inductor or cap on the board.

problem with ESP's is a lack of i/o pins.
great for serial protocols to wifi or bluetooth(ESP32) but crap for loads of switches/transistors!

[Dannyx]

Re: Remote pump control ideas.

I/O count is not a problem, since for this next project I was talking about, the end goal is to essentially create some "ears" which light up the corresponding room number on a panel located in the night watch office to alert the staff if any of the newborns start crying - yes, that's right: I'm talking about a newborn ward at a private clinic here They also want this to double as a listener for any alarms given off by the incubators or whatever monitoring devices they have in these newborn wards........which I right away suggested is a VERY poor way of implementing this sort of monitoring when dealing with something this important. I insisted that we instead have a look at said devices to see if they don't already feature some sort of communication interface and use THAT instead (seems logical), but the management or whoever's in charge said I just go ahead and go down this other route, so I jut took off my hat and delivered (pun intended )...sort-of. I'm just messing with some mic modules I picked up off Ali for cents....not the most high-tech solution when considering we ARE talking about newborns and what could be time-sensitive situations Not sure how I feel about this...

[stj]

Re: Remote pump control ideas.

i personally wouldnt use any type of radio for safety critical alarms/monitors.
the liability if they get jammed at the wrong moment is huge.

[Dannyx]

Re: Remote pump control ideas.

That's a good point....guess they can spare an Ethernet jack in each room then Now to settle on an appropriate board. The STM one is.....kinda oversized for this application I think Still, Ethernet-capable boards tend to be overspec'd like this. Cost is another aspect, since I imagine there's like 5-10 rooms and I can't blow my budget on a single room...

[Dannyx]

Re: Remote pump control ideas.

I just thought of something I thought would be trivial but could end up being tougher than I thought: connecting multiple clients to a single server....not too sure yet what hardware I'll be using and how this affects the difficulty of this task.

For the pump project, this is easy: one client - one server, but here's there's several "ears" which have to report to the server which has to differentiate between them (separate warning light for each of them) and I don't think they can all hog the same port (23 in the case of the pump project)...I think I have to create multiple server objects on the server board and have each client connect to its own server. I think we're talking about multi-threading capabilities here which requires more advanced hardware...

[stj]

Re: Remote pump control ideas.

the clients just have to transmit 2 bytes.
a unique id, and a status byte.

[Dannyx]

Re: Remote pump control ideas.

I too thought it would be simple conceptually, but as I read online, there are some snags one might hit with this multiple-clients-to-one-server business, limited strictly to the Arduino world: you can't use the same port for both clients (not without extensive mods to the ethernet library) and you can't have more than 4 clients connected at once (limitation of the W5100 shield). In this case, I'm not sure how many rooms there are which need a client in them and whether this would be a problem.

I started looking into more advanced and exotic ways of doing this and found THIS. Trouble is I have never messed with a Raspberry Pi before and can't experiment anything at the moment because I don't have one.

Then there's also that Mbed for ARM boards....wonder how those handle TCP/IP and if it's wildly different than the library for the Arduino shields or still shares some concepts. Like I said, all these choices make a novice's brain hurt when having to choose the best one

[stj]

Re: Remote pump control ideas.

stop reading what your reading.

your stations listen and have a unique i.d.
your base poll's each station once per second and request the status.
if a station does not respond then it flags an error.
if a station responds with a status of "button pressed" or "fire sensor" or whatever then it sets the lights or display and does the sounder or whatever
simple

the stations themselves just constantly listen on the same port for a packet that contains their id byte.
if they dont match then the buffer is cleared, if they do match then they reply.
a router will multicast across all ports if you use the right packet.

[Dannyx]

Re: Remote pump control ideas.

stop reading what your reading.

your stations listen and have a unique i.d.
your base poll's each station once per second and request the status.
if a station does not respond then it flags an error.
if a station responds with a status of "button pressed" or "fire sensor" or whatever then it sets the lights or display and does the sounder or whatever
simple

the stations themselves just constantly listen on the same port for a packet that contains their id byte.
if they dont match then the buffer is cleared, if they do match then they reply.
a router will multicast across all ports if you use the right packet.

That's a different approach indeed. The way I had it set up was based on the pump idea where a client connects to a server and that's it.

Sounds like what you're suggesting is to have multiple servers instead and a single client which initiates the connection to each one by one....good idea in fact, though it requires some massive work at this stage.

So the servers just sit there waiting for incoming clients and when the single client hooks up (the "base" where the staff is), I'd have to have each server ("Station") report its ID and last status, then the client would have to disconnect, move to the next one and repeat. This means I'd have to move my "client.connect()" function outside the "setup()" section, since I'd have to step through the IPs rather than get stuck with a single one...just some random thoughts as I think about this. Nice idea, actually....will certainly keep me busy It also proves that I still can't think like a programmer and come up with solutions to problems - I take the "hard" approach...

[stj]

Re: Remote pump control ideas.

the "master" is the monitoring station with all the lights & shit,
the stations would be considered clients/slaves because they answer requests rather than making them.

and this method can also be used with multi-point serial like rs485
and wifi/bluetooth/descrete-radio modules - but i dont recommend those for the reason i already gave.

[Dannyx]

Re: Remote pump control ideas.

the "master" is the monitoring station with all the lights & shit,
the stations would be considered clients/slaves because they answer requests rather than making them.

Yes, but from a code perspective, I don't see a way for the "server" board to actually initiate the connection to each client. The commands here don't make it seem so at least. Server.begin() just makes it "listen" for clients, but IT can't actually send anything out until a client willingly connects and sends something first....I think...that's how I did it, but like I said, could be way better...the more you learn

What you describe definitely sounds a lot like Modbus which I read about.

[Curious.George]

Re: Remote pump control ideas.

I just thought of something I thought would be trivial but could end up being tougher than I thought: connecting multiple clients to a single server....not too sure yet what hardware I'll be using and how this affects the difficulty of this task.

For the pump project, this is easy: one client - one server, but here's there's several "ears" which have to report to the server which has to differentiate between them (separate warning light for each of them) and I don't think they can all hog the same port (23 in the case of the pump project)...I think I have to create multiple server objects on the server board and have each client connect to its own server. I think we're talking about multi-threading capabilities here which requires more advanced hardware...

You don't understand how protocol stacks work.

A TCP connection is defined by a 5-tuple:

(protocol, source IP, source port, target IP, target port)

A server can manage any number (depends on available resources) of connections.

For example (neglect "protocol" as we assume they will all be using the same protocol, in your applicaation):

(clientA IP, clientA port, server IP, server port)
(clientB IP, clientB port, server IP, server port)
(clientC IP, clientC port, server IP, server port)
(clientD IP, clientD port, server IP, server port)
(clientE IP, clientE port, server IP, server port)

Yes, the "server IP" and "server port" are constant, but, these are all different -- because each "client IP" is unique from all others. So, the server's stack knows that the first tuple is used to talk with clientA while the fourth is used to talk with clientD.

[Curious.George]

Re: Remote pump control ideas.

Yes, but from a code perspective, I don't see a way for the "server" board to actually initiate the connection to each client. The commands here don't make it seem so at least. Server.begin() just makes it "listen" for clients, but IT can't actually send anything out until a client willingly connects and sends something first....I think...that's how I did it, but like I said, could be way better...the more you learn

What you describe definitely sounds a lot like Modbus which I read about.

You have to choose how your system configuration is managed.

Do you "tell" someone that there are N clients and they exist at the following IP addresses?

Is each client told of the identity of its server? (what if there are multiple servers on the same internet??) Or, does each client "discover" the identity of the (single?) server?

Is the server told of the identities of each of its clients? (what if there are clients that will NOT be serviced by that server?) Or, does the server discover the identities of its multiple clients?

This decision has consequences. What if a client goes away? What if a new client is added? Are IPs statically assigned or dynamically allocated? Are certain IPs bound to certain MACs? etc.

Think about how you want the user/administrator to deal with your system before thinking about how to implement it.

[Dannyx]

Re: Remote pump control ideas.

Does each client "discover" the identity of the (single?) server?

I WAS planning on doing it this way, though I haven't actually TRIED it on the bench, due to a lack of both inspiration and hardware. Reading about it though, like I said, revealed some issues. On paper, it seemed like it'd be totally doable, as described - different IPs and junk - and makes perfect sense, but from a practical standpoint, apparently there are some limitations, like I said...at least that's what I've read when others tried the same thing.

Does the server discover the identities of its multiple clients?

Sort-of....This was the idea that came to my mind after what STJ suggested (EDIT: OK, no, he didn't actually suggest THIS, but I worked around it): have multiple servers which listen for the single incoming client - sounds stupid, but strictly from the perspective of the hardware I'm working with at the moment, it's the only workaround that I, the average Joe, sees Hence why I love discussing stuff like this and learning how more advanced chaps do it.

This is also why I was curious about how other boards, other than Atmels, handle Ethernet, because frankly I haven't left that realm yet, so I'm still in the stone-age so to speak...