• State Verified Answer
  • Replies 3 replies
  • Subscribers 71 subscribers
  • Views 6859 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 114065
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Best strategy for bulk transfer over BLE?

Elias

My BLE application needs to occasionally (1-2 times a year) send large amounts (several kbytes) of data, and I'm wondering about how to make this happen as fast as possible.

I'm thinking that for sending data from the peripheral, I could have a characteristic with notifications enabled that is 20 bytes large (the user data available in the Max Transmission Unit) and updated when a BLE_EVT_TX_COMPLETE happens, so a notify-transmit-update cycle happens until an EOF code is sent.

For receiving data in the peripheral, I could just use the write handler as normal, also from a 20-byte characteristic, and assume that it happens quickly enough to keep up with the connection events.

Is there another scheme that would play more nicely with s132 SD, in terms of speed or reliability, like using 512-byte characteristics and queued writes? Obviously, BLE isn't optimized for this, but the technology is appropriate for the application since this happens infrequently.

Parents
  • 0

    This is pretty much exactly what the Nordic UART service, which is one of the oldest examples in the SDK, has always done and is the standard way of sending streamed data over bluetooth.

    There's no need to worry about the other side 'keeping up' as the link layer has guaranteed delivery of packets accepted, so as long as the link stays up, data will be received, in order, and given to your app.

    512 byte characteristics would be much slower as they require round trip confirms for each packet sent so you lose the ability to send more than one packet per connection interval.

    Throughput using notifications is discussed constantly here, do a search for throughput or notification or NUS service and you'll find 300 threads about it.

Reply
  • 0

    This is pretty much exactly what the Nordic UART service, which is one of the oldest examples in the SDK, has always done and is the standard way of sending streamed data over bluetooth.

    There's no need to worry about the other side 'keeping up' as the link layer has guaranteed delivery of packets accepted, so as long as the link stays up, data will be received, in order, and given to your app.

    512 byte characteristics would be much slower as they require round trip confirms for each packet sent so you lose the ability to send more than one packet per connection interval.

    Throughput using notifications is discussed constantly here, do a search for throughput or notification or NUS service and you'll find 300 threads about it.

Children
Related
Terms of service