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

BLE high bandwidth bulk transfer from Client to Server

I am developing an application that will transmit a lot (say 100kB) of data from client (scanner) to server (advertiser). 

Using cccd, notification, and hvx works well for large data transfer from server to client, as illustrated in the ble_app_att_mtu_throughput example. However, that's the opposite direction from what I would like to do. 

What would be advised for bulk transfer from client to server?

  • In BLE the role of Client and Server are separate from the roles of Scanner/Master and Advertiser/Peripheral, in other words, a Peripheral can just as well be a client. See this where it is explained as well. So the mechanism used by the Peripheral to notify its Client in the example you mention can just as well be used by the Master. This means that the Peripheral discovers the service and relevant characteristic at the Master and registers for the notification.

  • Does that mean that the scanner should call sd_ble_gatts_service_add() to register a service UUID and that the advertiser, upon an BLE_GAP_EVT_CONNECTED event should initiate ble_db_discovery_start() to later get handles to the scanner's service characteristics when the callback to discovery handler occurs? 

  • I was able to get the suggested idea of having the scanner register a service, and the advertiser, upon BLE_GAP_EVT_CONNECTED event should initiate ble_db_discovery_start(), sort of working.

    However, it does not work if the advertiser stops advertising -- by calling sd_ble_gap_adv_stop() in the handler of the connected event. The discovery appears to complete only if the advertising is not stopped.

    1. Why is this?
    2. Is there an appropriate time to stop advertising?
    • Hi, I would think what you want to do is similar to an DFU update (where a mobile phone try to send a large amount of  data to update the firmware of the device). I suggest you look at that.

      Best regards,
      Kenneth

    Related