time synchronization across different nodes in a mesh network, single hop as well as multi hop.

[khosla]

I am working on time synchronizations between different nodes in a mesh network. I have earlier worked on the radio and the ppi examples given. I wish to generate time stamps at each send and receive events between two different nodes for which i am using the nRF radio along with two crystal oscillators, 16 M XOSC as well as 32.768 KHz XOSC with quartz crystal. Could you let me know that if i am using the ppi with the radio functionality, how do i define the two nodes in my code between which i want to send packets. then can i extend this case for n nodes too.

[khosla]

You can find the receiver functionality slightly above the main function. Since i am still experimenting on this, i was earlier thinking to collect the timestamp information (send and receive times) with the help of wireshark and analyser. But this won't be precise enough since there is no idea of the clocks analyser is using and that wireshark receive times can't be relied on. Although this could be done as a verification part only. I now ought to add some more timer functionality to achieve this. But i had another query that if i use the capture functionality in hardware timer, how do i go about it without CPU intervention, as we are normally doing this by calling TASKS_CAPTURE for each capture event in the code. But this involves CPU. What's the other CPU independent way for doing this. Would appreciate your advice!!!

[Hung Bui]

Yes I can see start_reciever() but I don't see when it's called.

Yes, using wireshark and analyser is for verification. The question is how you are planing to do the actual time synchronization ? Do you have an idea of what you are trying to achieve ?

Basically please explain what you meant here: I wish to generate time stamps at each send and receive events between two different nodes for which i am using the nRF radio

The main point of time synchronization is to calibrate multiple devices to start a timer at the same time. By having the synchronized timer we can add a time stamp on every data we sample or execute a command at the same time.

What we do in the example I pointed you to (which only takes 15 minutes to read and 5 minutes to test ) is to do TASKS_CAPTURE on the timer of the master, add the latency (consistent time delta by using another timer), then put that value in the radio packet.

On the receiver/slave side, when receiving the packet, it uses that timer captured value to update its own timer with that value (includes the delta). After that the timers on both device should be synchronized.

Note that this solution is only for a start network, where one single node can update multiple nodes around it. I don't know how do you plan to do it for a mesh network. That why I keep asking how do you plan to do your mesh.

And yes, we don't have a solution to avoid CPU involve here. We need the CPU to put the captured timer value to radio packet. But we can have a consistent time for doing that by using another timer and PPI to start radio transmission a fixed time after the capture task.

[khosla]

01200555.pdf

This is a part of my thesis work basically. I am using the tiny sync algorithm to achieve this. Refer to fig 1 and then section 4 on page 1270. basically i need to collect the three time stamps, t_o, t_b and t_r for each probe message sent. The packet itself would be carrying the timestamp to the destination.

U mean to say that while using timers too for all events we would always be requiring the CPU. Although timers have the inbuilt functionality to minimize CPU intervention. There are probably some related tasks of Nordic in the SDK itself that have been done without using CPU. But i still need to figure out how to do the capture tasks independent of the CPU.

[khosla]

Also i would be just using capture events for capturing the event times. So no compare events will be involved.

[Hung Bui]

Thanks for providing the document. My understanding is that you need to capture time stamp on both side and your approach require time-stamp packet from both direction to do calculation and estimate a12, b12 from that.

Our approach is a little bit different that we only use packet from one direction and try to reset the timer on node 2 to set the offset b12 to zero using the time stamp. We reduce the affect of the drift a12 by keep sending time stamp packet so that the drift create by the timer won't exceed the real time requirement.

You can re-use what we implemented in our example on the transmission side. Use PPI to trigger a TASK_CAPTURE of the free run timer from COMPARE event of another timer (TIMER2) (You can ignore this, and trigger TASK_CAPTURE your way) Then use CPU to put the Captured value of the freerun timer to radio packet. Then TIMER2 will trigger the transmission of the radio after that using PPI. (This is important and shouldn't be ignored) The involvement of the CPU here is only to put the timestamp into radio packet. It wouldn't cause any un-predictable latency because we will use the TIMER2 and PPI to trigger radio. Most of the task is done using PPI and the latency is consistent.