Time_stamping_value?

[MMG]

Hi Nordic Devzone,

First i want to make sure that if the clock being used by softdevice is the LFCLK (32kHz) and its counter register is 24bits ? and which prescaler is being used? because I want to send the local time (clock value ) from one device to another using Bluetooth mesh connectivity, but when i'm reading the time of the receive message from the ( const access_message_rx_t * p_message) the value of timestamp is greater than 24 bits value actually its a 32bit value , so if the counter register in the LFCLK is 24 bits how would it be possible to count up to 32 bits value ? does it mean that the clock begin used for time stamping the receive messages is different than the clock used by softdevice ? And what is the best way to keep track of time while using the softdevice ?

Thank you in advance

[MMG]

Hi Hung , Actually I'm interested in time for my application where global time could provide some more accurate data, I assume it would be similar to synchronization-like behaviour. Hence, I was wondering about global time and if i can use the timer_now() to get time on TIMER0 in my application? Have I understood it correctly that the softdevice is responsible for transferring and receiving packets then when it receives the las part of the message it will signal the reception and the the TIMER0 value will be assigned to the timestamp?

Also, timeslot mechanism is not that clear for me; For instance, how does the softdevice provide that and when does the timeslot begin and end? Would it be possible to determine when the TIMER0 will be reset or define a static timeslot length? Could you elaborate a little bit more on that?

Thank you very much for your help!

[Hung Bui]

Hi MMG, Actually we do use RTC to count the time between timeslot. So the timestamp is calculated by TIMER0 when inside timeslot and by RTC0 when outside of timeslot (Softdevice activity).

Note, again, MESH is not handled by softdevice. All Mesh packet is handled by mesh stack, directly from the radio. BLE Softdevice here is used so that the device can do BLE if needed, such as advertising, beaconing, GATT connection etc.

To read more about timeslot, please have a look at Multiprotocol support in the Softdevice spec, and have a look at the timeslot tutorial in the Tutorials on this devzone.

Regarding your application, from my understanding, our current implementation might not be ready to use for time synchronization out of the box because there is no mechanism to synchronize time between nodes. We need a timer keeper that send sync packets to other nodes to get the offset from each node. That sync packets need to be sent periodically to all nodes to correct the drift of the clock on each node.

Then the local time and the offset should be added in each TX packet to tell other node about the exact time when the packet is send from the source.

[MMG]

Hi Hung, Thanks for the link to study! And once again, thanks for your explanation!

I see, so then there is no use of softdevice when using Bluetooth Mesh? If that's true, then if we take a time sample(our local time ) using TIMER0 (calling time_now()) and send this value plus the calculated drift in our TX packet, it should be enough for my use case? Since in such case, I assume the timeslot (on TIMER0) will be running all the time in our communication and we can take our time sample using TIMER0? or will the softdevice still be used which means we cannot rely only on TIMER0? Are you aware of any ongoing implementation that adds a timestamp from the sending node?

[Hung Bui]

It's not entirely true that there is no use of softdevice when using Mesh. We still use timeslot mechanism by softdevice :)

The way it works is that the mesh stack request timeslot from softdevice, softdevice will grant a timeslot to the application when it possible. Max timeslot length is 100ms and it can be extended until 128 seconds. In our case, softdevice won't do much stuff, so most of the time the mesh stack has all those 128 seconds, but it can't be guarantee. And timeslot will be closed and open again because of the limit.

Everytime a new timeslot is granted, TIMER0 will be reset to 0.

So you can't rely entirely on TIMER0 as it will be reset. You can use what we are doing now RTC+TIMER0.

But I would suggest you just use a new timer , say TIMER1 to keep track of the timing. Then you don't have to worry about timeslot etc.

But still even if you use a separate timer for time keeping, how do you sync time between nodes ? How do you calculate the drift and the initial offset ? Note that all devices don't start up at the same time. You need a timing master.

You can have a look at this blog.

[MMG]

That makes more sense! With another timer there is no need to consider the RTC0. Thank you for the blog post! I hadn't paid that much attention to it before but it looks you had very good accuracy, maybe I will try to include something similar.

The synchronization doesn't have to be very accurate, but I was thinking of one node being the master node, and control the other nodes (slave nodes) time. Possibly with a configuration phase that would run every now and then that would check the drift and the initial offset. Most likely it wouldn't be very accurate since there would be a lot of non-deterministic behaviour. But at least it will not reset in the middle which what I was worried about.

Thanks once again for all your help! It was very educational to receive complete answers on how the time functionality on the device worked!