I am evaluating a lora network composed by a pkt forwarder (rak831 based) running in a raspberry pi 3 with an end device (rak811 based) placed 2km away. The uplink frames are sent to TTN servers and then integrated via http to an IOT dashboard. The pi runs the code from https://github.com/Lora-net/packet_forwarder. I am happy with the results, the system is quite stable.
I am planning to install a second gateway in order to gain robustness in the network. I am currently losing around 18% of packets (in the range of an rssi of -115) coming with failed CRC (1 byte corrupted normaly). I am working without confirmation due to the high impact in battery life the retransmisions cause. The idea is to achieve a better ratio of failed packets down to 3% by adding the second gateway.
The point is that a possible scenario is the raspberry loses internet connection. I am observing that the uplink frames reveived in this interval are lost. I though the gateway would implement kind of buffer in order to send the frames when the connection between pi and the TTN servers is restored. What is the sense then of having a gateway timestamp in the metadata?
Do you know if exist a solution for this?
Thanks!
Ed
Hi Borroz thanks for your response.
I am not having free line of sight, it is kinf of urban context. The transmissions are in SF12. I am usign this antenna for the gateway and this one for the end device. Both placed vertically.
I don’t see another option then to add another gateway or move the first one closer to the node Is there a lot of other lora(wan) traffic or industry rf 'noise ?
it’s maybe worth to try a different antenna on the node first
In principile it is not a noisy zone. The second gateway will be better placed so I will improve the network a lot.
In any case and regarding my question about the posibility of buffering frames in gateway in case of losing connection from Pi to TTN server, I understand there is no solution currently right?
Idea is GW & backhaul connection is low latency otherwise timing for e.g. RX1 & RX2 gets screwed and also join req’s, confirmed acks etc would be a mess/non-starter and as open infrastructure even if you amended your own firmware/apps to accommodate impact it would mess up for other community users Not sure but suspect that if packets arrive way to late (due to extended buffering) likely some network servers would simply drop/ignore esp if buffering is so long that frame counts get out of sync etc.
I understand. Maybe an option would be not using TTN and install a lora server in the PI (e.g: https://www.loraserver.io/guides/raspberry-pi/)… although the problem would be still not solved because the second gateway couldn´t connect the one who runs the server in case the first loses connection.
OK, maybe a internet connection backup in pi (type 4G modem) would be the way to face the problem…
)
Not sure but suspect that if packets arrive way to late (due to extended buffering) likely some network servers would simply drop/ignore esp if buffering is so long that frame counts get out of sync etc.