Probably not if heavy/regular or time critical control/downlinks needed (for all those nodes!) and if looking at 100bytes x 247 nodes per 2hrs that is (simplistically) a continuous stream - not allowing for dutycyle limits/breaks etc, which would be a problem over a single radio link (remember downlinks will kill uplink capacity also further reducing available capacity, increasing latency and also causing potential lost messges - application would need to be resiliant and allow for that). Can’t tell anymore as Nick has developed a heavy redaction hand of late removing user posted info inc .pdfs (jpg’s & pngs can be poisoned as much a .pdf’s) (‘Save target as’…run virus/malware scan…view content…?, vs blindly click and open with attendant virus risks? per good internet health practice;-) )
Having a radio per node would be well within a typical gw’s capacity (though obviously more expensive to deploy) or perhaps some smaller fraction sharing - decimate? 25 radio modems with <10 end nodes each?
Before we carry on, it would be worth you re-reading the responses and clarifying some of the issues, the most important one remaining in the diagram - a gateway connects to a LoRaWAN Network Server and sends out the uplinks in a number of formats that are almost entirely comprised of JSON with a few that are JsON and a couple that are JSoN - no TCP is harmed in the making of LoRaWAN uplinks.
So controlling anything via ModBus TCP/IP is going to need some serious definitions on what you expect.
And the desperate lack of off the shelf ModBus TCP/IP to LoRaWAN devices.
As Jeff points out, it’s not clear exactly what “100 bytes every 2 hours” is - it could be per sensor or it could be for the entire buoy. Depending on the number of devices, the former may get bogged down with just one device, if the latter, then you’re good to go - although I’d cut it up in to smaller packets with some overlaps so you get some of the new fangled Forward Error Correction everyone is trying to add to their AI/ML systems!
The ultimate number of nodes is somewhat fluid at the moment - I’m guessing about a dozen in the near term (12 months). But, the client is adamant that he wants to use Modbus TCP because that version of Modbus allows >247 nodes. If the number of nodes increases, then presumably we need to add more gateways but there is probably some hard limit to how many gateways can co-exist in one area?
Each of the 16 sensors produces 3 or 4 bytes of data. 100 bytes is a conservative value for data payload planning purposes. IOW, 100 bytes is the data payload for one complete buoy.
So why insist on ModBus TCP/IP - indeed, why not wire the sensors straight to the device (or node, something that can read readings and send it out via LoRa as a LoRaWAN formatted waggle of the bits).
There are many many devices in the LoRaWAN range for reading sensors and it removes a point of failure. And it’s affordable - you could have two devices with duplicate sensors for the critical data.
LoRaWAN comes in to it’s own with the deployment of devices - you just do it! All the action is back on the server, the gateway just listens out for appropriate radio packets & passes it on - you don’t register anything on the gateway.
However LoRaWAN is still not a great option for command & control - you need to figure that it may take more than a couple of tries over a space of 10’s of minutes to get a message back - and that’s the optimistic version.
Sure, but they are mostly passive listening devices.
I think the OP had it in mind that a device & a gateway were somehow linked and that throwing more gateways at the situation would solve the problem whereas the maths wasn’t clear on how many sensors / uplinks / buoys were in the mix leading to Jeff’s calculations showing a worse case scenario!
Over the years I have seen many Buoy based deployments for LoRa and later LoRaWAN but not yet seen anywhere there was a need for local deployment of >247 nodes (sensors)! Curious to know more on the application. The three main catagories previous cases have fallen into have been
Environmental monitoring/weather - no significant downlink activity: Half dozen to dozen or so sensors for each - air temp, water temp, water salinity, barometric pressure, wave height (displacement/accelerometer sensing), local battery, wind speed/direction, light level, etc. with local aggregation and stats generation sending overview messages - non-realtime)
Agri/Fisheries monitoring - little downlink activity: dozen to maybe 2 dozen sensors covering similar to (1) with addition of (fisheries) net monitoring, additional water quality monitoring, multipoint temp & flow(rate) monitoring etc. rope/chain monitoring (Mussel farming!), etc.
O&G/Energy - under water infrastructure monitoring - some of which was Mod-Bus (& IIRC RS485?) based - but main data path and feeds/command and control was over field to shore fibre links with several out of band device to bouy wired links with the LoRa-Buoy providing a seperate telemetry and alarm feed to (cliff top & rig GW’s). For off-shore wind farm monitoring also saw GW on turbine tower with buoy to GW collection of local data (similar to (1)) plus some additional installation related data - with the GW (actually several per field for redundancy) then backhauling over farm to shore redundant fibre links…
I’m not privy to the specific application(s) of the system - all I can share with you is what I’ve presented here so far. I can reiterate - minimum of 247 buoys (nodes) is a hard number.
I understand the rationale and it’s appealing but the use of a Programmable Logic Controller on each buoy is not open for debate. Other functions are involved which (probably) don’t lend themselves to direct interface with a LoRa unit.
Please stop calling buoys nodes - you could have 25 devices aka nodes on a buoy - it just confuses what is already a muddled set of concepts on the application of LoRaWAN.
If a PLC is needed for other things, that’s fine - but why channel sensor data via a PLC, or just snag the PLC only data via serial.
Not a problem. Not even with 4 nodes on a buoy, however I agree with @descartes you make this discussion harder by not calling things what they are from a LoRaWAN point of view.
The thing with the radio is a LoRaWAN end device (often called node) that periodically sends data to a LoRaWAN network server (NS) via a gateway. Gateways connect to an IP network but talk UDP or TCP to the LoRaWAN NS only. Not modbus tcp or any such protocol.
You can retrieve data from a LoRaWAN NS using integrations that are provided by the party running the network server. If you need another protocol you need to get the data there and translate it to your required format before sending it on.
There is an option to send data to the end device via the NS as well, however this is very limited (think 1 or 2 times a day, more will impact the number of end devices that can be deployed in an area).
That should not be an issue, however you will need to find an end device that talks the same protocol the PLC speaks when it attempts to send the data. I haven’t seen any using modbus tcp yet. I am sure someone will gladly design and build one for you at the right price.
it sounds like you need to customeized a Lorawan to TCP/IP device, with Class C communication, the good thing is it looks like you don’t need to take care about power consumption, compare to the PLC, the power used by Lorawan node is almost nothing.
I’m grateful to everyone for taking the time to explain the operation and nuances of LoRa to me. I have a better understanding of its capabilities - which are enormous - and limitations - of which there are a few. For the buoy project at hand, it would seem a more traditional approach is appropriate.
(‘Save target as’…run virus/malware scan…view content…?, vs blindly click and open with attendant virus risks? per good internet health practice;-) )
