2 uplinks on a single gateway


#1

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.


#2

Is your device really close to your gateway?


#3

Yes it is approximately 2 meters away from the gateway.


#4

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.


#5

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


#6

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.


#7

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?


#8

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.