This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Timeslot API: BLE + ESB, slower transmissions when no advertising or no connection

Good morning everyone,

I am facing an apparently common problem (reported with some variations HereHere or here ) which is driving me crazy. In the linked discussions no working solution was given, so this is

why I open a new topic.

In my application, I have a NRF52832 development kit which should receive periodic packets from a custom board (later there will be n custom board, n = 5 more or less).

The DK is programmed with the ESB protocol in PRX mode, while the custom boards are programmed with the S132 and the timeslot API with ESB protocol in PTX mode.

Once a second, the custom board should transmit a message to the DK using the timeslot API (thus, the ESB protocol).

The problem I have is that when the custom board is advertising OR connected to a smartphone, all works perfectly fine: I receive all the data both on the smartphone and the DK with

the expected timings. When the custom board is disconnected AND/OR not advertising, then I receive on the DK only 1 packet every 10 seconds. For the record, I am on SDK 15.0.0.

If I do not start advertising, all my code (I have some periodical sensors sampling) runs perfectly fine and all the timings are well respected. The only issue is with the ESB transmissions, 

which are performed only once every 10 seconds.

From the look of it, it seems a configuration problem somewhere, but I was not able to find until now a solution. 

Can someone help me with this?

Thanks a lot!

Lorenzo

  • No, I don't get the EXTEND_FAILED case.....Just as before, all the code seems to run correctly, but the event NRF_RADIO_CALLBACK_SIGNAL_TYPE_START does not seem to be signaled regularly if the advertising is inactive.....I tried to modify the code to use normal timeslots instead of earliest, but things got worse....only a first timeslot is allocated, then I don't get any transmission, not even once every 10 seconds.

    I tried to update the softdevice to the latest available version, but this did not make any difference.

    As for your reply, I was wrong....the END_IRQHandler is in fact called only when there was a previous SIGNAL_TYPE_START event....my mistake.

  • You'll need to add some debug signals to your timeslot handling to find out why you're not getting the slot extended. Do you have several GPIOs available, so that you can toggle these in each of the respective events? Also check your nrf_evt_signal_handler(), to see if anything pops up there as well.

    Could you post more code regarding your handling of this in main?

     

    Kind regards,

    Håkon

  • Hi again,

    I don't have easy access to GPIOs. I checked the nrf_evt_signal_handler() in debug mode and it is never called, neither with advertising, nor without advertising.

    There is nothing more concerning the handling of this in the main.....the main only calls 

    err_code = esb_timeslot_send_buffer(to_send, 19, hw_addr);

    in a timer callback once a second. 

    All the other code related to timeslot management is the one I posted above.

    Just a question: is it possible that if the advertising is not started at all, the soft device does not start the HF crystal and/or the radio? So that it cannot allocate any slot, because the needed hardware is not running? Maybe the no-advertising mode is a corner case......

  • lbe said:
    I don't have easy access to GPIOs. I checked the nrf_evt_signal_handler() in debug mode and it is never called, neither with advertising, nor without advertising.

    You need to call this from the system event handler from the SoftDevice, as described here (step 8): https://devzone.nordicsemi.com/nordic/short-range-guides/b/software-development-kit/posts/setting-up-the-timeslot-api

     

    Since you are using a newer SDK, you can do something like this to register a system observer (include nrf_sdh_soc.h as well):

    NRF_SDH_SOC_OBSERVER(m_timeslot_sys_obs, 0, nrf_evt_signal_handler, NULL);

     

    Kind regards,

    Håkon

Related