cancel
Showing results for 
Search instead for 
Did you mean: 

WICED Smart Bluetooth

Anonymous
Not applicable

I think that the interval is a default value and it's not defined in the BLE profile configuration so i didn't find the variable to change the default value

0 Likes
1 Solution
ArvindS_76
Employee

This is not the function you are looking for. The connection interval is (to some extent) controlled by the slave sending a request to grant the connection interval it desires using bleprofile_SendConnParamUpdateReq(). The first parameter is the min interval and the second is the max interval (both in BT frames, each frame = 1.25mS). The master (generally) grants min or max or something inbetween.

Every time the master and slave sync up to each other is called a connection event. blecm_connectionEventNotifiationEnable() sets up a callback that will be invoked a few mS before the every connection event. For example, if your connection interval is 20mS and you enable connection event notification (through the callback) 5mS before connection event, then at t=15mS, your callback will be invoked, t=20mS the master and slave will exchange a packet, t=35mS your callback will be invoked, t=40mS the master and slave will exchange a packet... and so on forever.

The connection event notification will always track the connection events even if it is changed. This will allow the app to collect, process and enqueue the data just-in-time for the transmit (which will save power because you don't need to wake between connection events).

View solution in original post

5 Replies
Anonymous
Not applicable

yes that's close to my problem but the solution proposed doesn't work !! it's not the adv intervall that's responsble of the number of sending sensors 😕

0 Likes
BoonT_56
Employee

Is this what you are looking for in wiced_sense.c?

// Register for notifications from the baseband of upcoming TX opportunities.

  // wiced_sense_tx_opportunity_notice - the callback to be invoked

  // No context needs to be supplied back

  // notifications needed 6.25ms before the TX opportunity (so we have enough time to poll sensors

  //         and enqueue the notification)  = 6250uS / 625uS in BT slots

  // if not connected, notify every 30ms = 30000us/625 in BT slots (will not be used because we enable notis only when connected).

  // wiced_sense_connection_handle - the connection handle of the connection for which we need the notis.

  blecm_connectionEventNotifiationEnable((void (*)(void*, UINT32))wiced_sense_tx_opportunity_notice, 0, 6250/625, 30000/625, wiced_sense_connection_handle);

Anonymous
Not applicable

yes it is, but i don't find the link between these values and the occurrence of tx opportunities every second(33 times in a second) .

Adding to that when i changed the relation between 6250 and 625 (6250/625=10) by multiplying (6250*2)/625 the android application disconnect quickly , so the ultimate solution that i found: moving the treatment of the code from the function tx opportunities to the fintimeout function to manipulate the interval of sending data but there's the same problem, by changing this interval the android application disconnect quickly 😕 ( after 20 or 30 seconds)

and i don't understand why 😕

0 Likes
ArvindS_76
Employee

This is not the function you are looking for. The connection interval is (to some extent) controlled by the slave sending a request to grant the connection interval it desires using bleprofile_SendConnParamUpdateReq(). The first parameter is the min interval and the second is the max interval (both in BT frames, each frame = 1.25mS). The master (generally) grants min or max or something inbetween.

Every time the master and slave sync up to each other is called a connection event. blecm_connectionEventNotifiationEnable() sets up a callback that will be invoked a few mS before the every connection event. For example, if your connection interval is 20mS and you enable connection event notification (through the callback) 5mS before connection event, then at t=15mS, your callback will be invoked, t=20mS the master and slave will exchange a packet, t=35mS your callback will be invoked, t=40mS the master and slave will exchange a packet... and so on forever.

The connection event notification will always track the connection events even if it is changed. This will allow the app to collect, process and enqueue the data just-in-time for the transmit (which will save power because you don't need to wake between connection events).

View solution in original post