Value returned by smtc_modem_hal_get_time_in_s and application layer clock synchronization (ALCSync)

[MartinBP]

According to the documentation smtc_modem_hal_get_time_in_s should return the uptime in seconds.

See https://github.com/Lora-net/SWL2001/blob/master/lbm_lib/PORTING_GUIDE.md#uint32_t-smtc_modem_hal_get_time_in_s-void-

Brief: Provide the time since startup, in seconds. LoRa Basics Modem uses this command to help perform various LoRaWAN® activities that do not have significant time accuracy requirements, such as NbTrans retransmissions.
Return: The current system uptime in seconds.

This is inconsistent with the documentation in smtc_modem_hal.h

@brief Returns the current time in seconds
@remark Used for scheduling autonomous retransmissions (i.e: NbTrans),
transmitting MAC answers, basically any delay without accurate time
constraints. It is also used to measure the time spent inside the
LoRaWAN process for the integrated failsafe.
@return uint32_t Current time in seconds

Looking at the example in "lbm_applications/1_thread_x_on_stm32_u5/" the seconds returned are seconds since 01/01/2000.
Call stack:

• smtc_modem_hal_get_time_in_s
• hal_rtc_get_time_s
• rtc_get_calendar_time
• rtc_get_timestamp_in_ticks

Finally it looks like alcsync_build_ans_payload in lorawan_alcsync_v1.0.0.c and lorawan_alcsync_v2.0.0.c uses smtc_modem_hal_get_time_in_s as input to alc_sync_construct_app_time_request.

alc_sync_construct_app_time_request requires a device_time which is GPS epoch. See documentation below.

@brief Construct the applicative time request
@param [in] lorawan_alcsync_ctx_t ctx Clock sync pointer context
@param [in] device_time DeviceTime is the current end-device clock and is expressed as the time in seconds
since 00:00:00, Sunday 6 th of January 1980 (start of the GPS epoch) modulo 2^32
@param [in] ans_required If the AnsRequired bit is set to 1 the end-device expects an answer whether its
clock is well synchronized or not. If this bit is set to 0, this signals to the AS
that it only needs to answer if the end-device clock is de-synchronized.
@return None
static void alc_sync_construct_app_time_request( lorawan_alcsync_ctx_t ctx, uint32_t device_time,
uint8_t ans_required );

This all leaves me a little bit confused.

Given that smtc_modem_hal_get_time_in_s is used for timing it makes sense if it is a monotonic time like the porting guide describes.
Have I misunderstood something in the ALC implementation or why is smtc_modem_hal_get_time_in_s used in alcsync_build_ans_payload to create the payload?

[opeyrard]

Hi,
You are right, smtc_modem_hal_get_time_in_s is used for timing and it makes sense if it is a monotonic time like the porting guide describes.
Just to clarify, in case it could help, in smtc_modem_hal.h, @brief Returns the current time in seconds of the CPU. This is not the GPS epoch time.
On the contrary, the ALCSYNC package returns the GPS epoch time.

Many thanks,
Best regards.

[MartinBP]

Thanks for confirming.

I missed that the ALCSYNC time would be corrected by "lorawan_alcsync_ctx[idx].time_correction_s". In my case that variable was still 0 because I did not receive an ALCSYNC answer/response yet.

I'm closing this issue.
/Martin