Access Gazell Heartbeat Timer

[MorelNexus]

Is there a way to access the Gazell heartbeat timer? Ideally I would have a callback to my application when the heartbeat occurs. The main motivation for this would be to try to use the Gazell heartbeat to synchronize clocks between Gazell devices and a host.

I am using an nRF51 dev kit (nRF51422).

Thanks,

Kevin

[Kenneth]

Likely not no.

Maybe it can be possible to create a PPI channel from the timer0 compare0 event to your own timer in some way?
http://infocenter.nordicsemi.com/topic/com.nordic.infocenter.sdk5.v12.3.0/gzll_02_user_guide.html?cp=4_0_7_5_0_2#gzll_resources 

[MorelNexus]

This approach seems to be working, however the results are different than I expected.

Setup:

• PPI channel uses the Timer2 Compare0 event (Gazell's heartbeat) to clear Timer0.
• Timer0 is set to run at 1 MHz and Timer0 Compare0 is set to raise an event at 1 tick. The event handler increments the heartbeat_counter variable.
• At 1 second intervals (based on a Timer1 event), heartbeat_counter is written to the virtual COM port and then heartbeat_counter is reset to 0. The printout should be the number of heartbeats in the last second.
• I have one Gazell device and one host sending data back and forth continually, similar to the setup in the gzll_ack_payload example.
  • timeslot period = 600 us
  • packet and ACK payloads are 32 B each

Results:

• On the device with the host powered off, heartbeat_counter hovers around 1433
• On the device with the host powered on, heartbeat_counter hovers around 2430
• On the host with the device powered off, heartbeat_counter is consistently 1666
• On the host with the device powered on, heartbeat_counter hovers around 2450 but sometimes drops down to around 1666

Based on the Gazell Link Layer User Guide, I expected the hearbeat_counter to be closer to 1666 (1 s / 600 us) during regular operation when the host and device are communicating. The number of heartbeats I'm seeing correspond with a timeslot period closer to 400 us. Can you shed any light on why this might be?

Thanks,

Kevin

Edit: One non-default setting I have enabled on Gazell is NRF_GZLL_DEVICE_CHANNEL_SELECTION_POLICY_USE_CURRENT.

Edit: I set it up so that the device and host each toggle a GPIO when their Timer2 Compare0 event is triggered. I'm surprised to see that the output is not a symmetric square wave with consistent periods.

And the number of Timer2 Compare0 events on the host changes every now and then for reasons unknown to me.

[Kenneth]

I expect there may be some adjustment to the timer on the device, when the device is out of sync and when a packet is transmitted/received, however I do not understand why this should impact the rx period on the host. How frequently are you transmitting from the device to the host here? For instance if you transmit every 10ms does that affect what you observe?

Have you considered using ESB instead, and make a simple frequency hopping using ESB?

[MorelNexus]

In my previous post, data was being transmitted as quickly as possible (device sends a packet about every 1.2 ms).

With data transmitting from the device every 10 ms, there is still in increase in the number of heartbeats on the host but it is a smaller increase. With the device off there are consistently 1666 Timer2 Compare0 events per second on the host. With the device on number of Timer2 Compare0 events fluctuates around 1690-1750.

I have been looking into ESB as well. I'm still not sure which is best for my application. ESB is interesting to me due to the increased packet payload size, however I like the pairing and encryption features provided with Gazell. Is there something in ESB that would facilitate clock synchronization?

[Kenneth]

I don't think Gazell will be able to do what you want here. The Gazell is built on top of ESB, using ESB you will have full control of when you actually transmit and receive packet, so when you transmit a packet you will always have a fixed offset from start of transmission on the device to packet is received on the host, a tolerance of a few ~us, and should be able to sync based on that. Maybe you can consider using Gazell to establish initial connection, and then exchange parameters to use with ESB, and then use ESB for synchronization.

Best regards,
Kenneth