Ghost packet response frequency

[sanchox]

Hello there!

I am research for ghost packet receiving problem now.

I found out that this PR Adding frequency as part of the lock key by KarthikSubramanian2 · Pull Request #409 · brocaar/chirpstack-network-server · GitHub not actually resolving problem with ghost packets.
What I found out is sometimes response for packet received together with “ghost” packet is sent on “ghost” packet frequency instead of original packet frequency.

So I dig to code to find place where "freq" property from uplink json is used to determine response frequency.
And I found that “freq” is packed to UplinkTXInfo struct in chirpstack-gateway-bridge backend/semtechudp/packets/push_data.go#L159
But as I can see in gw.proto only one UplinkTXInfo is exists in opposite to multiple UplinkRXInfo.

Using frequency for response from first (or last) available packet may be a reason for this problem as I think.

Here []gw.UplinkFrame with unique UplinkTXInfo for each other is transformed to portobuf serialized message.

Here gw.UplinkFrame.TXInfo from pb message is used to fill models.RXPacket structure with only single TXInfo property.

Example uplink JSON from packet_forwarder

{
   "rxpk":[
      {
         "jver":1,
         "tmst":133903775,
         "time":"2020-06-03T12:23:44.438993Z",
         "tmms":1275222243439,
         "chan":4,
         "rfch":0,
         "freq":867.300000,
         "mid":4,
         "stat":1,
         "modu":"LORA",
         "datr":"SF12BW125",
         "codr":"4/5",
         "rssis":-96,
         "lsnr":-12.0,
         "foff":-1203,
         "rssi":-85,
         "size":21,
         "data":"QI2GVAABMFoCBM/KrjiZeNY7/fYY"
      },
      {
         "jver":1,
         "tmst":133903775,
         "time":"2020-06-03T12:23:44.438993Z",
         "tmms":1275222243439,
         "chan":1,
         "rfch":1,
         "freq":868.300000,
         "mid":0,
         "stat":1,
         "modu":"LORA",
         "datr":"SF12BW125",
         "codr":"4/5",
         "rssis":-23,
         "lsnr":11.5,
         "foff":-1203,
         "rssi":-22,
         "size":21,
         "data":"QI2GVAABMFoCBM/KrjiZeNY7/fYY"
      }
   ]
}

Also, I find that GW count in link_check MAC command response calculated incorrect here.

I’m not good enough in Golang to make patch.
Can anyone approve or decline my suggestions? @brocaar maybe?

Ghost packets receiving was already described in these forum topics:

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…

SodaqOne - Waiting for response from server

This is RF basics. In close proximity the end-device may over-drive the gateway hardware causing ghost packets to be received on adjacent channels. These ghost packets can also be seen at time on channels 1 MHz or higher or lower than the intended channel due to harmonic and sometimes 4MHz and 11MHz above or below the primary signals.

Sorry for my English =)

[sanchox]

I made this patch, and it works fine for me.
This also fix link_check MAC command gw_cnt bug.
GitHub diff