Wireless timer synchronization among nRF5 devices revisited

[kont40]

Hello to the community!

I have two nRF52832 sensor nodes and aim to implement synchronized sampling of all sensors, including synchronization between sensors of the two nodes. I went through this article   Wireless timer synchronization among nRF5 devices . Yet, before starting work, I wish to make sure:

(1) Can we apply the method described in   Wireless timer synchronization among nRF5 devices  irrespective of the communication mode; i.e., I am currently using notifications to send the sensor data to the client continuously? Is there any danger that implementing this method will affect the existing communication?

(2) Synchronization in sampling shall remain valid continuously, e.g., after one hour of data collection. I guess per-sample synchronization may not be efficient, and the proper solution will involve synchronizing the sampling rate timers between the two nodes at regular intervals, e.g., every 10 seconds. Any recommendations regarding choosing the proper strategy and avoiding possible pitfalls will be appreciated.

[Susheel Nuguru]

(1) Can we apply the method described in   Wireless timer synchronization among nRF5 devices  irrespective of the communication mode; i.e., I am currently using notifications to send the sensor data to the client continuously? Is there any danger that implementing this method will affect the existing communication?

You should be able to use this synchronization method even using a BLE connection(s) in parallel. Audun (Author of that blog) has mentioned that Radio Timeslot API was used to configure the radio and timers to have the maximum predictability when using this along with other protocols that also use Timeslot API. Note that the timeslot frequency is  100Hz (10ms interval) so the connection interval of BLE connection(s) will affect the chances of this synchronization module getting a timeslot every 10ms. More frequent connection interval and more connections in parallel will affect the accuracy of this synchronization module as the chances of requested timeslots reduces with faster connection intervals.

(2) Synchronization in sampling shall remain valid continuously, e.g., after one hour of data collection. I guess per-sample synchronization may not be efficient, and the proper solution will involve synchronizing the sampling rate timers between the two nodes at regular intervals, e.g., every 10 seconds. Any recommendations regarding choosing the proper strategy and avoiding possible pitfalls will be appreciated.

Do you mean to say that over longer period of time the synchronization per-sample will jitter in itself? Hmm, I do not see why this should happen, but I haven't processed the pitfalls of this communication completely as I have gone through this blog just today to be able to assist you. If you do care to help me explain what exactly are the details of this pitfalls, then maybe I can ask Audun or try myself to assist you with a strategy to come around that pitfall.

[kont40]

 Susheel Nuguru 

Thank you for the very helpful comments. So far I have succeeded to run the synchronization demo. Next questions are:

(1):

Susheel Nuguru said:

More frequent connection interval and more connections in parallel will affect the accuracy of this synchronization module

(a) What would be the optimal connection interval to make sure the 100 Hz synchronization is ensured?  (I am currently using min connection interval of 7.5 ms and max connection interval of 10 ms, which were good for my application before considering the synchronization).

(b) This eventually means, that in some applications it maybe challenging to achieve synchronization at frequencies higher than 100 Hz, as this would mean producing higher volumes of data requiring shorter connection intervals, which will make it more challenging to get timeslots properly.

(2) I am currently concerned regarding the proper place to call the sensor sampling code at the master and slave side.

So far I am toggling the test pin into RADIO_IRQHandler:
- for the slave device upon the end event of RADIO_STATE_RX;
- for the master device upon the end event of RADIO_STATE_TX;

void RADIO_IRQHandler(void)
{
    if (NRF_RADIO->EVENTS_END != 0)
    {
        NRF_RADIO->EVENTS_END = 0;
        (void)NRF_RADIO->EVENTS_END;
        
        if (m_radio_state == RADIO_STATE_RX &&
           (NRF_RADIO->CRCSTATUS & RADIO_CRCSTATUS_CRCSTATUS_Msk) == (RADIO_CRCSTATUS_CRCSTATUS_CRCOk << RADIO_CRCSTATUS_CRCSTATUS_Pos))
        {
            sync_timer_offset_compensate();
            ++m_rcv_count;
                    
                    /* slave node: the code to obtain sensor sample*/
                        nrf_drv_gpiote_out_toggle(10);
        }
                
                
                /* master node: the code to obtain sensor sample*/
        if (m_radio_state == RADIO_STATE_TX)
        {
                        nrf_drv_gpiote_out_toggle(10);
        }                
                
    }
}

In this way, it seems like I am indeed getting the 100 Hz synchronized pulses of both nodes.
However, I am not sure if these are the right places to put my sensor sample acquisition code;
I am also not sure whether I have to add more conditions to the if (m_radio_state == RADIO_STATE_TX) condition.

(3) What could you suggest as an optimal solution for the MCUs on both sides to check whether the synchronization is happening properly? I aim to discard data or cancel measurements automatically in case of synchronization failure.