programatically change advertising rate

Dear Motred,

You're right when saying that both lines 209 & 210 in app.c must be changed in case you need to change the advertising interval.
所以你menti的函数oned is fine.
Note that current_app_adv_int_min & current_app_adv_int_max must be the same.

best regards,

Guillaume.

#define APP_ADV_INT_MIN 1100
#define APP_ADV_INT_MAX 1100
1100 means ?? unit??

Hi JE_Dialog

are yu sure ? because it is advertising interval so 1100*(1/100) = 11 seconds !! ?? or is it 1100 * 0.625 =687.s msec ? because while checking in power profiling the time between two advertising event is approx 680 msec !!

Hello hrg, yes, you are right : i was looking at our Beacon SW by mistake where we have a different calculation.

Line 81 and 83 in main.c apply a multiper of 0.625 so the 680mS is the correct value.

#define APP_ADV_INT_MIN 0x20 // *0.625ms (+ pseudo random advDelay from 0 to 10ms)

BR JE_Dialog

Hi,

Just adding to this. You will have to stop, then restart advertising to actually change the intervals.

Hi JE,

In #8, you mentioned the (BLE) stack will add random number(0~10ms) above APP_ADV_INT_MAX, while in our tests, we did not see this random adding to the interval:
- when we power up 3 DA modules(with same firmware) simutaneously, we could hardly scan all 3 modules(sometimes we can only scan 1, sometimes 2).
- while if we power up 3 DA modules one by one, we can scan all 3 modules everytime.
- if we burn firmware with different APP_ADV_INT_MAX value to each module, and power up the 3 modules simutaneously, we also can scan all 3 modules everytime.

Pls help to check and advise..

Thanks.
Alex

Hi alex,

According to the bluetooth spec the advertising events occurs at regular intervals which are slightly modified with a random delay to aid in interference avoidance. Even without this mechanism, over time the different advertising intervals should drift and stop overlapping eachother (no matter how simutaneously your advertising starts for how long the other devices aren't discoverable by your scanner). Do you use different bd-addresses ? What is your software version ?

Thanks MT_dialog

Thank you MT..

Do you use different bd-addresses ?
- Yes, we are having different BDA for each module.
What is your software version ?
- The firmware developed based on SDK304.

Alex.

Hi alex,

Can you please try to define the CFG_TRNG configuration, and check again if the advertising events overlaps ?

Thanks MT_dialog.

Hi Dialog
We have the same issue as #11, and we are using SDK 5.0.2.1

Info:
We are using "app_easy_gap_non_connectable_advertise_start_create_msg" which sets up cmd->intv_max and cmd->intv_min identically
cmd->intv_max = user_non_connectable_advertise_conf.intv;
cmd->intv_min = user_non_connectable_advertise_conf.intv;

True Random number Generator is enabled in "da1458x_config_advanced.h"
#define CFG_TRNG

Hope you have a solution, since this is a real issue for the application.

Best Regards,
Ciano Frost
Denmark

Hi ciano,

请确保下载的图片in the 580 has the CFG_TRNG defined, i tested your scenario with the SDK 5.0.2.1 in a modified template example advertising in non-connectable mode (different advertising strings, different bd_addresses and same advertising intervals ) and by connecting the two reset pins i issue a reset at the two boards at the same time. I can properly see the boards with a sniffer and with a normal android BLE app. The only way i could get one device and corrupted advertising data is when the CFG_TRNG is undefined. Please check the sniffer attachments when TRNG is defined and when its not.

Thanks MT_dialog

Hi ciano,

So you are advertising 1 advertising packet every 1 second and this is defined by an elapsed timer that issues an advertise start. That explains what you are experincing, the first advertising message hasn't a delay applied to it. After the app_adv_start is issued the advertising string is transmited in the same time as the other DUT after that the next advertising event is re-scheduled with a random delay, so in the first message you send there is a collision between the two advertising messages. A work around of what you are experiencing is to decrease the advertising interval so that the second advertising string is transmitted within the 1 second interval and the random delay to insert the advertising interval so that the two advertising string doesnt collide.

You can count the advertising string that you have emmited and stop the advertising in the second emmited advertising string (which will be received correctly), you can catch the completetion of the advertising and and start the timer, when tha timer elapses start advertising again.

Here is a small snippet on how you can count your advertising events:

enum arch_main_loop_callback_ret count_adv_events(void)
{
uint8_t temp_last_ble_event;
temp_last_ble_event = arch_last_rwble_evt_get();
if (app_last_ble_event != temp_last_ble_event)
{
app_last_ble_event = temp_last_ble_event;
if (app_last_ble_event == BLE_EVT_END)
adv_count++;
if (adv_count == 2)
{
adv_count=0;
app_easy_gap_advertise_stop();
}
}
return GOTO_SLEEP;
}

Thanks MT_dialog

Hi ciano,

The delay that is inserted in the advertising operation is located in the ROM code according to the BLE spec, you cant change that.

Thanks MT_dialog