nrf51422 ANT interrupts and WS2812b

[bradm6]

I am having an issue implementing a WS2812b driver for the nrf51422 using the 210 softdevice. We currently have ANT enabled with a tx master only channel setup. The WS2812b driver uses bit-banging to transmit the bit pattern to a strand of LEDs. Due to the nature of the one wire WS2812b protocol, this bit banging has very sensitive timing tolerances. By adding this bit pattern transmission to the tx event handler (ran in main context off of ant_event_process), the bit stream is interrupted mid-transmission by an ISR exceeding 50us causing the bit stream to be corrupted.

Doing some digging it seems that this issue only occurs with ant enabled and a channel opened. By disabling ANT and putting the LED code on a separate, periodic signal, the issue goes away. It appears that there is an ANT related interrupt that causes the bit transmission to be corrupted. If I add a delay in my driver code the LED pattern is not corrupted as the interrupt occurs during the delay. That being said, the delay is not ideal as it holds up all main context events.

Does anyone have an idea of what is causing this issue? What is it about ANT that I get this periodic interrupt (following the tx event) that holds up the processor for more than 50 us? If anyone has suggestions on how to get around this issue I would greatly appreciate it.

Cheers,

Braden

[Kenneth]

You can find in the S210 softdevice specification the interrupt latency the softdevice will introduce during an ANT protocol event, see chapter 11: www.nordicsemi.com/.../51629523

Note: To find which S210 softdevice specification document that apply to your S210 release, you should check the nRF51 Series Compatibility Matrix first.

If you are using a master channel, you can find in the ANT power profiles in chapter 12 that a transmit is always followed by a receive period. This receive period is used for possible bi-directional data from the slave, the event might extend further if for instance the slave is sending a burst-transmission or ask for an acknowledge of data. The receive period is also used for adaptive transmission, to allow many ANT devices to communicate concurrently without interference from one another.

The only way to be sure that the ANT event is complete is to use radio notification as described in chapter 7. You can then start bit-banging after nACTIVE signal with no interrupts until next ANT event.

You might include the ble_radio_notification module in the SDK to enable radio notifications.

#include "ble_radio_notification.h"

ble_radio_notification_init(APP_IRQ_PRIORITY_LOW,
NRF_RADIO_NOTIFICATION_DISTANCE_800US,
ble_radio_notification_evt_handler);

Callback:

static bool m_radio_active;
void ble_radio_notification_evt_handler(bool radio_active)
{
    m_radio_active = radio_active;
}

Then you simply need to wait for !m_radio_active.

[bradm6]

Awesome. I tried your suggestion and with a few modifications it worked. That being said I had to call my led bit banging function inside the radio notification event handler else the bit stream would get corrupted. I hypothesize that decoupling the bit banging from the radio notification event handler results in scenarios where the bit banging starts when the radio is inactive but changes to active a short while later. We are using ANT with a very small period which likely causes issues on the bit banging (which occurs at a different frequency).

All in all it appears to be stable now. Thank you for all your help Kenneth!