Packet Forwarder don't show all packets from multiple End Device

[vikasrohal]

Hi,
I am using multiple End devices and facing a issue on packet forwarder

Packet Forwarder don't show all packet from end device but End Device get ACK from the Server, and no record of these packets in lora server as well.

End Device code version - V4.3.2
Lora Packet Forwarder Version - v4.0.1
Lora Gateway version - v5.0.1

[mcoracin]

Hello,
If the End Device gets ACK from the Server (for all packets?), it means that there is a gateway which receives all packets, and a Server as well.
Do you have several gateway around you?
Which server are you using?

If you have a gateway on which you see some packets from a particular end device, but not all (what is the ratio?), maybe it could be due to the fact that one is configured as "private" and the other is configured as "public"?
How is the "lorawan_public" field set in your global_conf.json file?

[vikasrohal]

"lorawan_public" set true in global_conf.json

as per below log fcnt=57 droped but End Device Send frame with frame count 57 and got ACK.

INFO: Received pkt from mote: 00000005 (fcnt=56)

JSON up: {"rxpk":[{"tmst":899872780,"chan":0,"rfch":0,"freq":865.062500,"stat":1,"modu":"LORA","datr":"SF9BW125","codr":"4/5","lsnr":13.5,"rssi":-49,"size":51,"data":"gAUAAACCOAADBwOdjwvVy1XA1MTvuzwQxsZX0PePNjXAYsX0+DHy2lzuSMm0P91M6F22"}]}
INFO: [up] PUSH_ACK received in 1 ms
INFO: tx_start_delay=1495 (1495.500000) - (1497, bw_delay=1.500000, notch_delay=0.000000)
INFO: [down] PULL_RESP received - token[0:0] :)

JSON down: {"txpk":{"imme":false,"tmst":901872780,"freq":866.55,"rfch":0,"powe":14,"modu":"LORA","datr":"SF10BW125","codr":"4/5","ipol":true,"size":12,"data":"YAUAAACgPAFpo94I"}}
INFO: [down] PULL_ACK received in 0 ms
INFO: tx_start_delay=1495 (1495.500000) - (1497, bw_delay=1.500000, notch_delay=0.000000)

INFO: Received pkt from mote: 00000005 (fcnt=58)

JSON up: {"rxpk":[{"tmst":902515060,"chan":0,"rfch":0,"freq":865.062500,"stat":1,"modu":"LORA","datr":"SF9BW125","codr":"4/5","lsnr":-4.8,"rssi":-51,"size":49,"data":"gAUAAACAOgADBEYm5W7rgLBZIXRUkBeDIP9UF1nLaMnsIOeq7+2X1nbXxju1W+ZuHA=="}]}
INFO: [up] PUSH_ACK received in 0 ms
INFO: [down] PULL_RESP received - token[0:0] :)

[mcoracin]

Are the channels correctly defined on both end-device and gateway side?
Could it be that packet with FCnt 57 has been sent on a channel which is not configured on this gateway?

[vikasrohal]

All the channels are define correctly.
If no (Ack not possible to End Device)
I am using 2 End Device with Ducty Cycle OFF and sending data continuously ( interval of 1 second )

[mcoracin]

The gateway cannot receive a packet while transmitting.
Is it possible that packet with FCnt 57 was sent by the end device, while the gateway was sending the ACK for packet with FCnt 56?
Do you have a SDR dongle to see what happens in the air?

When you say that the End Device is sending data continuously, do you mean it does the following sequence:

• sends the packet
• opens receive window 1 (1s after uplink)
• opens receive window 2 (2s after uplink)
• wait for 1 seconds
• sends the next packet

A End-Device cannot send a packet every second and receive ACK at the same time...

[vikasrohal]

Yes you are right. Every thing happening as say last.
i am using receive window 2 to receive data or ack from server.

sorry, Don't have SDR dongle.

Send confirm data
wait for 2 sec(Second Receive window)
if got ACK, wait 1s and send other packet
if don't get ACK, Mac layer starts Nbtriels (send 8 time ) to get ACK.

[vikasrohal]

Log with Debug Messages

fcnt=117 droped without Nbtries(8 time retries )

INFO: Received pkt from mote: 00000004 (fcnt=116)

JSON up: {"rxpk":[{"tmst":771129596,"chan":4,"rfch":1,"freq":865.985000,"stat":1,"modu":"LORA","datr":"SF9BW125","codr":"4/5","lsnr":12.5,"rssi":-55,"size":51,"data":"gAQAAACCdAADBwOfK3ZndsD1I1MKA4iaLR7vm39awCn3AhqdYb3eR7I2wtD6Ug9+Hqux"}]}
INFO: [up] PUSH_ACK received in 0 ms
INFO: tx_start_delay=1495 (1495.500000) - (1497, bw_delay=1.500000, notch_delay=0.000000)
INFO: Enabling TX notch filter
58.a3.33.2d.f9.a7.e5.9.0.9a.c.10.0.8.0.0.60.4.0.0.0.a0.97.3.d9.7d.7.62.end
lgw_receive:1155: FIFO content: 1 cb 0 7 33
lgw_receive:1174: [0 17]
Note: LoRa packet
INFO: [down] PULL_RESP received - token[0:0] :)

