Network time +/- one minute.

[PeteMilligan99]

All, Thanks for a great solution. I've ported to a BGM220 from Silabs & after resolving a few timing issues, I'm up and running with a BLE bridge. I am however struggling with a common issue; 'How do I get a network time'. I'm not after millisecond accuracy, minute accuracy would be absolutely fine. I came across the following:

https://github.com/mcci-catena/arduino-lmic/blob/master/examples/ttn-otaa-network-time/ttn-otaa-network-time.ino

Can anyone provide me with pointers to do the same with this framework?

Pete

[mluis1]

You have 2 possibilities:

1. Use the MAC command DeviceTimeReq
2. Use the protocol defined on LoRaWAN® Application Layer Clock Synchronization Specification v1.0.0 document.

Option 1 is the most accurate and simplest to achieve.
Option 2 requires an implementation of the protocol on the application server as well. This implementation tries to use DeviceTimeReq MAC command, in case the networks server does not support it (LoRaWAN versions <= 1.0.2) the implementation will use the less accurate method to get the time (1 second resolution).

In order to use option 1 the user can use something similar to below API implementation. Currently this API is not public, in order to make it public just remove the static keyword and declare the function prototype on LmHandler.h file. (We will make this function public in future releases of the project)
This function just adds the DeviceTimeReq MAC command to the list of MAC commands to be sent on the next uplink.
The system time is automatically updated by the MAC layer.

LoRaMac-node/src/apps/LoRaMac/common/LmHandler/LmHandler.c

Lines 520 to 539 in 5780612

	static LmHandlerErrorStatus_t LmHandlerDeviceTimeReq( void )
	{
	LoRaMacStatus_t status;
	MlmeReq_t mlmeReq;
	mlmeReq.Type = MLME_DEVICE_TIME;
	status = LoRaMacMlmeRequest( &mlmeReq );
	LmHandlerCallbacks->OnMacMlmeRequest( status, &mlmeReq, mlmeReq.ReqReturn.DutyCycleWaitTime );
	DutyCycleWaitTime = mlmeReq.ReqReturn.DutyCycleWaitTime;
	if( status == LORAMAC_STATUS_OK )
	{
	return LORAMAC_HANDLER_SUCCESS;
	}
	else
	{
	return LORAMAC_HANDLER_ERROR;
	}
	}

An example on how to use option 2 is provided by the fuota-test-01 application example.

Please note that the provided time does not take in account the leap seconds as the provided time is based on the GPS epoch.
In order to be able to take in account the leap seconds one must implement a way to provide that information to the end-device. A downlink on a specific FPort can be used to convey such information.

[PeteMilligan99]

Mluis1 - Thank you. I chose option 1 & have the MAC commands being received on Loriot. The downlinks seem sporadic - I'll look into that. Assuming GPS to UTC offset, no problem there either. On reception of the MAC downlink, I'd favour squirting this directly into the BLE devices rather than maintaining the time on an RTC (Which would be problematic on a Bluetooth stack). To help me navigate the framework somewhat, what is the reception point in the MAC? Pete

[PeteMilligan99]

All done here - Checked out LoRaMac.c for the logic under case SRV_MAC_DEVICE_TIME_ANS & found what I was looking for. Thanks for your help.