Configuring connection interval (WICED SDK 2.2.2 and BCM20736S)

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
lock attach
Attachments are accessible only for community members.
Anonymous
Not applicable

We are using WICED SDK 2.2.2 and BCM20736S. We got struck while configuring connection interval.

We followed steps given in the attached document ("EMRF-BCM20732S-BOB-UserManual.pdf") and the connection interval is configured as follows,

    /*.high_undirect_adv_interval     =*/ 32,   // slots

    /*.low_undirect_adv_interval      =*/ 338, // slots

    /*.high_undirect_adv_duration     =*/ 30,   // seconds

    /*.low_undirect_adv_duration      =*/ 300,  // seconds

And, initialising the structure "BLE_PROFILE_CFG" using "bleprofile_Init(bleprofile_p_cfg)"

As per the document, the device is expected to advertise with a high interval of 20ms. Unfortunately, we are not getting this rather we are getting one advertisement per one second after booting up the board.

Also attaching the sniffer screenshot and the ble_ttl.c file.

Please, help us in resolving this issue

0 Likes
1 Solution
BoonT_56
Employee
Employee
500 likes received 250 likes received 100 likes received

I noticed from your code that the below line was greyed out in the app_create function.

bleprofile_Discoverable(HIGH_UNDIRECTED_DISCOVERABLE, NULL);

Can you insert this line right after your bleprofile_StartTimer()?

The lowest resolution for fine-timer is 12.5ms and I noticed that you have set it to 12ms. Can you

set it back to 12.5ms or 50ms?

View solution in original post

9 Replies
BoonT_56
Employee
Employee
500 likes received 250 likes received 100 likes received

I noticed from your code that the below line was greyed out in the app_create function.

bleprofile_Discoverable(HIGH_UNDIRECTED_DISCOVERABLE, NULL);

Can you insert this line right after your bleprofile_StartTimer()?

The lowest resolution for fine-timer is 12.5ms and I noticed that you have set it to 12ms. Can you

set it back to 12.5ms or 50ms?

lock attach
Attachments are accessible only for community members.
Anonymous
Not applicable

Hi, Thank you for the response,

>> I noticed from your code that the below line was greyed out in the app_create function.

Yes, this was done intentionally. As per our requirement, we have to wait for data received via UART to set the advertisement data. So, we are not starting the advertisement in app_create function and this is done in another file (attached with the reply).

Please let us know if there is any change to be done.

>> "Can you insert this line right after your bleprofile_StartTimer()?"

Our understanding was that bleprofile_StartTimer() is to start the fine timer, is this correct? Does this has any direct relation with advertisement time interval?

Sure, we will change the resolution to 12.5 ms as you suggested.

0 Likes

Can I suggest that you carved out a dedicated advertisement function just for that purpose? After you get your UART data, register a callback to it for advertisement. Probably something like the below:

void start_advertisement(void) {

blecm_setTxPowerInADV(4); // Set TX power

BLE_ADV_FIELD adv[3];

BLE_ADV_FIELD scr[2];

// flags

adv[0].len     = 1 + 1;

adv[0].val     = ADV_FLAGS;

adv[0].data[0] = LE_LIMITED_DISCOVERABLE | BR_EDR_NOT_SUPPORTED;

// Service UUID

adv[1].len     = SERVICE_UUID_LEN + 1;

adv[1].val     = ADV_SERVICE_UUID128_COMP;

memcpy(adv[1].data, &ttl_ble_uuid_main_vsc_service[0], SERVICE_UUID_LEN);

// Tx power level

adv[2].len     = TX_POWER_LEN+1;

adv[2].val     = ADV_TX_POWER_LEVEL;

adv[2].data[0] = bleprofile_p_cfg->tx_power_level;

// name

scr[0].len      = strlen(bleprofile_p_cfg->local_name) + 1;

scr[0].val      = ADV_LOCAL_NAME_COMP;

memcpy(scr[0].data, bleprofile_p_cfg->local_name, scr[0].len - 1);

// L4 UID

scr[1].len     = STM_UID_DATA_LEN + 1;

scr[1].val     = ADV_MANUFACTURER_DATA;

memcpy(scr[1].data, &bleprofile_p_cfg->UID_Adv[0], 16);

for(inde = 0; inde < 16; inde++){

ble_trace1("new_uid1---> %x \r\n",bleprofile_p_cfg->UID_Adv[inde]);

}

bleprofile_GenerateADVData(adv, 3);

bleprofile_GenerateScanRspData(scr, 2);

bleprofile_Discoverable(HIGH_UNDIRECTED_DISCOVERABLE, NULL);

}

