MPSL radio notification API: why dropped?

[rgrr2]

Hello,

is there any technical reason why the MPSL radio notification API has been dropped somewhere before NCS 2.6?

Our application needs information about radio notifications as in the old "nRF SDK", because we have to collect radio on times for modelling power consumption and also to put the main application to sleep during radio on.

So how to do it without the dropped API?  Any Zephyr API I missed?

Thanks & regards

Hardy

PS: I know this "connection event trigger" sample, but this unfortunately does not offer enough functionality

[Einar Thorsrud]

Hi,

The radio notification feature in MPSL was not much used and there were some techinical reasons to remove it (related to internals in MPSL). Threfore it was dropped in 2.6.

As you write, connectino event trigger is provided as an alternative, but it is not exactly equivalent, and does not cover all use cases. To get notification of all radio activity you can hook up to radio events using PPI and the EGU, as described in this post. This will not give you warning in advance like you got with the old radio notifications, though.

[rgrr2]

Ok... thanks.

So the rough sketch is to route some radio events onto an EGU, right?  Which are the actual events to use?

Another point: how do you find out, if a feature is being used or not?  Because I doubt, that the notification feature had been used rarely, for us e.g. this was an important feature of the old SDK.

[Einar Thorsrud]

Hi,

We don't have exact data on how much specific features are used, but we know what topics are discussed with sales and support. That said, we know that radio notification was used and we are workgin on providing alternatives (starting with the connection event trigger in 2.6). 

Regardign events, I suggest you look at EVENTS_READY which you will get every time the radio is ready to start an Rx or Tx operation, and EVENTS_DISABLED which you get when the radio has been disabled.

[rgrr2]

Thanks for the suggestion.  I will check this next week (long weekend yet) and post results.

[rgrr2]

Ok... this seems to work better for my use case.  Init code is as follows:

void RadioMeasurementInit()
/**
 * Initialize radio timing measurements
 */
{
    int err;
    uint32_t start_evt;
    uint32_t stop_evt;
    uint8_t start_ch;
    uint8_t stop_ch;

    k_timer_init(&slotend_tmr, slotend_cb, NULL);

    start_evt = nrf_radio_event_address_get(NRF_RADIO, NRF_RADIO_EVENT_READY);
    stop_evt  = nrf_radio_event_address_get(NRF_RADIO, NRF_RADIO_EVENT_DISABLED);

    err = ppi_alloc(&start_ch, start_evt);
    NRFX_ASSERT(err == NRFX_SUCCESS);
    err = ppi_alloc(&stop_ch, stop_evt);
    NRFX_ASSERT(err == NRFX_SUCCESS);

#if defined(__ZEPHYR__)
    IRQ_CONNECT(NRFX_IRQ_NUMBER_GET(NRF_EGU_INST_GET(EGU_INST_IDX)), IRQ_PRIO_LOWEST,
                NRFX_EGU_INST_HANDLER_GET(EGU_INST_IDX), 0, 0);
#endif

    nrfx_egu_t egu_inst = NRFX_EGU_INSTANCE(EGU_INST_IDX);
    err = nrfx_egu_init(&egu_inst, NRFX_EGU_DEFAULT_CONFIG_IRQ_PRIORITY, egu_handler, nullptr);
    NRFX_ASSERT(err == NRFX_SUCCESS);

    const uint32_t channels_to_trigger = (1 << TASK_RADIO_START) | (1 << TASK_RADIO_STOP);
    nrfx_egu_int_enable(&egu_inst, channels_to_trigger);

    ppi_assign(start_ch, start_evt, nrfx_egu_task_address_get(&egu_inst, NRF_EGU_TASK_TRIGGER0));
    ppi_assign(stop_ch,  stop_evt,  nrfx_egu_task_address_get(&egu_inst, NRF_EGU_TASK_TRIGGER1));

    ppi_enable( (1 << start_ch) | (1 << stop_ch) );
}   // RadioMeasurementInit

But per connection event there are now a lot of equ_handler() calls, also the handler has to find out which of the events are advertisements or data.  So still some work to do ;-)

Currently the configuration also relies on EGU0.  Any suggestion how to do this nicer with devicetree?

[Einar Thorsrud]

Hi,

This looks very sensible.

If you want to, you could describe the EGU instance in the device tree and parse the devicetree in the code that sets the EGU instance here using something like DEVICE_DT_GET(DT_NODELABEL((my_egu)), but I don't think you can do much more from the devicetree in this case.