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

BLE GATT questions and large transfer

I'm designing a BLE peripheral with a custom profile composed by Hearbeat, Device Information and Battery service plus a custom service for device operation parameters configuration and, somehow, create an attribute that is ~60KB which should be updated at a worst case scenario every 10 seconds. This device must be able to talk to all major mobile phone OS plus Windows/Linux (with or without default stack).

  1. What's the best option for the 60KB object transfer? I saw Object Transfer Profile (OTP) and "long write", does any of it solves the problem? It seems that OTP is not support by Nordic nor other BLE stacks (e.g. Android and iOS) and I'm not sure that is possible to use a long write for 60KB;
  2. If I'm using a custom profile will I still be recognized by applications that only use Heartbeat/Battery/Device Information service or usually they only look at profiles and not services? Meaning, does a fitness app will I look for Hearbeat service inside the device profile or I only look at the devices that implement Hearbeat Profile? My idea is that if the reader doesn't have support for my custom services it could use the ones that are standard;

I'm using a NRF52832 using SDK 12.0

Parents
  • FormerMember
    0 FormerMember

    1) From what I understand, in a worst case scenario, the firmware on the devices should be updated every 10s, i.e, transfer of data from the central (Android, iOS) to the peripheral (the device). In that case, the best working solution is to use regular writes of 20 bytes. However, depending on the connection interval and the number of packets per connection interval supported by the central, it may not be possible to transfer 60 kB of data within 10 s. This blog post shows typical number of packets per connection interval for various phones.

    Another option could be to use data packet length extension (DLE), where the maximum packet length is 255 bytes. However, currently, there is only a few phones that support DLE.

    It is also possible to look into Bluetooth 5, it was released two weeks ago and is currently supported by very few devices. Bluetooth 5 allows higher transfer speed than Bluetooth 4.2.

    2) I would think it is "allowed" to do what you describe, for instance have a heart rate profile and some extra services in addition heart rate profile. It could be regarded as a device with two profiles.

Reply
  • FormerMember
    0 FormerMember

    1) From what I understand, in a worst case scenario, the firmware on the devices should be updated every 10s, i.e, transfer of data from the central (Android, iOS) to the peripheral (the device). In that case, the best working solution is to use regular writes of 20 bytes. However, depending on the connection interval and the number of packets per connection interval supported by the central, it may not be possible to transfer 60 kB of data within 10 s. This blog post shows typical number of packets per connection interval for various phones.

    Another option could be to use data packet length extension (DLE), where the maximum packet length is 255 bytes. However, currently, there is only a few phones that support DLE.

    It is also possible to look into Bluetooth 5, it was released two weeks ago and is currently supported by very few devices. Bluetooth 5 allows higher transfer speed than Bluetooth 4.2.

    2) I would think it is "allowed" to do what you describe, for instance have a heart rate profile and some extra services in addition heart rate profile. It could be regarded as a device with two profiles.

Children
No Data
Related