This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Bypass or skip the discovery service nRF52 SDK 12.2

Hi all,

I am trying to reduce the connection time between each connection to the minimal posible

Connect -->Transfer data -- Disconnect

I am facing two options:

  1. On the BLE_GAP_EVT_CONNECTED event avoid to call ble_db_discovery_start(), but it require in some way set BLE_LBS_C_EVT_DISCOVERY_COMPLETE with a valid event and how to assing the conn_handle to static handles on the GATT server

  2. From the BLE_GAP_EVT_CONNECTED event Set handles and enable a Notificiation to the peripheral.

Which is the most viable option? or Are there some example doing something similar?

Thanks

Parents
  • Hi,

    No problem with issuing (G)ATT Write once you know 16-bit handle number, here is paraphrase of nRF5 SDK v12.2.0 example:

    //...
    
    uint32_t                 err_code;
    ble_gattc_write_params_t write_params;
    uint8_t                  your_data_buffer[YOUR_DATA_MAX_LEN];
    
    //...
    your_data_buffer[0] = 0x41;
    your_data_buffer[1] = 0x42;
    //...
    
    write_params.write_op = BLE_GATT_OP_WRITE_REQ;
    write_params.handle   = your_write_handle_number;
    write_params.offset   = 0;
    write_params.len      = sizeof(your_data_buffer);
    write_params.p_value  = your_data_buffer;
    
    err_code = sd_ble_gattc_write(my_connection_handle, &write_params);
    APP_ERROR_CHECK(err_code);
    

    If you need GATT Client Service Discovery example (oriented to find specific UUID not all of them and so you can use much shorter algorithm to crawl through GATT handle tree) here are some hints.

Reply
  • Hi,

    No problem with issuing (G)ATT Write once you know 16-bit handle number, here is paraphrase of nRF5 SDK v12.2.0 example:

    //...
    
    uint32_t                 err_code;
    ble_gattc_write_params_t write_params;
    uint8_t                  your_data_buffer[YOUR_DATA_MAX_LEN];
    
    //...
    your_data_buffer[0] = 0x41;
    your_data_buffer[1] = 0x42;
    //...
    
    write_params.write_op = BLE_GATT_OP_WRITE_REQ;
    write_params.handle   = your_write_handle_number;
    write_params.offset   = 0;
    write_params.len      = sizeof(your_data_buffer);
    write_params.p_value  = your_data_buffer;
    
    err_code = sd_ble_gattc_write(my_connection_handle, &write_params);
    APP_ERROR_CHECK(err_code);
    

    If you need GATT Client Service Discovery example (oriented to find specific UUID not all of them and so you can use much shorter algorithm to crawl through GATT handle tree) here are some hints.

Children
  • awesome thanks :) that code should I put inside the my Connected event? and what are the differences between your_write_handle_number and my_connection_handle?

    I know my handle for example: 0x0010 for a writeable characteristic on the peripheral. Is it the same value than your_write_handle_number? and what is my_connection_handle value sorry I am a little confused

    regards

  • Well looking to ble_gattc.h it seems to be easy:

    /* @param[in] conn_handle The connection handle identifying the connection to perform this procedure on. */
    

    and

    uint16_t       handle;               /**< Handle to the attribute to be written. */
    

    So my_connection_handle is what you get from Soft Device on BLE_GAP_EVT_CONNECTED event from (ble_evt_t *)->evt.gap_evt.conn_handle structure and your_write_handle_number is the GATT handle number in 0x0001 - 0xFFFF space you get from Service Discovery or elsewhere (e.g. hardcoded if you are 100% sure that your GATT Server will never change).

  • I am going to test it thanks again :) when you say GATT server will never change you mean if am I going to add/remove more attributes/services? if it is the case the answer is not. I think I am going to keep the current I am using

  • Hi endnode you rock men :]

    It is working pretty awesome

    I use 0x0000 for the conn_handle because my requeriment are one device per time. The only concern I have about this method is it still BLE compliant doing it? and some times I am getting 2 times the same ATT_WRITE_COMMAND to the peripheral: ACK OK, ACK Retry, Unexp. NESN, Unexp. SN from my peripheral to central?? when the central is sending the payload to the peripheral

  • I don't see any violation of BT SIG Core specification here, also you use Soft Device API and it's main purpose of BLE stack implementation by Nordic to be compliant;) I don't understand the second part of your question, you will need to elaborate...

Related