I’ve got a curious problem with messages that I can see arriving on the gateway, and all but a couple of them don’t arrive at the application.
I’ve tried a bunch of things to be able to understand what might be going on, including spending hours with the sensor manufacturer’s application engineer to try and find out what might be happening, with no idea. But at least the problem is reproducable!
This is with a new to the market internal air quality sensor, so I don’t want to mention the manufacturer straight away, as this could just be teething trouble with a new device. I’ve tried with both OTAA and ABP with the same results, and tried with ADR on and off.
What’s the best way to try and find the cause of this packet loss?
The sensor is turned on an working as it expects to sending (in this case) every 2 minutes (although I started at every 20 minutes), using OTAA the join works as expected, or using ADB the sensor starts sending as expected. While the gateway local to me (on the roof of the building the sensor is in) shows receiving every expected message, the message
cnt matches the sensor’s expectations, and I can decode all the LoRaWAN messages correctly using
lora-packet with the appkey and devkey from the application, only 2 or 3 of the packets actually arrive at the application and the rest go missing somewhere between the gateway and the application.
Every packet for the application that the gateway receives should be decoded and arrive at the application.
Only 2 or 3 of the messages arrive at the application, the rest go missing.
These screenshots are from rebooting the sensor just now and watching the sensor traffic only (uses ADB):
Sometimes, packet 1 makes it through, and occasionally I’ve seen number 4, but never anything beyond that.
2: 0175640367FF0004686106659300C8004700056A2B00077DF203087D000009735F2703670A0104684E06659300C8004700 3: 056A2B00077DF203087D000009735F27
And the local gateway traffic, filtered by device ID:
Device Address: 260117E6 Network Session Key: 0583B50A5A0EEE11A1504A5C20822694 Application Session Key: FCB12639D8E7341EDFAAD71711DD5E2E
Physical payloads as seen by the gateway:
1: 40E61701260101000D55369CDEDAAA342470773F2637282DB54DD92F3829526465A60D01EE6ECB3DB58543 2: 40E6170126000200555350BCB55AD3E62C49247A1633491D52EB9828596734FFCF5B7BA601DE35527196BEC33DD3EB3677155019BEFCB88ED8CA246395B8 3: 40E6170126000300554FB8CD427EB690DDADF5AE07D942D066FDD34396 4: 40E61701260104000D553A548BE9C7E26CAF9D76635F57A0B33DB81530F6E4ACB392E35C8F83DAD7101B23A402 5: 40E61701260105000D559A94A00DD7FF486EC7DCF6715467A26EAC05F4FA5548A7A54EB34D8FCDC5FA3B53DB4F 6: 40E61701260106000D55769EA7804EFECD84656A8C920E8DC0220D8F05283A12F9AADE422CA2B974CCC7D5F086 7: 40E61701260107000D5587360B69BFBB7C854D80F4F3FCF463D5CD9B2121E8D519ABF76FBF30BC0EBBC91F638D 8: 40E61701260108000D553DCB5B7D3EC7A8D7BE4E4D25F4826BC531B56772DD592922BD7F4AB14F45464931FA7F 9: 40E61701260109000D550A7B826F8E5D4AF1682DBC327D8F065ABFD12D53599B21BC1483C59E17FD3956A2D422 10: 40E6170126010A000D559055A1F59326FE9D9E743B11850183EA824362F4BC94DFB28318AD72B93898694630E0
And the decoded versions, using the keys above:
The payload data is a little esoteric, but it’s using a variant of the Cayenne, except message 1 that encodes device/firmware info. But what’s confusing, is that all of the packet data can be decoded properly.
What am I missing here?
What’s the best way to go about troubleshooting to find these missing messages?