About LoRa

[zceld]

Good morning, we are having some problems with the reception and issuance of messages through LoRa between Lopy and the following questions arise:

• 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!

[rcolistete]

@bmarkus said in About LoRa:

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.

[zceld]

@jcaron Thank you very much !

[jcaron]

@zceld As stated earlier, in raw LoRa mode, you send a frame, and you just hope it gets to destination. There are no ACKs, no retries, no collision detection, nothing at all. If there's a collision, too much noise, or you are out of range, the frame is lost, and that's it.

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.

[zceld]

@jcaron
Thank you very much for the information. On the other hand I have another question about 'Lora-Raw' and it is yes although in the programming for example you will only send a message like the example that I attached:

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?

[jcaron]

@rcolistete said in About LoRa:

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.

[bmarkus]

@rcolistete said in About LoRa:

@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.

[rcolistete]

@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 ?

[bmarkus]

@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.

[rcolistete]

@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 ?

[jcaron]

In the case of raw LoRa, you just send a frame, and hope it gets to the destination.

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.

[Sympatron]

Currently none of the things you mentioned are implemented in LoRa-Raw and they probably never will be.
The whole idea behind LoRa Raw is that you have full control over what is sent and and how received messages are processed.
To achieve what you are asking you will have to implement message acknowledgements. Is the case of broadcasts this is not trivial. But otherwise the sending device has no means of knowing whether the transmission was successful.

[zceld]

@jcaron said in About LoRa:

LoRa

LoRa raw

[jcaron]

@zceld You'll have to specify if you're using raw LoRa or LoRaWAN, and show us the code you're using...