“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.
Thanks for all the input. Like @descartes mentioned, there is more research to do.
Summary
LoRaWAN should not be used,
- if a lot of massages should be transmitted
- when you need a guarantee, that the message got delivered
There are ways to wire up a Raspberry Pi, to become a LoRaWAN node (e.g. Pi-Supply)
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.
But not really mains powered stuff in a building.
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.
1 Like
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.)
That’s an interesting idea. I’ve been eyeing the siemens iot2050 but haven’t tried one. It seems robust and I like the arduino shield feature.
It took a while but now I see “things” more clearly (The Things Network haha). Jokes aside, this is a post to wrap up the thread for other community members who find themselfs in the same position.
Hardware:
- RPi 4
- Dragino LoRa/GPS HAT v1.4 https://wiki.dragino.com/index.php?title=Lora/GPS_HAT
Setup:
Just put the HAT on the RPi, no more wiring is needed. There are a lot of repos on github to set up the RPi as LoRaWAN node, this was the most suitable for me GitHub - computenodes/dragino: LoRaWAN implementation in python.
If this GitHub repo goes down, you can also find a copy in one of my GitHub repos. If you set your node up, always be aware:
In terms of connecting it to a PLC: I’m not there yet but if there is interest, I will share it here.
Right now I use the additional GPS module on the HAT for a GPS-mapper (send location every minute via LoRaWAN). This could be interesting for people who want to contribute to TTN Coverage.
So it’s possible to use the RPi as a LoRaWAN-node in IIoT applications.
Is it as low-power as other nodes? - No.
Are other solutions “easier”? - Definitely, e.g. PLC → OPCUA → Ethernet has way less limitations. Nevertheless the use-case decides. And a lot of great replies with things to consider were made here.
Every minute, for a whole day ?
Best case (close to Gateway) that would be around 85 secs of air time per day.
Worst case (long distance from Gateway) that would be 1,804 secs of air time per day.
It’s not running 24h, just when needed (1-2h a day max) and with a low SF. The main objective is to place the gateway in the best position, where it covers the most needed spots on our plant.
Which doesn’t seem to be helped by uplinking its position once a minute unless you are positioning it by some radio prediction method on a very slippery surface such that it keeps moving …
I plug the RPi in and run around with it. If a package reaches the gateway, it will be forwarded and the GPS-data gets stored in a database. There is no other gateway near, so I can be sure it doesn’t get forwarded by another gateway.
How do you know?
1 Like
The Things Stack Discovery. Private LNS for evaluating gateway positions, no other gateway interferes.
This does not stop any other gateway that is in the area hearing your transmissions and forwarding them to its Network Server for processing.
Hence the FUP and the laws relating to Duty Cycle.
Before you point us at the map, you may want to search the forum for the number of times people point us at the map and then we tell them that not everyone is on the map, certainly not other network providers.
1 Like
For sure, every gateway is hearing every LoRaWAN message transmitted in range. But doesn`t a private LNS mean, that only the own gateways connected to the private LNS forward accepted packages?
Are these not the basic principles?
Public LNS → shared gateways
Private LNS → gateways are not shared
Don’t be worried, I won’t point at any map. But the location is so isolated, even cellular communication is barely possible (which does not mean anything, just for reference).
Nope, not at all, not even a little bit, because gateways do not have any autonomy beyond checking the CRC of the packet - if it passes, the it’s forwarded - it can’t decrypt so it doesn’t know. So if forwards to the NS. This means your frequent transmissions fill the airwaves and require all gateways that hear the uplinks for pass them on.
It actually means that the situation is worse than we thought - any LoRaWAN gateways in the area will be using a backhaul that is has a significant ongoing cost.
Isolated locations often make use of the Long Range radio system known as LoRa.
But as you have PLC devices, it can’t be that isolated. Or it’s a poor application of PLC devices where a more direct data acquisition / sensing scheme would be appropriate.
2 Likes
What u say wrt the NS being the final arbiter and rejecting the message is correct, as Nick says the GW how ever makes no such decision ….it’s purpose is to be a transparent passer on of messages but what you are also missing is the hint wrt the spectrum as a shared resource….and more importantly EVERY GW that hears the initial preamble for your message will say ahah…. LoRa message is coming….it might be a LoRaWAN message and better yet might be one my NS would love to handle….so best I start demodulating and start allocating some of my channel handling (remember it may only have 8 or possibly 16) resource and allocate and fire up my SF demodulation resources to go with it…… that is every packet heard by a gw triggers it to start looking and start demodulating/decoding, only if the crc is errored (ok there a few other deep spec clues that may impact handling decision, not for here) will it drop at the gw and be ignored. In the meantime it might miss a packet that it legitimately may want to handle from a better behaved node that it is there to serve…. Even in what seems to be the middle of nowhere…… and guess what areas with poor cellular coverage are a ripe use-case for LoRaWAN deployments notably because the users and communities can do it themselves and at low cost without waiting for a Cellco to decide the business case for them to deploy a mobile tower and supporting RAN is justified. Hence the continent of Africa is a hotbed or innovative deployments for e.g. threatened species monitoring or poacher detection, subsistence agriculture improvements., etc. Also just ‘cause you think there is no gw next door today, doesn’t mean there won’t be tomorrow or next week or…… 
3 Likes
You are both absolutely right, responsible use of licence-free frequency band is key.
That’s the one I was looking for.
This is what I have to find out in my thesis (Is LoRa / LoRaWAN is appropriate for usage in this area of industry? …).
My general approach is to be responsible with the sending of packets and only do transmissions at shorter intervals for testing.