• State Not Answered
  • Replies 1 reply
  • Subscribers 87 subscribers
  • Views 398 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 262703
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

BLE questions

Roei

Hi,

I have some questions regarding BLE:

1) What is the max payload size? Where can I find it?

2) What is the throughput in bps? Where can I find it?

3) Where can I find the maximum latency?

4) Is there any mechanism for validation of incoming messages? CRC validation? Can I define that?

Thanks!

Parents
  • 0

    Hi,

    1) The default link-layer payload is 27 bytes, giving an ATT MTU size of 23 bytes. However, for the full picture, you need to take into account how data is sent in multiple packets, data length extension, etc. There are also multiple packets per connection event, depending on event length. See the Bluetooth Core Specification, and our SoftDevice Specifications (for our stack.)

    2) Throughput depends on various settings, and depend on what parameters are supported by the devices. We do have a list of numbers for various scenarios using our stack, in the SoftDevice Specification for each of our SoftDevices. See e.g. for the S140 SoftDevice here: Bluetooth Low Energy data throughput.

    3) What latency are you looking for? Roundtrip? Internally in one end? What is the use case / scenario?

    4) There are CRC checks as part of the protocol, yes. You cannot choose yourself, it is mandated by spec. You may of course add additional checks on the application level, but that is usually overkill. For instance, for our device firmware upgrade (DFU) solution transferring application images over BLE, we use additional CRC check of the full image before completing the DFU, mostly because the consequences of an error is so incredibly large (upgrading to a broken application will likely brick the device). That CRC check serves, not as a  check that individual packets were correctly transferred, but that the packets were correctly assembled and correctly written to flash in the receiving end.

    Regards,
    Terje

Reply
  • 0

    Hi,

    1) The default link-layer payload is 27 bytes, giving an ATT MTU size of 23 bytes. However, for the full picture, you need to take into account how data is sent in multiple packets, data length extension, etc. There are also multiple packets per connection event, depending on event length. See the Bluetooth Core Specification, and our SoftDevice Specifications (for our stack.)

    2) Throughput depends on various settings, and depend on what parameters are supported by the devices. We do have a list of numbers for various scenarios using our stack, in the SoftDevice Specification for each of our SoftDevices. See e.g. for the S140 SoftDevice here: Bluetooth Low Energy data throughput.

    3) What latency are you looking for? Roundtrip? Internally in one end? What is the use case / scenario?

    4) There are CRC checks as part of the protocol, yes. You cannot choose yourself, it is mandated by spec. You may of course add additional checks on the application level, but that is usually overkill. For instance, for our device firmware upgrade (DFU) solution transferring application images over BLE, we use additional CRC check of the full image before completing the DFU, mostly because the consequences of an error is so incredibly large (upgrading to a broken application will likely brick the device). That CRC check serves, not as a  check that individual packets were correctly transferred, but that the packets were correctly assembled and correctly written to flash in the receiving end.

    Regards,
    Terje

Children
No Data
Related