SDK 17.1.0: is the "Need to close the ANT channel to make it safe to write to flash" warning still valid?

Hello,

I'm writing an application that sends cycling power information via ANT+ and Bluetooth (S340, on a nRF82840). While the ANT+ is a pure cycling power service, the device exposes multiple Bluetooth services. In many cases, the cyclocomputer will receive ANT+ data, while the user changes settings on the device using BLE services. So the BLE will  be connected and disconnected while ANT+ is transmitting. Pretty much everything is working as expected.

In the multiprotocol example, there is the following warning

// Need to close the ANT channel to make it safe to write bonding information to flash
err_code = sd_ant_channel_close(ANT_HRMRX_ANT_CHANNEL);
APP_ERROR_CHECK(err_code);

First of all, is that warning still valid for SDK17.1.0? I found conflicting information searching here.

Assuming that the warning is still valid, I'm not entirely sure I understand how the code works. When debugging, it looks as if the system calls the following event handler

void ant_evt_handler(ant_evt_t * p_ant_evt, void * p_context)
{
    if (p_ant_evt->event != EVENT_CHANNEL_CLOSED)
    {
        return;
    }
    if (m_conn_handle != BLE_CONN_HANDLE_INVALID)
    {
        ant_hrm_rx_start();
    }
    else
    {
        ant_and_adv_start();
    }
}

[...]

/**@brief Start receiving the ANT HRM data.
 */
static void ant_hrm_rx_start(void)
{
    uint32_t err_code = ant_hrm_disp_open(&m_ant_hrm);
    APP_ERROR_CHECK(err_code);
}


/**@brief Attempt to both open the ant channel and start ble advertising.
*/
static void ant_and_adv_start(void)
{
    advertising_start();
    ant_hrm_rx_start();
}

Which if the channel is closed, immediately reopens it: ant_and_adv_start() calls ant_hrm_rx_start() after starting the BLE advertising, which I do in a separate part of the code.

What is the reason why the ANT+ channel is closed and immediately reopened? 

Parents
  • First of all, is that warning still valid for SDK17.1.0? I found conflicting information searching here.

    I indeed believe so, I can find this comment all the way back to before we did support executing flash operations while in a connection. So please disregard this comment. This also make the other code you refer to make sense I think; it should advertise on disconnected.

    Kenneth

  • Thanks for the super-fast reply. Just one clarification, please. 

    If there's no need anymore to stop the ANT channel on BLE disconnect, then I would simply remove the sd_ant_channel_close() call and ant_evt_handler(). In my application, it's actually required that the ANT channel be always active. Say, for example, that the user is monitoring the cycling power via a ANT+ cyclocomputer while changing settings using BLE (which is supported in our case). At he end of the BLE connection, there should be no interruption to the ANT+ packets.

    Granted, a sd_ant_channel_close(0 followed immediately by ant_hrm_disp_open() (my equivalent in this case) will at worst result in one lost packet, hardly noticeable. But it's better to avoid unnecessary ANT channel disturbances

    I would also suggest to remove that comment/code from future SDK examples. I would simplify the logic and make the example easier to understand

Reply
  • Thanks for the super-fast reply. Just one clarification, please. 

    If there's no need anymore to stop the ANT channel on BLE disconnect, then I would simply remove the sd_ant_channel_close() call and ant_evt_handler(). In my application, it's actually required that the ANT channel be always active. Say, for example, that the user is monitoring the cycling power via a ANT+ cyclocomputer while changing settings using BLE (which is supported in our case). At he end of the BLE connection, there should be no interruption to the ANT+ packets.

    Granted, a sd_ant_channel_close(0 followed immediately by ant_hrm_disp_open() (my equivalent in this case) will at worst result in one lost packet, hardly noticeable. But it's better to avoid unnecessary ANT channel disturbances

    I would also suggest to remove that comment/code from future SDK examples. I would simplify the logic and make the example easier to understand

Children
Related