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.
So for short interval you flood the network and the node that is responsible and abides to FUP (30sec) a day, don’t get is fair share of the 30sec?
Point to the map, as you need to be fairly remote not to be out of range (its possible you are), I have seen uplinks 130Km + from nodes on the ground (not flying in high altitude balloons).
What does LORA stand for?
Look at msg.payload.uplink_message.rx_metadata and you get surprise sometimes.
Just to be sure you understand what I am saying the GW has no part in the decision - the NS decides…
Yes and no - not shared as in they wont handle your messages if not part of your network - unless part of a roaming agreement or using something like packetbroker…BUT those same private GWs will allocate limited resources, handle the message and forward to their associated NS if valid - same for all whether public or private, on net or offnet…
Short answer for your your thesis is - yes it can be - and indeed in many installations around the worls it is - its just the devil is in the detail…and the associated radio regulations 
There are PLC and PLC node connectivity devices and solutions in the market using LoRa &/or LoRaWAN and have been for years. They just have to be used carefully and for the right use cases…
…search the forum and will see lots of instances where we push back on people who say "but I’m only doing it for testing/for my limited case/for my area where there is nothing else around/for my…
fine within reason, and in the case of TTN within FUP - but the individual or company making the judgement as to what might be reasonable in the eyes of others is often not the person best placed to make the call as to what others consider reasonable = hence regulations…(note we all push limits at times - even if accidentally - the key is to have a good grasp of the consequences and mitigations… appreciate this is a learning exercise for you, as for us all! )
2 Likes
The blue line is a gateway 40km+ from every other gateway in the world, that were recently installed it. We have few nodes reporting to it, that is the grass looking line at the bottom.
The spike to 1000+ is all from one node and were there from the day we installed the gateway. We have monitored the gateway and it is one Dev Address causing this spike. If you look at the spikes, it only occur during office hours.
So there is somewhere not on any map a gateway that this node use to report to or maybe still reports to it. Just we cant see this gateway on any map.
4 Likes
Separate from the other discussions, I’m intersted in your PLC connection ideas. I could see a use for this on a pipeline monitoring application (for example). I have run some OPC-UA python libraries on an RPi3 and it works well. Layering LoRa onto that could be useful.
I have been looking into this for a while now. I have a raspberry pi CM4 attached to sx1262 lora module and I have been looking for a way to connect it to the things network through a gateway as an end node. Can anyone direct/ help me with any repo on using raspberry pi CM4 with sx1262 as an end node ?
I have a raspberry pico attached to a sx1262 lora module, and I’m using the hello_otaa example script in the repo(GitHub - siuwahzhong/lorawan-library-for-pico: Enable LoRaWAN communications on your Raspberry Pi Pico or any RP2040 based board. 📡) to register the device on the things network. However, after providing the dev EUI, app EUI and app KEY in the config.h, I realized from the debug logs that the credentials (dev EUI and app EUI) change when I build and run the code. I kindly need some help on that if you’ve encountered the same problem using this repository. Thank you.
Please do not double post, it splits the efforts of the volunteers answering - continue with the thread you added to as it provides vital context as to what’s gone before.
1 Like