I need to establish a LoRaWAN gateway radio on shore to get data from several buoys 2 - 3 km offshore. Each buoy will generate a payload of 100 bytes and interrogated every 2 hours. The gateway radio will be connected to a ISP-supplied cable modem. The system will be controlled via Internet from a PC - about 25 km away - using Modbus TCP/IP.
Each buoy needs an end-node LoRaWAN radio which will be connected to a PLC via an Ethernet cable. The PLC will be connected to 16 sensors.
My biggest problem is that most end node radios seem to already be equipped with a sensor of some sort. I want an end-node with just an RJ-45 connector on the data I/F and an antenna port.
Iāve been in the RF business - propagation and antennas - for a long time but Iām completely new to LoRaWAN. Is my approach to this project even realistic? What kind of hardware should I be looking for - esp for the end node? Iāve looked at some PLC topics on this forum but didnāt see anything that I could relate to.
sounds like you want to find a convertor that convert Lora to TCP/IP, itās not common to having such device but you can find TCP/IP to rs232 device and rs232 to Lora device. maybe make an integration of them then it works.
A picture would help a great deal as it looks like TLA soup at present. But overall Iām not sure LoRaWAN is likely to be suitable.
You appear to wanting be connecting a PLC via Ethernet to a LoRaWAN end node that transmits to shore, picked up by a LoRaWAN gateway with the attendant transfer via an LNS to āsomethingā that can then turn it all back in to Modbus TCP/IP to your control system. And then, by implication, back again, for which LoRaWAN is not suitable for real time control, particularly not with some many differing links as points of failure.
Deeply unlikely to exist as LoRaWAN is the polar opposite to TCP/IP. If you mean something that can use Ethernet to be told about readings and re-package it as a LoRaWAN uplink, then simple enough to put something together, it will be all about the firmware. But the return path will be equally un-funny.
What bought LoRa/LoRaWAN to your attention as part of the solution, specifically what attributes does it bring to play that you desire?
There are such nodes. We offer a device named izi-io 4840 that is used e.g. in electrical grid stations. We have no Ethernet connector but use Modbus RTU (i.e. serial) to read measured values from specialized grid monitoring devices (such as voltage, current, active/reactive/apparent power, THD etc.), process them (min/max/mean calculations, limits and other) and finally transmit them as ācondensedā LoRaWAN telegrams on a regular as well as event-triggered basis. You might call that āedge computingā, or whatever. We also have eight configurable input channels that can facilitate digital (PLC, TTL) or analog signals (voltage, current, Pt1000 temperature, 4ā¦20mA) and four digital outputs. All processing is done with a soft PLC on the device. By default we have a standard application that can be widely parameterized using a JSON configuration file, but we also offer engineering to implement customer-specific solutions.
(@descartes enough TLA soup? 
)
As seen here:https://www.thethingsnetwork.org/device-repository/devices/izinto/izi-io-4840/
Hopefully the OP can use serial rather than the Ethernet he referred to - so much simpler all round!
A drawing is attached.
On each buoy, a PLC would be located adjacent to the radio and connected with a short Ethernet cable. The RJ45 connector is required on the PLC because the PLC is limited to 247 addresses (nodes) otherwise. An RS232 port can be used to control the PLC if there are 247 nodes or less. This is a feature of the Modbus control s/w - Modbus RTU is used to control the PLC if 247 nodes or less is used, and Modbus TCP/IP is needed for more than 247 nodes.
LoRaWAN was appealing because the data payloads are small - 100 bytes, and retrieved every 2 hours. The current project could be supported by a long-range WiFi gateway radio but just barely. Future projects may be further offshore and WiFi will no longer be an option. LoRaWAN would be ideal but apparently weād need to find some other way to control the Gateway and presumably to interface between the PLC and the LoRa radio.
< Redacted: Ensenada System >
Using my quarantined machine, I checked out the attachment. Please repost as a JPEG or PNG - no point having people download things that donāt need to be. Thank you.
@izinto, nice looking box, cool functions, not sure about SD Cards but canāt see the open source files ā¦
How many nodes in reality (not 247 I hope!)
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?
Thank you - here you goā¦
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?
A buoy with more than 247 sensors???
No, youād add more devices and no, there is no hard limit on how many gateways can co-exist!
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.
Iām using ābuoyā and ānodeā interchangeably. A buoy will never have more than 16 sensors, and never more than one radio.
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.
However all gateways share the same very limited radio spectrum so there is no point in adding many of them at the same location.
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ā¦
Never 247+ per - let alone 47!
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.