Hello,
I’m testing out the Chirpstack V4 using a RAK7289CV2 as gateway and ST’s Nucleo board for STM32WL family as end node (via AT commands).
The network server is running in Docker on a local machine and is based on the example available on GitHub).
The gateway is configured as Basics Station and connects to Chirpstack through LAN (no authentication).
I can do OTAA join of the network as well as send uplinks and receive downlinks. However, I have an issue with the timestamp of the uplinks from the gateway:
could you be more specific? Both gateway and the PC that hosts the Chirpstack use NTP server “pool.ntp.org”, and are connected to the local network through Ethernet.
Moreove, at the moment I’m doing tests using 3 different gateways connected to the same Chirpstack instance: 1x RAK7289C V1, 1x RAK7289C V2, 1x RAK7249. I see the issue on all of them.
I’m inclined to think that the problem is on the LNS/bridge side.
For the bridge version I’m not sure how to retrieve it, I tried running the following commmand in Chirpstack’s container but it return a blank response:
What you propose would be relevant in case the issue is gateway-related. However, I have three gateways connected to the same chirpstack instance (two RAK7289 in basics station + one RAK7249 in UDP forwarder) and I see the issue happening at the same time on 3 different gateways.
I had the system running for several days and the issue is intermittent: it might be present now, then disappear within few hours without any external intervention.
I’m inclined to think that the issue is related to the Chirpstack/bridge, but I have no idea on the root cause at the moment.
About running the Chirpstack example Docker compose: I have it running on a Windows 11 host PC which is configured to run NTP synchronization hourly with pool.ntp.org. How does the chirpstack containers perform NTP synchronization? Does they take the timestamp from the Windows host OS? Or does they synchronize autonomously via NTP?
Hello forum,
I’m adding another piece of information.
I have an STM32WL nucleo board that simulate an end node. The firmware make use of LoRaWAN timesync to set the internal RTC.
The timesync is generally working fine. However, while the LNS is experiencing the “timestamp issue”, the device might receive a completely wrong timestamp:
As you can see in this log, the timesync at line 12 reports timestamp 315964783.928 (unix epoch) that roughly corresponds to January 6th 1980 00:00. The timesync is repeated at line 16, this time with a valid timestamp.
What’s going on? This kind of behaviour is catastrophic since I need to implement acquisition of timestamped events.
