Packet Loss in SX1302

[SteveQi]

Hi All,

I am using the SX1302 module over spi 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

no Ack ConfirmedDataUp Packet

[vivTob]

I'm facing a similar issue with Join-Accept messages:

`# Join-Request JSON up: {"rxpk":[{"jver":1,"tmst":909287041,"chan":2,"rfch":1,"freq":868.500000,"mid": 8,"stat":1,"modu":"LORA","datr":"SF7BW125","codr":"4/5","rssis":-22,"lsnr":10.8,"foff":12466,"rssi":-22,"size":23,"data":"AMe8AdB+1bNwq4cE/v9YF6joi8tNXho="}]} INFO: [up] PUSH_ACK received in 2 ms

Join-Accept

INFO: [down] PULL_RESP received - token[82:111] :)JSON down: {"txpk":{"imme":false,"rfch":0,"powe":14,"ant":0,"brd":0,"tmst":914287041,"freq":868.5,"modu":"LORA","datr":"SF7BW125","codr":"4/5","ipol":true,"size":33,"data":"IK6GW08uKOnqoRkB6ouUmGO/e2UwbfYtWpUUbfe3stiK"}} 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 2 ms

Join-Request

INFO: Received pkt from mote: D001BCC7 (fcnt=46037)JSON up: {"rxpk":[{"jver":1,"tmst":923087375,"chan":1,"rfch":1,"freq":868.300000,"mid": 8,"stat":1,"modu":"LORA","datr":"SF7BW125","codr":"4/5","rssis":-22,"lsnr":13.8,"foff":12524,"rssi":-21,"size":23,"data":"AMe8AdB+1bNwq4cE/v9YF6h3WNgJ1eU="}]} INFO: [up] PUSH_ACK received in 2 ms

Join-Accept

INFO: [down] PULL_RESP received - token[19:165] :)JSON down: {"txpk":{"imme":false,"rfch":0,"powe":14,"ant":0,"brd":0,"tmst":928087375,"freq":868.3,"modu":"LORA","datr":"SF7BW125","codr":"4/5","ipol":true,"size":33,"data":"IOcKdsT4xdYGO3U2LBEas5FJD+e7M1aON2TrGuZt9tgU"}} INFO: [down] PULL_ACK received in 1 ms WARNING: --- Packet dropped (current_time=928118865, packet_time=928087375) ---`

That prevents the node from Joining the network.

[vivTob]

I just came to investigate this behaviour. In my case the solution was quite simple increasing the TX_JIT_DELAY to about 120ms. The downlinks were dropped by the queue because the concentrator clock never met the timestamp in the TX_JIT_DELAY window.

[cstratton]

It would appear two very different things are being confused here.

The TX_JIT_DELAY setting has influence on downlink scheduling only, it has absolutely nothing to do with uplink packet loss. 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).

In terms of the actual packet loss, key issues involve transmitting too frequently (likely illegally so), potentially in a way that time aligns between nodes, not using channels with sufficiently random selection, and using confirmed uplink which means that the gateway is often busy transmitting downlinks. All of these together greatly increase the chances of time collisions, either on the air in the uplink case, downlinks blocking uplinks, or conflict in trying to schedule downlinks that overlap in time.

[smtc-bot]

Thank you for your inquiry.

Customers are encouraged to submit technical questions via our dedicated support portal at https://semtech.force.com/ldp/ldp_support.

We invite all users to visit the LoRa Developer Portal Forum at https://forum.lora-developers.semtech.com and to join the thriving LoRa development community!