Advertising interval problem

[Hive777]

Hello, 

We are developing a BLE beacon with nRF52810 and SDK17.0.0.  I modified the code on the basis of ble_app_beacon. I rewrited m_advertising.adv_modes_config.ble_adv_fast_interval to change advertsing interval and through nRF connect for Android I find it worked. However, when I verified it by another scanner - a custom board based on nRF52832, I observed something wrong.

I used RTC1 to calculate elapsed time between two scanning.The relevant code is as follows:

uint32_t last_rtc1_ticks = 0;
uint32_t cur_rtc1_ticks = 0;
float ms_diff = 0;
uint8_t mac_addr[6];

void ble_evt_handler(ble_evt_t const * p_ble_evt, void * p_context)
{
    uint32_t err_code;
	ble_gap_evt_t const * p_gap_evt = &p_ble_evt->evt.gap_evt;
    switch (p_ble_evt->header.evt_id)
    {
        case BLE_GAP_EVT_ADV_REPORT:
        memcpy(mac_addr ,p_gap_evt->params.adv_report.peer_addr.addr, 6);
        
        if(accord_with_beacon_uuids(m_scan, m_beacon_uuids) && accord_with_specific_mac(mac_addr, test_mac))    
        {
            if(last_rtc1_ticks == 0)
            {
                last_rtc1_ticks = app_timer_cnt_get();
                return;
            }
            else
            {
                cur_rtc1_ticks = app_timer_cnt_get();
                ms_diff = ((float)cur_rtc1_ticks - last_rtc1_ticks)/32;
                last_rtc1_ticks = cur_rtc1_ticks;
            }
        }
        break;
        ....
    }
}

I debugged with it and the result is half of the setup, e.g., if I set the adv interval to 300ms, the ms_diff is usually about 150. Can you tell me what the problem is. Thanks in advance.

[Karl Ylvisaker]

Hello,

SDK17.0.0. 

We recommend upgrading to SDK v17.0.2 - this is fully compatible with v17.0.0, and contains some bug fixes.

I debugged with it and the result is half of the setup, e.g., if I set the adv interval to 300ms, the ms_diff is usually about 150. Can you tell me what the problem is. Thanks in advance.

While the thought and implementation here is alright, this will not produce accurate measurements of the time between advertisements and BLE events, since the SoftDevice controls the CPU for its timing-critical event handling your program will be delayed until the SoftDevice has finished its processing, every BLE event. This will therefore only accurately tell you how long has passed since the previous ADV report event was processed in your application.
To measure connection parameters and to see what is happening on-air, I highly recommend making use of the nRF Sniffer tool. It is a powerful tool to wield when developing for BLE, and lets you monitor the on-air BLE traffic, so you may see exactly what is being exchanged, and when.

Could you install the sniffer, create a sniffer device, and provide a sniffer trace of the communication that is happening when you see this issue?
This will make debugging a lot easier.

Best regards,
Karl

[Hive777]

Hello Karl,

Thanks for your reply and suggestions. I will consider using the new version of the SDK and sniffer tool. 

Karl Ylvisaker said:

since the SoftDevice controls the CPU for its timing-critical event handling your program will be delayed until the SoftDevice has finished its processing, every BLE event.

For my application, can I understand it this way - the RTC stops when  the SoftDevice controls the CPU for its event handling, so I got the wrong result?

Best regards,

Alan

[Karl Ylvisaker]

Hello Alan,

Hive777 said:

Thanks for your reply and suggestions. I will consider using the new version of the SDK and sniffer tool. 

No problem at all, I am happy to help!
The process of familiarizing with the sniffer tool might seem daunting, but I highly recommend it because it is such a powerful tool to wield. It makes debugging of BLE traffic a lot easier.

Hive777 said:

For my application, can I understand it this way - the RTC stops when  the SoftDevice controls the CPU for its event handling, so I got the wrong result?

No, this is not quite correct. The RTC it its own peripheral, so it will keep counting.
However, the SoftDevice will control the CPU, so your program / application will stop for this duration.
I.e, if you check the RTC tick difference between two consecutive lines in your code, you will sometimes find that the SoftDevice has used the CPU between the first and the second line, and so the program counter will have stopped on the first line for a longer time, for example.
Since your program is dependent on the CPU to proceed, it will have to wait every time the CPU is used by the SoftDevice.
Please do not hesitate to ask if any part of this still should be unclear! :) 

Best regards,
Karl

[Hive777]

Got it! Thanks a lot, Karl!

Best regards,

Alan