Hey everyone, I’m new to LoRa.
I want to send PLC data over LoRa to a LoRaWAN-Gateway. Because the PLC has no LoRaWAN support, I need an interface. I thought of a Raspberry PI with some kind of attachment which proceeds the data from the PLC (OPC UA) and then sends data over LoRaWAN to my gateway.
Is this approach reasonable?
During research, in 99% the Raspberry Pi is a LoRaWAN gateway. On what I learned in this use-case the Pi should need it to be a end-node. So is there a way of sending data from a raspberry pi to a LoRaWAN gateway?
Feel free to correct me, if I misunderstood something about LoRaWAN. It helps me learn.
Thanks in advance
~Nick
It can be done but you need to be wary of the amount of data/traffic the PLC generates as LoRaWAN if great for small amounts of infrequent data vs a steady stream of what might well be realtime/time-critical data, and talking of that general concensus from those who seem to know is that the Pi whilst great as a complex and powerful processor isnt great choice for with low power use or for hard realtime ('cause Linux) such as may be needed for (some of the) tight timing contraints within e.g. LMIC. You could look at a simple (say) UART interface to a LoRaWAN Module such as a Microchip RN2483 or RAK or Laird alternative and using comms with messages sent and controlled issued using simple AT like commands with the module then handling the LoRaWAN stack and any timing/schduling issues. Do you have any idea of the traffic volumes or allowed latency etc. Also wrt PLC be aware that downlinks (such as command and controls use) should be used extremely rarely/infrequently (and indeed TTN FUP has a limit of 10 messages per day! and that should really be thought of as per week or even per month ) A Pi Pico may be better option - allowing some local pre/post processing and data compaction or edge processing/intelligence again with external module handling the actual LoRaWAN traffic, but even then probably not recommended…
If your application is safety critical:
TTN And LoRaWAN are not recommended for safety critical applications. TTN because there is no SLA. LoRaWAN becuase there is no absolute guarantee of message delivery.
If you have a paid TTI subscription there is an SLA, but it cannot cover the radio part of the link as TTI have no control over the radio signal environment experienced by your sensor nodes and gateways. Electrical noise in your neighbourhood could obliterate your signals.
If you have a control loop:
The TTN “Fair Use Policy” (FUP) limitation of a maximum of 10 downlinks per day, including system generated downlinks, limits the use of TTN for process control to a realistic maximum of two state changes per day on average. TTI or a completely private server server stack will allow more downlinks but gateways are half duplex, so the receiver is blind when transmitting a downlink. Also if message delivery is not guaranteed, is it an effective control loop?
Here is where LoRaWAN and TTN can be made to work for you:
TTN is ideal for monitoring and data gathering use as long as you stay within the TTN FUP and the legal limits for your location. Adding additional LoRaWAN sensors to your process control system to get a better understanding of system performance is a good use case.
If your control system is fail safe, you might also use a downlink to trigger an infrequent, non critical, process that stops automatically under local control when the process is complete.
Further Information about the project
This project is supposed to be the topic for my bachelor thesis. It’s in the planning phase and I want to achive as much information as possible to buy hardware / to see if the stuff I want is possible.
Limitations
Thanks for pointing that out, I would definitely need more messages. What if I don’t use TTN? I would have to build my own server and loose the advantages building on TTN but the nodes could send more messages, right?
Working with the Raspberry Pi
What hardware or setup would be needed? There is a LoRa Node pHAT (Pi Supply), would this help with the LoRa-handling?
Can you point me out where I can find more information about this topic? For sure, this is TTN forum and I don’t want to hijack it with non TTN related questions.
Note FUP point called out is for downlinks (inc system generated messages, MAC commands etc from NS), there is a 30sec air time limit for uplinks per day (so # is determined by SF mix…)… actual # also dictated by amount of data/message size as has previously been asked for…A private instance of TTS would allow for operation beyond the TTN FUP…however, be aware that the airwaves are a shared resource and just because legal limits in a given territory might allow higher usage that doeant mean you should! Be a reponsible spectrum user and evaluate needs carefully before firing up and use data compression techniques and bit/byte wise payloads where possible - sending only the minimum needed. Pi Hat - Yep that works as a node- uses a RAK module per above, not good for low power use though (RPi!) as a node, could you use an Arduino or similar?
This should be possible. Your comment brought me to a solution, maybe you can confirm it:
PLC → (OPC UA) → Raspberry Pi (Subscribe to OPC UA data) → Arduino (LoRaWAN end-node) → Gateway → TTN
This way the preprocessing isn’t located on the LoRaWAN end-node and the Arduino only sends data, if lets say the status of the machine changes.
Data by exception is a good use case for LoRaWAN - rather than sending monitored data as a regular stream do local processing and send a regular status message/summary as needed with options for exception based alarming as and when needed…good for things like preventative maintenance or system down/failing/excusion alarming. As noted above consider what happens if message does not get through - 'cause Radio/RF - there no such thing as an SLA for open free space radio as you never know what a neighbour might do or where an interferer may come from and what it may generate…
“This project is supposed to be the topic for my bachelor thesis” - what other research have you done to look at the topology - hint, the Arduino as a LoRaWAN end node seems redundant if you look at what the Pi-Supply HAT does - but just asking us if it will help with “LoRa-handling” shows no real investigation. Ask yourself, what does this product do for a Raspberry Pi.
It occurs to me that a system whoes purpose is possibly to warn of machine failure\defect needs the PLC end node to operate with a secure\relaible send and acknowledge packet type system.
Frankly that doesn’t really sound like a LoRa radio application, LoRaWAN or otherwise. Ranges are short enough that a lot of other wireless technologies, or even wired ones, are probably better. And they’re going to offer you far fewer usage limitations.
If these were say, irrigation pumps scattered over a large area of farmland, that might be more a LoRa radio (and potentially LoRaWAN) application.
For a serious industrial application of your requirements you may have a look into the SIMATIC IOT2050. It is an Linux based edge device and allows to attach Arduino Extension Shields (like LoRa Borads). At the Siemens IOT Forum Website I saw an Application note which describes how to setup the system.
I think there are more Pi3B running factories than what you realize, I have seen deployment of 40, they all been running for years and not a single failure.
Does it need to go to the cloud? You could collect PLC data on your rPi via OPC UA (I’ve done that easily with a PLC and rPi) and then send it to AWS/Azure/googlecloud
My other thpught is, you could use LoRa, not LoraWAN. Scatter a few LoRa nodes and a few LoRa receivers around your Hall. (But as was pointed out, this is a LoraWan forum, not LoRa.)
) A Pi Pico may be better option - allowing some local pre/post processing and data compaction or edge processing/intelligence again with external module handling the actual LoRaWAN traffic, but even then probably not recommended…