Hi,
I recently acquired an LG01-N to develop a small project in agriculture.
Since the internet connection in the field is very unstable, what happens if it crush? All data will be lost…
One possibility is to program the device, but it is openwrt, and I don’t manage it.
Do you know any mechanism to do it with external hardware?
One solution I was thinking is having an mqtt broker and a database locally on a raspberry pi and connect with the Dragino LG-01 via ethernet or wifi, and from this upload to the cloud. I can handle this with nodered in a simpler way without learn a new programing language, but the cost will rise quickly…whats do you think about?
First of all, sorry to say, the LG01 is not a viable LoRaWAN gateway. The Lora hardware is too limited to work as LoRaWAN gateway. If you really need to use this hardware you are limited to (plain) Lora which is not the subject of this forum.
There are other gateways available that already implement temporary storage of LoRaWAN packets when the gateways connection to the backend is lost.
Keep in mind the store and forward later mechanism has drawbacks. It will not work for anything where you need downlinks like OTAA and ADR.
And Dragino are now displaying a link to the limitations part of the documentation which I guess is progress.
RAK appear to have some store & forward capabilities in their gateways but there is discussion about how it’s deployed - possibly only with its built in NS or via own ChirpStack.
Maybe there is a use case for a local P2P gateway that can then relay on to a full gateway, either live or storing if offline & forwarding when the link is back up. But then if you have internet back, you may as well just forward directly to your data store …
Keep in mind that stale packets saved on the gateway don’t really work very well with by-the-rules LoRaWAN.
This is because LoRaWAN considers any repeat or decrement of the frame counter embedded in each packet to be a replay attack and not a valid message. So the only way you can use saved packets with a conventional LoRaWAN server is to make sure that they are uploaded in order, and also that no more recent packets happen to have gotten in from a different gateway before the saved packets are uploaded.
Really, all of this plus the single-channel fakeway point towards a project that may want a custom server implementing something locally unique, perhaps with a packet format and air paradigms inspired by LoRaWAN, but not actually LoRaWAN… there is real potential there, but it is not on topic here.
I wasn’t thinking of any form of replay - collect data via P2P using own format and then submit when the link is live. But off-topic so we can stop here.
The point is that to a LoRaWAN server which has seen any more recent packet, such delayed submission looks like a replay attack. To be compliant, the packets have to be (collectively by all gateways) submitted in order - forward skips are fine, backwards ones are not, including backwards ones resulting from a gateway submitting packets it saved while unable to reach the server.
I wasn’t thinking of any form of replay - collect ALL data via P2P using own format and then submit when the link is live, if it’s not live, store and then submit as if live - which will require a timestamp in the payload for the destination data store.
Everything, all uplinks, will be via a proxy. I do fully understand the frame counters.
Again, the issue is that delayed submission looks like a replay attack.
If any other gateway gets a packet to the server at the time it is actually put on the air, then all of your delayed packets look like replay attacks when they finally arrive and are ignored.
If there simply aren’t any other gateways that could possibly contribute (ie, you build a single-gateway private network) then you might as well just run the network server on the gateway, with the added benefit that ADR, OTAA, etc can actually work because the loop only has to be completed to that box.
Which wouldn’t be possible as I’d be using P2P for ALL data with my own format to a proxy - which as I noted above, makes the whole scheme a bit moot as you may as well just relay straight to your own data store.
Or, as you suggest, spring for your own private gateway, NS, AS etc etc
I fully understand the replay issue so I think we’d best stop now.
Hi,
is there a way of doing what this topic suggests only with the LG01P?
I have an application with raspberry and self made gateway, which stores data in local database when connection to internet fails, when connection is restored it automatically uploads the data to the cloud. I want to know if i could do something similar with LG01P and TTN, can you store data locally in LG01P ( can i install mysql to its OS?)? and when it stablishes internet connection it uploads the data to TTN?
Regards
But as countless threads on this forum explain over and over, you’re not supposed to use the LG01 on TTN, so the question isn’t really on topic for the TTN forum.
