LoRa and Sigfox RSSI

[bitvijays]

Hello All,

Is it possible to get Lora/ Sigfox RSSI value without the downlink messages? I am aware of lora.stats and sigfox.rssi function which provide the rssi value after a downlink message has been received.

If not, when Lora sends a Lora.join message, it receives the accept message from the server, wouldn't that count as a lora downlink message?

Also, Does lora/ sigfox checks for network coverage before sending any message or they just send it blindly and hope that there's coverage and they might receive a response?

Thank you :)

[Gijs]

Also, Does lora/ sigfox checks for network coverage before sending any message or they just send it blindly and hope that there's coverage and they might receive a response?

Yes, the messages are sent blindly. At least for LoRa, there is only a downlink when you prepare a packet for downlink. There is no space for sending acknowledgements.

[jcaron]

@Gijs You can send confirmed messages, which will trigger an acknowledgment. With the usual caveats related to duty cycles and so on, depending on the region, so confirmed messages usually have to remain the exception rather than the rule (unless you send very, very, very few messages).

[bitvijays]

@jcaron By confirmed messages, do you meant, Downlink messages which are basically sent by Sigfox callback (the below pic)

and Lora messages downlink (for example TTN)

@Gijs Thanks for the answer. So, there is no way to know beforehand whether Lora and Sigfox network is even available and find out the RSSI or signal strength.

Thanks for the support :)

[jcaron]

@bitvijays A confirmed message is a message sent with a flag in the header asking for an ack. Confirmed messages exist in both directions (uplink and downlink), though in general (and in your case) it is set on uplinks.

You can set packets to be confirmed using:

s.setsockopt(socket.SOL_LORA, socket.SO_CONFIRMED, True)

You can set the number of retries using tx_retries in lora.init or the LoRa constructor.

But remember, it means the gateway will have to send a downlink, and in many regions duty cycle limitations and other rules will mean they can't do that very often, especially at low data rates (SF12 and such). That's the reason why TTN for instance only allow 10 downlinks a day per node, and that includes the ACKs for confirmed messages.

As to your question about the network being available, no, you can't know. LoRa devices do not maintain a connection to the network, there are no broadcasts from the network, this is very different from what happens in a cellular network.

For a fixed node, if you previously joined the network at the same locations, chances are you can still send data, unless you were really at the the RSSI/SNR limits and conditions have changed, or of course the gateway isn't available. That's the reason it is recommended to have multiple gateways with overlapping coverage.

Note that what you are most interested in is the RSSI at the gateway, not at the node. Even though there's some symmetry, there are enough asymmetric parameters in play that they're not necessarily the same.

For mobile nodes, well, you just send and pray.

[bitvijays]

Thanks @jcaron really appreciate the explanation.

Another quick query, Currently

1. Lora Device with Class A sends a message and then have two receive windows after 1 second and 2 seconds which means that for sending the next message we have minimum wait for 3 seconds. Is there a way to define that "do not wait for recieve windows". When we set the socket as non-confirmed by s.setsockopt(socket.SOL_LORA, socket.SO_CONFIRMED, False), does it still creates two receive window?

2. Sigfox device takes around 2 seconds to send a 12 bytes payload. However, as it further repeats the transmission on two different frequencies for reliability. The total time takes around 6 seconds which means to send the second message we have to wait for 6 seconds. Is there a way to only send it once rather than thrice at different frequencies?

Thank you :)

[jcaron]

@bitvijays listening during the receive windows is mandatory for a LoRaWAN-compliant device. The network could need a downlink to send MAC commands to change settings, and the end-device must listen for those and comply with their instructions.

If you don’t want that you’ll have to build your own networking stack on top of raw LoRa, but you’ll quickly find out you probably have to add a lot of the functionality of LoRaWAN.

You can control whether the LoPy repeats SigFox packets or not, see https://forum.pycom.io/topic/6057/lopy4-sending-duplicate-messager-using-sigfox/4

However note that this reduced resilience and increases chances of packet loss.

[Gijs]

@jcaron Ah yes, totally forgot about the feature.. Thanks for correcting me!
Indeed it depends on your country's duty cycle limit how much airtime you get and whether it is viable to send the acknowledgements. Generally, LoRa applications are okay with a few dropped packets. Do not make someones life depend on a LoRa packet arriving ;)