Packet Loss in SX1302

Gateways
1

Hi All,

I am using the SX1302 module and the Two SX1272 is Node, I am sending from Two Nodes Uplink every 5sec once for checking the Packet Loss, I am getting 30% packet loss because of the below logs.

INFO: Received pkt from mote: 00000417 (fcnt=77)

JSON up: {“rxpk”:[{“jver”:1,“tmst”:472419812,“chan”:0,“rfch”:0,“freq”:865.062500,“mid”: 8,“stat”:1,“modu”:“LORA”,“datr”:“SF7BW125”,“codr”:“4/5”,“rssis”:-49,“lsnr”:13.2,“foff”:-9254,“rssi”:-49,“size”:21,“data”:“gBcEAACATQAH1HLmqHHq1BJ9Zkuh”}]}
INFO: [up] PUSH_ACK received in 0 ms
INFO: [down] PULL_RESP received - token[116:222] :slight_smile:

JSON down: {“txpk”:{“imme”:false,“tmst”:473419812,“freq”:865.0625,“rfch”:0,“powe”:27,“modu”:“LORA”,“datr”:“SF7BW125”,“codr”:“4/5”,“ipol”:true,“size”:12,“data”:“YBcEAACgjhrTIPAE”,“brd”:0,“ant”:0}}
WARNING: a downlink was already scheduled on rf_chain 0, overwritting it…
INFO: [jit] lgw_status returned TX_SCHEDULED
INFO: [down] PULL_ACK received in 0 ms

INFO: Received pkt from mote: 00000417 (fcnt=85)

JSON up: {“rxpk”:[{“jver”:1,“tmst”:472419812,“chan”:0,“rfch”:0,“freq”:865.062500,“mid”: 8,“stat”:1,“modu”:“LORA”,“datr”:“SF7BW125”,“codr”:“4/5”,“rssis”:-49,“lsnr”:13.2,“foff”:-9254,“rssi”:-49,“size”:21,“data”:“gBcEAACATQAH1HLmqHHq1BJ9Zkuh”}]}
INFO: [up] PUSH_ACK received in 0 ms
INFO: [down] PULL_RESP received - token[116:222] :slight_smile:

JSON down: {“txpk”:{“imme”:false,“tmst”:473419812,“freq”:865.0625,“rfch”:0,“powe”:27,“modu”:“LORA”,“datr”:“SF7BW125”,“codr”:“4/5”,“ipol”:true,“size”:12,“data”:“YBcEAACgjhrTIPAE”,“brd”:0,“ant”:0}}
WARNING: a downlink was already scheduled on rf_chain 0, overwritting it…
INFO: [jit] lgw_status returned TX_SCHEDULED
INFO: [down] PULL_ACK received in 0 ms

2

below log, I am getting frequently,

INFO: Received pkt from mote: 00000416 (fcnt=42)

JSON up: {“rxpk”:[{“jver”:1,“tmst”:435095768,“chan”:4,“rfch”:1,“freq”:865.985000,“mid”: 8,“stat”:1,“modu”:“LORA”,“datr”:“SF8BW125”,“codr”:“4/5”,“rssis”:-42,“lsnr”:14.2,“foff”:-12928,“rssi”:-41,“size”:21,“data”:“gBYEAACAKgAHL9qX5CWZtlk644+j”}]}
INFO: [up] PUSH_ACK received in 0 ms
INFO: [down] PULL_RESP received - token[33:88] :slight_smile:

JSON down: {“txpk”:{“imme”:false,“tmst”:435792118,“freq”:865.0625,“rfch”:0,“powe”:27,“modu”:“LORA”,“datr”:“SF7BW125”,“codr”:“4/5”,“ipol”:true,“size”:12,“data”:“YBcEAACg5R14MJep”,“brd”:0,“ant”:0}}
INFO: [down] PULL_RESP received - token[91:235] :slight_smile:

JSON down: {“txpk”:{“imme”:false,“tmst”:436095768,“freq”:865.985,“rfch”:0,“powe”:27,“modu”:“LORA”,“datr”:“SF8BW125”,“codr”:“4/5”,“ipol”:true,“size”:17,“data”:“YBYEAACltg8DUwcAAcgM3/8=”,“brd”:0,“ant”:0}}
WARNING: a downlink was already scheduled on rf_chain 0, overwritting it…
INFO: [jit] lgw_status returned TX_SCHEDULED

3

This is an issue related to the packet forwarder.
I had the same problem and solved it by increasing the TX_JIT_DELAY in jitqueue.c.
This specifies the window in which a frame can be send by the concentrator. When the window is not big enough for your system, packets can get dropped.
See also: https://github.com/Lora-net/sx1302_hal/issues/53

4

You are doing a number of things in non-optimal ways which probably contribute to this issue.

First, you are transmitting too frequently. This is likely illegal in locations which use the 868 frequency band, and doing so at a small fixed interval such that your nodes could easily align in time and collide on the air.

Next, you are re-using the same frequency too often, indicating a bad channel selection algorithm. This also increases the chances of collision.

Next, you are unwisely using confirmed uplink, meaning that each (initially received) uplink will generate a downlink. While a gateway is transmitting a downlink to one node, it cannot receive from any other node, so this additional jams your air capacity.

The TX_JIT_DELAY setting has influence on downlink scheduling only, it has absolutely nothing to do with uplinks. And even in the downlink side, it would appear all you’re seeing are actual timing collisions - there is no setting which allows a gateway to transmit two downlinks which overlap in time.

All increasing TX_JIT_DELAY would do is try to counteract an extremely slow host embedded board. It also has the consequence of meaning that the downlink request from the network server must arrive at the gateway that much earlier - which may itself be a challenge if you have a sometimes slow internet connection in between (though for classic 1 second RX1, not for larger RX windows such as used in join accepts and other situations).

1 Like
5

Hello, I also encountered this problem, how did you solve it in the end?