• Is it possible to control or know the number of lost packets?

• Is it possible to know the percentage of errors in the broadcast / reception?

• Is it known if there is a small queue buffer or if there is a self-resending system in case of packet failure or collision?

thanks!

LoRa

LoRa raw

If you want to know about lost frames, you need to add a frame counter in your frames, increment it every time you send a frame, and check on the receiving side if there are missing frames (you'll only know when you actually receive a frame).

LoRa does not include any form of collision detection, so only the receiver knows if a frame was actually received (or not if using a frame counter as above).

If you want to have confirmed frames, you need the receiver to send acknowledgements when it receives a frame, have the sender wait for that ack, and resend if the ack is not received. You would need to include a frame counter as well (not incremented on retries), so that if it was the ack that got lost and not the original frame, it won't be received twice.

Note in some regions and bands there are limits on how often you can send data, so confirmed frames are not always possible in a scenario with multiple nodes talking to a single one.

The alternative is to use LoRaWAN which includes all of that and more.

Is it known if there is a small queue buffer or if there is a self-resending system in case of packet failure or collision?

Do any LoRaWan gateways have self-resending feature ? E. g., while WiFi is down, the gateway store the packets received by the LoRaWan nodes and send them when WiFi connection is restored ? Or this feature is not compliant with LoRaWan ?

@zceld said in About LoRa:

Is it known if there is a small queue buffer or if there is a self-resending system in case of packet failure or collision?

Do any LoRaWan gateways have self-resending feature ? E. g., while WiFi is down, the gateway store the packets received by the LoRaWan nodes and send them when WiFi connection is restored ? Or this feature is not compliant with LoRaWan ?

Gateways running the LORIOT packet forwarder has this feature, they are caching received packets and send when WAN connection restored.

@rcolistete said in About LoRa:

@zceld said in About LoRa:

Is it known if there is a small queue buffer or if there is a self-resending system in case of packet failure or collision?

Do any LoRaWan gateways have self-resending feature ? E. g., while WiFi is down, the gateway store the packets received by the LoRaWan nodes and send them when WiFi connection is restored ? Or this feature is not compliant with LoRaWan ?

Gateways running the LORIOT packet forwarder has this feature, they are caching received packets and send when WAN connection restored.

The LoRaWan receive the packets with the date when the node sends or when the gateway forward the packets ?

So in theory the Pycom LoRaWan nano-gateway (for LoPy/LoPy4/FiPy) could have this feature implemented ?

@bmarkus said in About LoRa:

@rcolistete said in About LoRa:

@zceld said in About LoRa:

Is it known if there is a small queue buffer or if there is a self-resending system in case of packet failure or collision?

Do any LoRaWan gateways have self-resending feature ? E. g., while WiFi is down, the gateway store the packets received by the LoRaWan nodes and send them when WiFi connection is restored ? Or this feature is not compliant with LoRaWan ?

Gateways running the LORIOT packet forwarder has this feature, they are caching received packets and send when WAN connection restored.

The LoRaWan receive the packets with the date when the node sends or when the gateway forward the packets ?

So in theory the Pycom LoRaWan nano-gateway (for LoPy/LoPy4/FiPy) could have this feature implemented ?

Can’t implement for UDP protocol used by Nano GW.

The LoRaWan receive the packets with the date when the node sends or when the gateway forward the packets ?

No timestamp is sent in LoRaWAN frames, and often nodes do not know the time (or not precisely). Timestamp information is added by the gateway when it receives the frame.

But I’m not quite sure how the timestamp would be relevant for retransmits? The only relevant data is a frame counter and ACKs.

from network import LoRa
import socket

lora = LoRa(mode=LoRa.LORA)
s = socket.socket(socket.AF_LORA, socket.SOCK_RAW)
s.setblocking(False)
x = "witeklab-"+"1"+"-"+"390-"+str(coord[0]) + "-"+str(coord[1])
s.send(x)

Is it safe that internally the chip only sends it once or in turn does some retries in case there are collisions with other emissions from other different devices through LoRa?

So if you want to be sure the frame gets to its destination, you'll have to add frame counters, ACKs and retries yourself.

Or use LoRaWAN and confirmed packets. But remember that in some regions confirmed packets (or manual ACKs) may be a problem given the duty cycle limitations on all nodes, including the gateway.

Can’t implement for UDP protocol used by Nano GW.

Why not using UDP ? A modified version of Pycom LoRaWan nano-gateway software able to resend cached packets to TTN (for example) after WiFi was down.