Issue with Messages not being Confirmed by Chirpstack

Setup and configuration
#1

Hello,

I am running Chirpstack and I have encountered an issue that I’m hoping to get some help with. I searched the forums, but didn’t find any issues substantially similar to mine.

I can provide any logs, configuration, or additional information required upon request.

When I boot up my LoRa device, my sensor will not successfully communicate correctly for a period of time before the sensor internally resets and requests a new Join. This is repeatable and happens every time.

Here is the sequence if the sensor and LoRa device are turned on at the same time:
-JoinRequest
-JoinAccept
-ConfirmedUp
-UnconfirmedDown
-ConfirmedUp
-ConfirmedUp
-ConfirmedUp
-ConfirmedUp
-ConfirmedUp
-…etc until the sensor does an internal reset
-JoinRequest
-JoinAccept
-ConfirmedUp
-UnconfirmedDown
-ConfirmedUp
-UnconfirmedDown
-…and so on, it works as expected now

If the LoRa device is restarted but the sensor is not, it looks like this:
-ConfirmedUp
-ConfirmedUp
-ConfirmedUp
-ConfirmedUp
-ConfirmedUp
-…etc until the sensor does an internal reset
-JoinRequest
-JoinAccept
-ConfirmedUp
-UnconfirmedDown
-ConfirmedUp
-UnconfirmedDown
-…and so on, it works as expected now

I have looked at the transmissions as best I can, but I don’t understand what is going on or why the message are being “ignored” by Chirpstack until the device does a Join the second time.

There is a lot of data, so I will link it:
Cold Start Test
Device Frames: Cold_Start_Device_Frames - Pastebin.com
Gateway Frames: Cold_Start_Gateway_Frames - Pastebin.com
Test Narrative: Cold_Start_Test_Narrative - Pastebin.com
Screenshots (provided for time stamps on transmissions): https://imgur.com/a/ceOvM6s

Reboot Test
Device Frames: Reboot_Device_Frames - Pastebin.com
Device Data: Reboot_Device_Data - Pastebin.com
Gateway Frames: Reboot_Gateway_Frames - Pastebin.com
Test Narrative: Reboot_Test_Narrative - Pastebin.com
Screenshots (provided for time stamps on transmissions): https://imgur.com/a/ILJz5zH

Please let me know if there’s any other data you need to help troubleshoot this and I’ll provide it.

Thank you very much!

#2

What do you mean by the “LoRa device” vs. the “sensor” ?

#3

Hello,

LoRa Device: the LoRa basestation/gateway that is running Chirpstack in docker. Restarting this causes Chirpstack to be restarted.

sensor: the LoRa end device (the sensor that is collecting data and sending it to the basestation via LoRa transmissions)

I apologize for the confusion (and can’t find a way to edit my original post to add clarity).

#4

Ah, okay, I suspect that’s the problem.

You probably need to configure persistence, especially of the redis component.

Also generally you want to restart something like this as rarely as possible - a traditional architecture would run chirpstack in the cloud so that gateways can go up and down, even be replaced with very little impact since all the actual records are in the server which keeps running with rare restarts and minimal downtown.

#5

Thanks for the suggestion. For this particular project, we are unable to move this processing to the cloud.

Redis is set up with append only persistence to enable the greatest durability of data. Postgres is also set up with appropriate options for data persistence and durability.

The setup works as expected with other LoRa sensors, it’s just this particular model of sensor that seems to “get lost.” I suspect the sensor firmware is misbehaving in some way.

As I am still somewhat new to LoRa (I have about a year of experience working with Chirpstack), I was hoping to have other’s review the information to see if there was an obvious error in configuration - or if the sensor was somehow violating LoRa spec or otherwise misbehaving.

Thank you!