Store PyGate Messages
We need to develop a LoRA Gateway that will be able to temporarily store the packets arriving (only the recent packets e.g. of the last 5 minutes) to the flash.
Does anyone know how could we achieve that without modifying the Lora packet forwarder in the PyGate firmware?
For example, I have seen in some posts like this that the PyGate firmware already supports the printing of the debug PyGate messages, but I don't know if this functionality is limited only to the statistics or the debug messages functionality could print/store also the original LoRA messages arriving (like we see them in TTN console).
Thank you for your time!
@rcolistete Ah, I understand. Thank you for the clarification. I was not informed of the nanogateway (1 channel) configuration for LoPy4, a quick google got me up to speed. Thanks.
rcolistete last edited by rcolistete
@d-alvrzx It is not published. But if the community is interested I can revise and better document the code and publish it.
But it is for nanogateway.py, so only 1 channel gateway using LoPy4/etc.
@x893 You probably could save the LoRa packets to PSRAM to buffer them. You might run into 'out of memory' issues, depending on the buffer size of course. I believe the Pygate itself also uses quite a lot of memory.
@rcolistete Hi! Where is this available?
rcolistete last edited by
I've developed a nanogateway.py (to run on LoPy4, etc) modified software with "resend" capability : when WiFi is not working, the received LoRaWan packet is saved in a RAM buffer, then it checks if the WiFi is back and send the buffered packets (with some delay).
Saving to internal flash, etc, has the timing problem if some uplink/downlin packet is received.
Can i use PSRAM to save packages (of course with changes in lora_fwd_pkt) ?
Re: Store PyGate Messages
1-2 years ago I used a RasPi + SX1308 gateway and modified lora_pkt_fwd to save packets to a file if the network server is not available. I think you can change lora_pkt_fwd to save packages. Only storage (PRAM or Flash) is required.
@anikolaid You could possibly run some kind of local store-and-forward proxy. The details depend on the specific protocol used between the gateway and the LNS, I have to admit I have no idea what is fashionable these days or supported by the PyGate.
As advised by @robert-hh downlinks (and possibly confirmed messages) will be an issue. IIRC confirmation are just a flag in a header, no idea if that's within the encrypted part or not, though, would have to check the specs.
It would be interesting to see if there wouldn't be issues with deduplication as well (in case a frame is received by more than one gateway, one of which is temporarily offline).
Note that the "official" LoRaWAN approach to this is to add more gateways for redundancy.
@Gijs I'm aware of the stability issues you are facing. I would encourage you to focus also in the cases like the one I reported yesterday that the operation of the PyGate is totally impossible for the NB-IoT networks with IPv6 only support (there are already many operators that support only IPv6 in their NB-IoT networks).
This means for us that we need to abandon the really nice concept and implementation of the PyGate...
In the background, we are working on creating a stable solution for dropped connections (LTE and WiFi), it just takes some time to figure out what is the most reliable and sustainable approach..
robert-hh last edited by
@anikolaid If you succeed in doing so, at least the downlink messages for the node will be lost, meanin that you cannot use confirmed messages for type A nodes. Unless the gateway creates downlink messages. But that would only possible for messages w/o encryped payload. I would have to lookup is confirm messages are such.
@jcaron I think you are correct! However we don't want to "decrypt" the stored packages in a "custom" way. We just want to forward them to the LNS some minutes later (and only in case of a WiFI failure). Do you think that this would cause any kind of issues?
@Gijs more importantly, if I’m not mistaken, frames are transported encrypted until they reach the LNS, so the gateway won’t be able to store anything useful.
One alternative could be to run an LNS on the gateway itself, but that radically changes the network architecture, and would cause all sorts of issues with redundant paths for instance.
Thank you, I really appreciate your prompt and well-elaborated answer!
Sorry to tell you this, but the LoRa packages are handled in low level C code. I believe we currently have no plans to extend the functionality to micropython and allow for saving of the LoRa packages. Also the printing is handled in the sourcecode.
Next to that, timing is very critical in the LoRa (to for example TTN) infrastructure, mainly in the sceduling of downlink packets. Using a buffer in this case will delay the uplink of the message for too long, causing a possible scheduled downlink event to not be received, as the receiving window of the node has closed.
Also, saving of LoRa packets is quite unconventional, as you are also handeling other people's traffic through a Pygate.