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

Why is S132 BLE GATT Notification bandwidth spec'd as 16kbps not 24kbps?

The last table on the S132 Specification BLE "data throughput" web page lists the maximum GATT Notification send/receive rates as 16kbps when using an event length of 2.5ms and C.I. of 20mS.

A quick calculation suggests that 2.5mS is enough time for 3 Notification packet transfers per event (0.708uS per transfer including 2 x T_IFS). This would yield (3 x 20 x 50) = 3kBps = 24kbps of Notification payload.

Am I making a mistake in my calculation or is this discrepancy due to a limitation in the scheduling or buffering?

Ref: infocenter.nordicsemi.com/index.jsp

Parents
  • In terms of radio time you will fit 3 packets pairs (one full, one empty) in 2.5 ms, but the 2.5 ms will not be utilized completely for transmitting/receiving. In it you also have scheduling of timing events, processing of potential radio traffic, switching/re-configuring of radio hardware, and so on.

    Also, after two packets pairs have been exchanged the SoftDevice will check if it is able to exchange a complete packet pair (both ways), if not it, will not try.

    The numbers in the spec are measured values, so this is what you should expect to see. If you see something else, please let us know.

Reply
  • In terms of radio time you will fit 3 packets pairs (one full, one empty) in 2.5 ms, but the 2.5 ms will not be utilized completely for transmitting/receiving. In it you also have scheduling of timing events, processing of potential radio traffic, switching/re-configuring of radio hardware, and so on.

    Also, after two packets pairs have been exchanged the SoftDevice will check if it is able to exchange a complete packet pair (both ways), if not it, will not try.

    The numbers in the spec are measured values, so this is what you should expect to see. If you see something else, please let us know.

Children
Related