JSON down: {"txpk":{"imme":false,"tmst":773129596,"freq":866.55,"rfch":0,"powe":14,"modu":"LORA","datr":"SF10BW125","codr":"4/5","ipol":true,"size":12,"data":"YAQAAACgmANs8h0u"}}
INFO: [down] PULL_ACK received in 0 ms
lgw_receive:1155: FIFO content: 1 e 1 7 31
lgw_receive:1174: [1 17]
Note: LoRa packet
INFO: tx_start_delay=1495 (1495.500000) - (1497, bw_delay=1.500000, notch_delay=0.000000)
INFO: Enabling TX notch filter
58.a3.33.2e.14.ff.a5.9.0.9a.c.10.0.8.0.0.60.4.0.0.0.a0.98.3.6c.f2.1d.2e.end
lgw_receive:1155: FIFO content: 1 4f 1 5 31
lgw_receive:1174: [4 17]
Note: LoRa packet

INFO: Received pkt from mote: 00000004 (fcnt=118)

JSON up: {"rxpk":[{"tmst":773808692,"chan":4,"rfch":1,"freq":865.985000,"stat":1,"modu":"LORA","datr":"SF9BW125","codr":"4/5","lsnr":12.2,"rssi":-52,"size":49,"data":"gAQAAACAdgADNF19HTwNJ9yrr/QySiTjo9vn2TF1XbAAQRjBPPIVGFTRXJK081ViXQ=="}]}
INFO: [up] PUSH_ACK received in 0 ms
INFO: [down] PULL_RESP received - token[0:0] :)

JSON down: {"txpk":{"imme":false,"tmst":775808692,"freq":866.55,"rfch":0,"powe":14,"modu":"LORA","datr":"SF10BW125","codr":"4/5","ipol":true,"size":12,"data":"YAQAAACgmQPbMQFR"}}
INFO: tx_start_delay=1495 (1495.500000) - (1497, bw_delay=1.500000, notch_delay=0.000000)
INFO: Enabling TX notch filter
58.a3.33.2e.3d.e0.dd.9.0.9a.c.10.0.8.0.0.60.4.0.0.0.a0.99.3.db.31.1.51.end
lgw_receive:1155: FIFO content: 1 90 1 5 31
lgw_receive:1174: [0 17]
Note: LoRa packet

INFO: Received pkt from mote: 00000004 (fcnt=119)

JSON up: {"rxpk":[{"tmst":776487916,"chan":0,"rfch":0,"freq":865.062500,"stat":1,"modu":"LORA","datr":"SF9BW125","codr":"4/5","lsnr":-3.2,"rssi":-49,"size":49,"data":"gAQAAACAdwADm+5eYoavg3gKXjI739/B4i98Rh2gdvnfgg+fHjaqr/rkGk/xK/t9yg=="}]}
INFO: [up] PUSH_ACK received in 0 ms
INFO: [down] PULL_RESP received - token[0:0] :)

JSON down: {"txpk":{"imme":false,"tmst":778487916,"freq":866.55,"rfch":0,"powe":14,"modu":"LORA","datr":"SF10BW125","codr":"4/5","ipol":true,"size":12,"data":"YAQAAACgmgOPsQVl"}}
lgw_receive:1155: FIFO content: 1 d1 1 5 33
lgw_receive:1174: [0 17]
Note: LoRa packet

[mcoracin]

As I have already asked several times: is there another gateway next to you, configured with same channel, that could receive the missing packet and ACK it?

If not, the possibilities are:

• the missing packet has not been demodulated for some reason (CRC error, you should see it if you enable DEBUG_HAL logs)
• the end-node never sent this packet: do you have an SDR dongle to see what is happening in the air?

[mcoracin]

By the way, even if there is another gateway nearby, you should see the corresponding rxpk on this gateway, so that would not explain why you don't see it here, and the CRC error could still be a possibility. But it is just to understand how a packet that we don't see here could be ACKed...

[vikasrohal]

I am using single Gateway and No another gateway in my city,
No Debug message of Dropped packet.
I made some changes in End Device code for Regress testing of End Device, Gateway, packet Forwarder and server.
Changes are: LORAWAN_DUTYCYCLE_ON false, send packets fast as possible(Disable TxNextPacketTimer timer and disable Sleep mode in main.c )

[mcoracin]

Are you sure that the missing packet is actually sent over the air?

[vikasrohal]

yes, I have log of missed packet with received ACK on End Device

[vikasrohal]

Its End Device Bug, Now working fine.
End Device Bug Detail
Lora-net/LoRaMac-node#287