I currently poll PLCs as a Master using Modbus/TCP, Modbus+ and Modbus depending on the communications available.

I have a new application for a rain gauge datalogger at a solar remote site only accessible by cellular. When it is raining, I would like to collect information every 15 minutes, otherwise I really don't care other than to confirm that the device is still available.

Currently, I have set everything up as a Master, to poll for 1 minute every 15 minutes. The datalogger itself is very low power, but the cellular modem in quiescent is 50ma is using 150-200ma to transmit and over a period of 4-5 dark days drains the battery to a level that the solar panel cannot recharge.

I am taking the first step of doubling my solar panel and tripling my battery, and will shorten my poll time to less than 1 minute.

But I am really wondering whether I should or can reverse my approach with the cellular devices acting as masters and whether it is worth the extra work. I could have the Datalogger itself, notice that it is raining, then turn on the modem, then send send data. We haven't used modbus here in that fashion before, so I am concerned how much work it will be and how reliable will it be.

GBrown

 

If you are using Modbus/tcp over cellular, keep in mind that there will be a lot of networking overhead traffic that deals with keeping a tcp socket open (eg ack's, nak's, etc.)

And all of that traffic will place your cellular modem into transmit mode and therefore run down your battery sooner.

Does your device support Modbus/udp? That's one possibility.

A connectionless protocol will cut down on the transmission duty cycle of your equipment, and it will also have the added benefit of costing you less in cellular data charges.

Hope this helps!

Jim.

 

Since there haven't been many other answers, I'll take a shot at this. There's no technical reason why the rain gauge can't be the client and your central data collection centre the server. The questions of course would be whether your hardware and software will support this configuration.

The key to saving power is usually to turn off as much hardware as possible when you are not using it. Again, I don't know how well your current hardware will work in this situation (e.g. will there be hardware failures if you power up and power down frequently).

You rain gauges will need to send an "I'm alive" signal to the central station regularly, so that you will know the difference between "not raining" and "broken". You will have to decide on the frequency of that check based on how long you are willing to go without knowing about a failure. Your software at your base station will have to keep track of these reports to check on the rain gauge stations. The rain gauges could do something simple like increment an integer in a register each time they report, and the software at the central base station could then check for changes in those registers.

Given your polling frequency, I don't think that changing to UDP would help much if at all. You should only transmitting for brief bursts, so the main power consumption should come from just keeping the hardware powered up.

However, you said you are currently polling at 15 minute intervals. Are you holding the connection open, or closing it and re-opening for each polling cycle? A lot of systems will close a socket if nothing has been transmitted for more than a few minutes. Are there any "keep alive" signals being sent back and forth over the connection? This might be happening at a lower level than your application code sees (it might be happening somewhere in the wireless system). If you are holding the connection open continuously, try closing it explicitly and seeing what that does to power consumption. There might be a lot more transmission events going on than you realize.

I believe that what some people do is to have the field stations wake up and listen for a certain time window, and then go back to sleep. For example, they may listen for a 10 minute window every hour (obviously you have to keep the clocks synchronized). If your total cycle is 15 minutes however, that would be much harder to arrange as your windows would have to be correspondingly narrower.

 

Thanks, after the previous two responses, I did go look at my monthly totalized traffic from AT&T and it is a lot more than my initial estimates. I will look into the keep alive, but this traffic may be from the logger webpage that people have been using while I have been testing.

GBrown

 

Having worked closely with cellular for many years, be aware that AT&T rounds up per hour per socket - so you'll be charged at least 1K per hour regardless. Plus most cellular systems just flush/drop any TCP socket which has been idle longer than 5 minutes. I don't mean close - just drop it, so your master will try a second poll and just see no response (no RST, no nothing).

Plus you are being charged for the IP headers, TCP headers, any TCP ACK/retry packets. You are charged for any port probing - so all of the those script-kiddies looking for open emails relays or trying to poison your DNS cache cost YOU money - that is if you have a fixed or dynamic IP (but not if you have a private/non-routable IP).

So changing to have the rain logger act as a Modbus/TCP master/client could save you a lot of data plan. For example, it could connect home at least once per day, but upload once per 15 minutes during rain.

My own tests with TCP keepalive vs open/close show 15 minutes about the break-even point, where the added cost of reopening a closed socket balanaces the TCP keepalive every 4+ minutes which would keep the idle TCP socket healthy.

Plus one huge value in this "rain-guage-as-master" design is that it allows you to not require fixed or routable IPs on your cell plans. This gives you wider options and less cost.

Using a private/non-routable IP (like 10.x.x.x) from AT&T means no-one can ever push traffic at you, which you get billed for. I bring this up because we've had large customers literally get monthly bills over $2 million due to DNS attacks upon their cellular fixed IP addresses.