what does the 'alcsync timestamp' exactly mean?

[mkdthanga]

Hi, I receive the device data 'alcsync timestamp' from the Semtech Lora cloud (topic in chirpstack AS: '#/integration'). I thought it is the Almanac update date of the Edge Tracker device, but it seems to be different when I checked the recent almanac updated date row in the LoRa Edge config (BLE Android App) .

If it is the timestamp when the device receives satellite coverage, the 'position timestamp' which is included in the 'position solution' element should be the same, but it varies from this 'alcsync timestamp', why is that?! please see the screenshot (highlighted texts) below:

can anyone please help me with this confusion about 'alcsync timestamp' received from Semtech LoRa Cloud Portal?

Regards, Thangaraj

[smtcbboulet]

Hello Thangaraj,

Sorry for the delay. where come from this dashboard ? I asked to the developer of chirpstack and he told me that it didn't come from chirpstack.

alcsync_timestamp represents the last date where the Modem-E has been synchronized by loracloud. the position timestamp is as you mentioned the timestamp of the position solution.

Regards,

Benjamin

[mkdthanga]

Hello, It is a Thingsboard dashboard, receiving messages from LoRa cloud via Chirpstack integration feature! But now I am clear that the 'alcsync_timestamp' is the time when the edge_tracker's Modem-E synchronised with the LoRa cloud. Thank you very much.

Also, Is there any rule/timeout like the Modem-E syncs 'n' times per day with LoRa cloud? Or under specific condition it happens? Because I couldn't interpret any rules on how and when this synchronisation happens.

Regards, Thangaraj

On Mon, 29 Mar 2021, 15:30 smtcbboulet, @.***> wrote:

Hello Thangaraj,

Sorry for the delay. where come from this dashboard ? I asked to the developer of chirpstack and he told me that it didn't come from chirpstack.

alcsync_timestamp represents the last date where the Modem-E has been synchronized by loracloud. the position timestamp is as you mentioned the timestamp of the position solution.

Regards,

Benjamin

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/Lora-net/lora_edge_tracker_ref_design/issues/2#issuecomment-809378473, or unsubscribe https://github.com/notifications/unsubscribe-auth/AIZVLSGRHQA3L2GCMK6AQFTTGCFJZANCNFSM4ZLBNYBQ .

[smtcbboulet]

The Modem-E alc_sync rule is in the reference manual chapter 6.52.

Here is the rule :

The ALC Sync service can also be enabled when the modem has not joined. Once joined, the modem automatically sends the ALC Sync uplink to get the time from the network. The ALC sync service is managed by the modem, and the ALC Sync works in three phases: sync-recent, sync-longtime and not-sync: • Sync-recent: If the modem receives an ALC Sync downlink, an Event time sync is generated to inform the host MCU. During the following 3 days, the ALC Sync sends an uplink every 36 hours with the bit AnsRequired =0. • Sync-longtime: 3 days after the modem receives the ALC Sync downlink, the modem continues to send ALC Sync uplinks every 36 hours, but with the bit AnsRequired =1. • Not-sync: the modem does not have time, or the time is not updated by the host MCU or by the ALC Sync service during 6 days. In that case, time synchronisation is lost and an Event time desync is generated to inform the host MCU. Therefore, the modem does not provide time, and the command GetTime(...) returns 0. The modem accelerates the time re-sync in the following ways: 3 ALC Sync uplinks at 128s intervals, then 1 uplink every 4 hours for the first 24 hours, and then 1 uplink every 36 hours. All these ALC Sync uplinks have the bit AnsRequired =1.

Regards,

Ben

[mkdthanga]

thank you very much @smtcbboulet!