I am refering to the hello_sensor app as a starting point. It is both connectable and discoverable like yours.

Anonymous
Not applicable

>>Can I suggest that you carved out a dedicated advertisement function just for that purpose?

In our case the advertising data is not static and it can be updated anytime in our implementation.

In "bt_uart_protocol.c" file we already using function called  "btup_receiveDataCallback", which is an UART receive callback.

Here we can't decide what is the packet until we receive complete packets (multi packets) from UART buffer and decode it.

Then based on header of received UART data, we start advertising.

Our worry is that If we add another callback inside this function, it may lead to some byte loss.

At the start of the board, BCM receives data packets(5 packets) from UART and acknowledges each packet. This packets are decoded then only starts the actual advertisement.

Is this right approach for advertisement? Do you think we are somehow doing it in a wrong way?

0 Likes

I quote the below API from mybeacon to illustrate the ability for a callback (advertisement_packet_transmission) to be

called at 2.5ms before advertisement so as to modify the advertisement data.

// register with LE stack to be called 2.5msec before the advertisement event

    bleprofile_notifyAdvPacketTransmissions(&advertisement_packet_transmission, 2500);

You may consider to use this if you have to sort of advertise on demand.

There is nothing inappropriate in your above approach. As you have initialized the ble_profile_config, bleprofile_Discoverable() is

the only API you need to start advertisement.

Can you insert trace where appropriate that bleprofile_Discoverable() has indeed been exerted after decoding your UART data header?

I am of the opinion to "prepare" the advertisement data prior to sending them. One may create a function just for that like:

void createADVdata () {

//Flags

//Service UUID

//name

//L4UID

bleprofile_GenerateADVData(adv, 3);

bleprofile_GenerateScanRspData(scr, 2);

}

Then in ttl_ble_create(), call the above, then follow by bleprofile_Discoverable().

In your advertisement (per second), did you nevertheless get the correct broadcasted data?

Anonymous
Not applicable

We are receiving UART data asynchronously from the other end, so we feel triggering a callback is not required.

Once we receive the data for advertisement from UART, we trigger the start of advertisement with in that condition block.

We also inserted some trace after bleprofile_Discoverable() as you suggested and yes, we are able to get trace.

As a response to the second reply:

"I am of the opinion to "prepare" the advertisement data prior to sending them. One may create a function just for that like...."

As per the requirement we have, we are strictly not allowed to advertise before receiving the data from UART.

Currently, we are able to advertise, connect to the BCM, and get the advertisement data using an iPhone app. Our configuration is High advertisng interval 30slots(20ms) and setup is BCM20736s & wiced SDK 2.2. But, still as per the sniffer screenshot I attached in above comments, we are not able to achieve the 20 ms advertising interval, which is the suggested advertisement interval by Apple for ensuring smooth connection with its devices (iPhone, iPad).

As I said, currently connection is happening and communication also is working. Sometimes the connection takes too long to establish between iPhone and BCM, we feel that this could be because of the actual advertisement interval of 1 sec, which is not satisfying Apple's recommendation.

Do you find anything wrong with our configuration?

Would you please take a closer look in that area and suggest some changes or improvements?

0 Likes

First of all, I only confined myself to the app_create and ttl_ble_puart_init() functions. I also do not have the header

files and so a lot of these are recommendations only.

Just for the sake of testing the advertising, can you turn on line 367 through 412?

i) remove "#if 0"

ii) define SERVICE_UUID_LEN to be 16

These are standard advertisement flags and will at least verify if indeed it is advertising properly.

Btw, why do you have "ws_upgrade_ota_init();" before calling advertisement?

In ttl_ble_puart_init(), you may want to disable sleep by exerting the below as you are not using flow control:

devlpm_registerForLowPowerQueries(uart_device_lpm_queriable, 0);

Can you also try loading hello_sensor on your board and observe what's the adv interval?