2 uplinks on a single gateway

I’m getting 2 uplink messages as below on a single gateway at same time:

INFO: Received pkt from mote: 00000066 (fcnt=464)
INFO: Received pkt from mote: 00000066 (fcnt=464)
JSON up: {“rxpk”:[{“tmst”:989055100,“chan”:2,“rfch”:0,“freq”:865.572500,“stat”:1,“modu”:“LORA”,“datr”:“SF12BW125”,“codr”:“4/5”,“lsnr”:-15.0,“rssi”:-113,“size”:23,“data”:“gGYAAACA0AEI9CRAofIAfx3lZMXyM2c=”},{“tmst”:989055092,“chan”:1,“rfch”:0,“freq”:865.402500,“stat”:1,“modu”:“LORA”,“datr”:“SF12BW125”,“codr”:“4/5”,“lsnr”:8.5,“rssi”:-76,“size”:23,“data”:“gGYAAACA0AEI9CRAofIAfx3lZMXyM2c=”}]}
INFO: [up] PUSH_ACK received in 30 ms

These are same packet which are received on 2 different channels of the same gateway.
There is a huge difference between the RSSI and SNR signals (one of them is a side band).
I want to know which of these signals will be considered by the LoRa Server as a uplink message.

1 Like

Is your device really close to your gateway?

Yes it is approximately 2 meters away from the gateway.

Try to avoid this. Due to the sensitivity of the gateway receiver, you will see this behavior where one uplink is received on two channels.

1 Like

That is fine, but I want to know for the below scenario what will the server decide?

