About the timing of fetching in DeviceTimeAns

[zouOrange]

When I use the DEVICE_TIME_REQ command, in SRV_MAC_DEVICE_TIME_ANS I read that the returned GPS time is 1669186181 and the converted UTC time is Nov 27, 2032 06:49:23. Obviously this is the wrong value. Why does this happen?Is this time generated by the gateway’s GPS or by the server?

[mluis1]

The value 1669186181 looks to be the UTC time. This value corresponds to 1353221399 GPS time.
It looks to be confirmed by the below result obtained by using https://www.andrews.edu/~tzs/timeconv/timeconvert.php

The LoRaWAN specifications say that the value of SRV_MAC_DEVICE_TIME_ANS must be the GPS time.

The handling of SRV_MAC_DEVICE_TIME_ANS is done as follows under this project

LoRaMac-node/src/mac/LoRaMac.c

Lines 2537 to 2578 in 23bb8cf

	case SRV_MAC_DEVICE_TIME_ANS:
	{
	// The mote time can be updated only when the time is received in classA
	// receive windows only.
	if( LoRaMacConfirmQueueIsCmdActive( MLME_DEVICE_TIME ) == true )
	{
	LoRaMacConfirmQueueSetStatus( LORAMAC_EVENT_INFO_STATUS_OK, MLME_DEVICE_TIME );
	SysTime_t gpsEpochTime = { 0 };
	SysTime_t sysTime = { 0 };
	SysTime_t sysTimeCurrent = { 0 };
	gpsEpochTime.Seconds = ( uint32_t )payload[macIndex++];
	gpsEpochTime.Seconds |= ( uint32_t )payload[macIndex++] << 8;
	gpsEpochTime.Seconds |= ( uint32_t )payload[macIndex++] << 16;
	gpsEpochTime.Seconds |= ( uint32_t )payload[macIndex++] << 24;
	gpsEpochTime.SubSeconds = payload[macIndex++];
	// Convert the fractional second received in ms
	// round( pow( 0.5, 8.0 ) * 1000 ) = 3.90625
	gpsEpochTime.SubSeconds = ( int16_t )( ( ( int32_t )gpsEpochTime.SubSeconds * 1000 ) >> 8 );
	// Copy received GPS Epoch time into system time
	sysTime = gpsEpochTime;
	// Add Unix to Gps epoch offset. The system time is based on Unix time.
	sysTime.Seconds += UNIX_GPS_EPOCH_OFFSET;
	// Compensate time difference between Tx Done time and now
	sysTimeCurrent = SysTimeGet( );
	sysTime = SysTimeAdd( sysTimeCurrent, SysTimeSub( sysTime, MacCtx.LastTxSysTime ) );
	// Apply the new system time.
	SysTimeSet( sysTime );
	LoRaMacClassBDeviceTimeAns( );
	MacCtx.McpsIndication.DeviceTimeAnsReceived = true;
	}
	else
	{
	// Incase of other receive windows the Device Time Answer is not received.
	MacCtx.McpsIndication.DeviceTimeAnsReceived = false;
	}
	break;

As you can observe the expected received time is the time since GPS epoch. Which then is converted to UNIX time for the system clock. (Please note that it excludes the leap seconds. Meaning that the UNIX time will be off by a few seconds)

Where have you obtained this value?
Is it extracted from the server logs for downlink?
Is it displayed on the end-device upon reception of the SRV_MAC_DEVICE_TIME_ANS?

In the future it would be nice if you could post this kind of questions on the project Discussions tab. It is a better place to engage discussions and then we can agree if it is an issue or not.
If you don't mind I move this issue to the Discussions tab.

[zouOrange]

Can you give me some advice? About returning BEACON_STATE_LOST.

[zouOrange]

Yes, I get this value in SRV_MAC_DEVICE_TIME_ANS in end-device.

sysTime = SysTimeAdd( sysTimeCurrent, SysTimeSub( sysTime, MacCtx.LastTxSysTime ) );
printf("time=%u.%d\r\n", (unsigned int)sysTime.Seconds, 

Because I did not appear LORAMAC_EVENT_INFO_STATUS_OK in MlmeConfirm when I entered ClassB. Whether it has anything to do with the time gained. So I checked SRV_MAC_DEVICE_TIME_ANS.

In LoRaMacClassBProcessBeacon function, I capture the BEACON_STATE_LOST.
It would be nice if you had any suggestions。

static void MlmeConfirm( MlmeConfirm_t *mlmeConfirm )
{
    LmHandlerPackagesNotify( PACKAGE_MLME_CONFIRM, mlmeConfirm );
    switch( mlmeConfirm->MlmeRequest )
   {
     case MLME_BEACON_ACQUISITION:
    {
         if( mlmeConfirm->Status == LORAMAC_EVENT_INFO_STATUS_OK )
         {
             LmHandlerPingSlotReq( 3 );
             printf("BEA_ACQ_OK\r\n");
         }
       else
      {
        // Beacon not acquired
       // Request Device Time again.
        LmHandlerDeviceTimeReq( );
        printf("BEA_ACQ_FAIL\r\n");
      }
  }
   break;
}

I certainly don't mind moving to the Discussions tab.