Why are timeslots only called after ble advertising events?

[syntroniks]

I have an application that advertises as connectable in BLE.

After connection and configuration, it should then disable connectable advertising and enable nonconnectable advertising using the timeslot api.

My advertising intervals are 150ms for fast, and 700ms for slow. The timeslot nonconnectable advertisements should have a period of 300ms.

After the connection has been terminated, ble connectable advertising starts as it always does, but once ble_advertising falls back to the 700ms interval, the timeslot api does not respect my 300ms in m_beacon.timeslot_request.params.normal.distance_us = 300000;

During fast advertising, everything works well but ideally I would call sd_ble_gap_adv_stop(). Unfortunately that stops all of my timeslot advertisements too. No, I do not have sleep_mode_enter anywhere in my code.

What is the suggested workaround?

[Hung Bui]

Hi, When you mentioned "does not respect my 300ms" what was the actual distance/interval you got ? Do you have the timeslot blocked or cancelled ? You can try to toggle a GPIO pin when the time slot started and use logic analyzer to check what is the actual interval. You can also use radio notification to detect when the stack's advertising happens.

I assume you have 2 issue, one with the timeslot distance, and second with the sd_ble_gap_adv_stop() ? It's pretty strange that the timeslot advertisement also stopped. Have you checked it was because the timeslot was never given or because it couldn't send the radio packet when in the timeslot ?

[syntroniks]

@Hung Thank you for your suggestions

As I laid my head to rest last night, I was practicing my alternative to sheep-counting: thinking about nrf51822 firmware.

I had hastily implemented a method of limiting the advertising channels by moving ADV_DONE to be after ADV_RX_CH37. This must have had some side effect on the radio configuration state. By restoring the default order, my problem was solved.

Now I have to reach back to my CC1110 days of radio configuration to do things the proper way. My issue has been fully resolved.

P.S. If you could lend me a hint about the effect of NRF_TIMER0->CC[0] = 400; It could save myself and hopefully someone else some time. I wonder why it is not included in the ADV_RX_CH37 case in m_handle_radio_disabled...

[Hung Bui]

I'm glad that you have fixed the issue. Could you let me know which example you were testing with ?