Gateway 1) Logs:
INFO: Received pkt from mote: 00000066 (fcnt=0)
INFO: Received pkt from mote: 00000066 (fcnt=0)
JSON up: {“rxpk”:[{“tmst”:322402916,“chan”:6,“rfch”:1,“freq”:866.495000,“stat”:1,“modu”:“LORA”,“datr”:“SF12BW125”,“codr”:“4/5”,“lsnr”:-10.8,“rssi”:-89,“size”:23,“data”:“gGYAAACAAAAI6ViJTcG+KzJAxm//yU8=”},“tmst”:322402908,“chan”:4,“rfch”:1,“freq”:865.985000,“stat”:1,“modu”:“LORA”,“datr”:“SF12BW125”,“codr”:“4/5”,“lsnr”:12.0,“rssi”:-29,“size”:23,“data”:“gGYAAACAAAAI6ViJTcG+KzJAxm//yU8=”}]}
INFO: [up] PUSH_ACK received in 66 ms

On the gateway bridge i found 2 signals of this gateway as below:
{“rxInfo”:{“mac”:“506f98000000005b”,“timestamp”:322402916,“frequency”:866495000,“channel”:6,“rfChain”:1,“crcStatus”:1,“codeRate”:“4/5”,“rssi”:-89,“loRaSNR”:-10.8,“size”:23,“dataRate”:{“modulation”:“LORA”,“spreadFactor”:12,“bandwidth”:125},“board”:0,“antenna”:0},“phyPayload”:“gGYAAACAAAAI6ViJTcG+KzJAxm//yU8=”}
{“rxInfo”:{“mac”:“506f98000000005b”,“timestamp”:322402908,“frequency”:865985000,“channel”:4,“rfChain”:1,“crcStatus”:1,“codeRate”:“4/5”,“rssi”:-29,“loRaSNR”:12,“size”:23,“dataRate”:{“modulation”:“LORA”,“spreadFactor”:12,“bandwidth”:125},“board”:0,“antenna”:0},“phyPayload”:“gGYAAACAAAAI6ViJTcG+KzJAxm//yU8=”}

Same signal was received on other gateways and on the LoRa App Server UPLINK INTEGRATION, i got the final signal as :
{“applicationID”:“2”,“applicationName”:“Field_testing”,“deviceName”:“node66”,“devEUI”:“0000000000000066”,“rxInfo”:[{“gatewayID”:“506f980000000030”,“name”:“gateway_no_30”,“rssi”:-81,“loRaSNR”:9.2,“location”:{“latitude”:0,“longitude”:0,“altitude”:0}}],“txInfo”:{“frequency”:865985000,“dr”:0},“adr”:true,“fCnt”:0,“fPort”:8,“data”:“MDEyMzQ1Njc4OQ==”}

Now when I checked for DOWNLINK, it goes from gateway MAC: “506f980000000030”, whose signal strength was low as compared to gateway 1

I’m not sure, but again I think this is because your device is really close to one gateway, causing this gateway to receive your frame twice which is not expected by LoRa Server, so it might store the frame received on 866495000Hz which has a SNR of -10.8.

Again, test again with your device further away from the gateway. In general LoRa Server uses the gateway with the best SNR.

2 Likes

I am seeing a similar issue too. Should the actual payload of the two packets be the same? Or is this a case of the gateway analog electronics getting saturated, which will result in some pseudorandom noise?

Is there another word or phrase for this phenomenon that I can look into deeper?

1 Like

There are two things that need to happen to get the point depicted (raw gateway receive message) and one more than needs to happen for any consequence to result.

  1. One of the preamble detectors in the SX1301 need to think it found the start of a packet with a recognizable spreading factor on a configured frequency. This is fairly routinely fooled; for example, you might use the public prefix but detect occasional private prefix packets, or just noise

  2. The SX1301 LoRa packet checksum needs to match - you’ll see in the packet forwarder logs indications of times this failed

  3. The LoRaWan Message Integrity Check needs to pass, this is a cryptographic checksum including not just the transmitted data but additional state like the frame count.

It’s relatively unlikely that all of these can be satisfied by something that isn’t the actual data, but of course it is theoretically possible; 32 bits of MIC only capture 4 billion unique possibilities, while the message has much more possibility space.

You might notice in the depicted case at the start of this thread that the base64 encoded packets are identical.

In this scenario, where two packets come in at nearly the same time (much less than the deduplication delay setting), is it safe to assume that LoRaServer will select the packet with the higher RSSI and SNR? Could you point me to the code or some documentation that shows how LoRaServer selects an uplink and also selects the gateway to send the downlink?

@cstratton thank you for the explanation. It’s interesting to consider all of those possible scenarios. Do you know if most gateways can be configured to listen for preambles on specific uplink channels or spreading factors?

I noticed this other thread on de-duplication logic might be applicable here. That thread links to this section of the code that de-duplicates packets based on the deduplication delay. https://github.com/brocaar/loraserver/blob/master/internal/uplink/collect.go#L32

When looking at it, it looks like LoRaServer will just use packet with the highest RSSI from the set of packets per gateway MAC and packet MIC. What happens in this situation when there are multiple packets from the same gateway? Since they are from the same gateway, will LoRaServer not keep track of multiple packets, even if they are from different channels and different RSSI and SNR since they are from the same gateway and have the same LoRaWAN frame?

TL;DR = All of the uplink packets (even duplicates from the same gateway) appear to be sorted by SNR and then RSSI. Sometimes these duplicate packets are even on different channels, which results in downlink acknowledgements not being received by end devices. I’m still not sure why LoRaServer sometimes picks packets with the lower SNR and RSSI.

The long version:
After spending some more time looking at this, it appears that 2 sets are created within Redis. The first set is keyed on the raw payload, with the value being the entire uplink packet (physical payload, channel, snr, rssi, etc.).

Then a second set is generated with a key that is also the raw payload, but with a slightly different name so it’s a different entry within Redis with a value of “lock”. This thread that successfully creates this 2nd set then goes to sleep for the deduplicationDelay time. Other threads (from other uplink packets) get an error because that value already exists within the lockKey.

After the initial thread wakes up after the deduplicationDelay it gets all of the values from the initial key in Redis. It then sorts the list of uplink packets based on SNR and then RSSI as a tie breaker if the SNR is the same, or if the SNR is very good for multiple uplink packets.

Having gone through that, I’m still not sure why a low RSSI and low SNR packet might still be selected by LoRaServer.

1 Like

Hello Brocaar,

I’m not sure, but again I think this is because your device is really close to one gateway, causing this gateway to receive your frame twice which is not expected by LoRa Server, so it might store the frame received on 866495000Hz which has a SNR of -10.8

According to the deduplication and sorting algorithms, shouldn’t it pick up the packet with highest SNR? In this case, wouldn’t it be 12.0 and rssi -29? I am a little confused why you would say SNR of -10.8. Can you shed some light on it?

1 Like

While it won’t give an internal view, I’d suggest a first step would be to setup an MQTT client that logs all the chatter to a flat file.

Then you could write something (in python or whatever) that goes through and tries to identify cases where the you think the “wrong” RX report was chosen as the basis for the downlink reply. Note that you can “see” the device address in a LoRa packet just by decoding the base64, you don’t need to decrypt it, so that can help you match TX’s back to RX reports. Also implement the uplink/downlink channel mapping if you are in a region where these are different. And finally the TX timestamp should be exactly 1 second (or appropriate window) after the RX report it is responding to.

You could do that in real time and repeat the downlink, but with the different channel. This PR seems like it will fix the root cause: https://github.com/brocaar/loraserver/pull/409

1 Like