Is it possible to bypass service discovery in S120 if UUIDs and characteristics of peripheral are known?

[boz]

Hi, I am using the S120 stack and wish to connect and control as quickly as possible to the peripheral. The central and peripheral devices are both embedded devices and are dedicated to each other for eternity. I only have control of the central source code. I have reduced the BLE_GAP_CP_MIN_CONN_INTVL_MAX to 30 msec. and it currently it takes about 1.5 seconds (that appears to be mostly discovery time) to accomplish this using the "ble central multilink" example. Is there way to shorten this time by bypassing the service discovery and just reading/writing the known characteristics directly? I don't think bonding is implemented/occuring but cannot be sure. It is not required. Thanks. Update: I have since learned that bonding will eliminate the need for service discovery, however, I do not think the peripheral I am connecting with is capable of bonding. I am not able to bond with it using the Master Control Panel.

[Petter Myhre]

Please have a look at this question.

[boz]

Referring to :"To skip this step you need to store these (persistently or not) on the first connection and then give them to ble_hrs_c and ble_bas_c on subsequent connections." I can initialize ble_hrs_c and ble_bas_c on boot with the uuids and handles required; however, this still does not prevent the central/server discovery from running. I must be missing a step to prevent this. The comment by Carles to avoid this by setting "en_param.gatts_enable_params.service_changed = 0" is specific to the peripheral/client. Thanks much.

[boz]

Update: I can read/write the characteristics directly by not calling ble_db_discovery_on_ble_evt() from client_handling_ble_evt_handler() after connect, but the central/server is disconnecting prematurely. When using the ble_db_discovery_on_ble_evt() as intended it waits for disconnect from the peripheral/client normally (BLE_GAP_EVT_DISCONNECTED).

[Hung Bui]

Hi Boz,

Could you check the disconnected reason when BLE_GAP_EVT_DISCONNECTED occurs ? You can find the reason inside p_ble_evt->gap_evt->disconnected->reason.

You can also try to do a sniffer trace and upload it here (in your question) so that we can find what happens over the air.

When the central disconnected would it continue to scan or just hang ?

[boz]

Thank you for suggesting the sniffer Hung. Using it I was quickly able to find the problem -- my coding :/ The solution turned out to be quite simple. Using the battery service as an example:

1. Init the Battery Service Client module with known handles rather than the default INVALID handles in ble_bas_c_init( )

2. After connection do not call ble_db_discovery_on_ble_evt( ) in client_handling_ble_evt_handler( ) but call your own function to tell the event handler that discovery is complete:

   void set_bas_discovery(ble_db_discovery_t * const p_db_discovery) { ble_bas_c_evt_t evt; evt.evt_type = BLE_BAS_C_EVT_DISCOVERY_COMPLETE; mp_ble_bas_c->evt_handler(mp_ble_bas_c, &evt); }

3. Next time bas_c_evt_handler() is called, case BLE_BAS_C_EVT_DISCOVERY_COMPLETE is now true so you can call ble_bas_c_bl_read() instantly.

4. Same idea for all known handles.

Note: You must reinit the Client Modules after waking up as they will hold the last values used before sleeping.

Worked for me...

Thanks again to Nordic for all the help!