Radio events clock

[Davide]

Hi, I'm doing some measurement on the radio peripheral of the nRF52840 using the generated events and a timer which is set to run at 16MHz. Radio events and Start/Capture Tasks of the timer are managed through the PPI. With such configuration can I expect to measure the time interval between radio events with 1/16MHz accuracy? From some preliminary evaluation I only get a granularity of 8MHz. Any idea?

PS: If useful I'm using SD140 with a connection established.

Thank you, Davide.

[Hung Bui]

Hi Davide, I think it should be 1/16MHz accuracy. At least it's the frequency of the timer's Tick can achieve.

Could you let me know how you connect PPI between the Radio and the Timer ?

[Davide]

The PPI is configured to connect the RADIO->EVENTS_READY with the TIMER->TASKS_START and then the counter value is captured connecting RADIO->EVENTS_ADDRESS with the TIMER->TASKS_CAPTURE. Then the timer itself triggers the execution of a routine which stops and clears the timer and retrieves the captured value.

[Hung Bui]

How did you verify that the granularity is 8MHz not 16MHz ? I would suggest you to test using a pin toggle where you can measure using logic analyzer and compare with the Timer count you have using PPI.

[Davide]

That's exactly what I did with the same result. I have some noise over the measurement (due to propagation time and clock drifts on the two devices), but I (almost) never get odd number of timer ticks. With the pin toggle tecnique I see that the noise makes the transition happen only on 8MHz edges.

[Hung Bui]

Hi Davide,

I'm sorry that we are quite short in staff now because of the summer vacation period. I can't to test right now.

It would be very nice if you can provide the firmware so we can reproduce here. I would suggest to have something like:

1. Setting up PPI, connect a GPIOTE EVENT 1 to TIMER TASKS_START

2. Setting up PPI, connect a GPIOTE EVENT 2 to TIMER TASKS_CAPTURE

3. Start a loop, trigger GPIOTE EVENT 1, put some delay , trigger GPIOTE EVENT 2

4. Print out the Captured value and go back to step 3.

This will clearly show the strange behaviour that we only have even capture value.