Bluetooth Low Energy MTU size for characteristics

Hi,

I am creating a BLE application based on the NordicThingy sample.
The sample only uses characteristics that are short.
I have a BLE GATT server that has a characteristic which is ~150bytes.
I can connect to it and everything works but the value I receive is truncated to 20 bytes.

After some research it seems that 20 bytes is the default MTU size.
I can receive the full longer value using the android "nRF connect" app though.
So the problem seems to be my app.

Does anyone know how to solve this?

Ray

Top Replies

jim_m_58 over 4 years ago in reply to Michael +1

Link to the bug report for this: https://forums.garmin.com/developer/connect-iq/i/bug-reports/messages-from-btle-gatt-server-truncated-at-20-bytes

Upvote and add comments.

All Replies

0 Chris Hanger over 5 years ago

I am just starting too...

0 jim_m_58 over 5 years ago in reply to Chris Hanger

With the nordic sample, the key part is setting the BLE profile(s). With this you are limited to 3 profiles in a CIQ app.

How far have you gotten? In CIQ can you scan for the device and pair to it?

0 Chris Hanger over 5 years ago in reply to jim_m_58

Starting now.

Gonna start a new thread. This is gonna get big...

0 Chris Hanger over 4 years ago

I am having the same problem. The TREADMILL_DATA_CHARACTERISTIC within FITNESS_MACHINE_SERVICE is over 40 bytes long. I'm missing important information. Help!!

0 5458292 over 4 years ago

Just working on this again. I could not find any information anywhere to get around the 20 byte limit.

Chris Hanger did you get further with this?

0 Chris Hanger over 4 years ago in reply to 5458292

Nope. The size limitation makes the watch incompatible with fitness equipment, which sends out a longer characteristic.

Luckily, the most useful data occurs at the beginning of the byte string coming-in from the treadmill. But calories, Watts and a whole lot more are lost... Such a shame

0 5458292 over 4 years ago in reply to Chris Hanger

Could you confirm with anyone from Garmin that this is really a technical limitation and not some configuration issue we might miss?

On a side-note:
Is there any contact at Garmin for non-trivial SDK issues?

0 jim_m_58 over 4 years ago in reply to 5458292

Has anyone submitted a bug report in the CIQ Bug report forums about this? That's now to get an official answer from Garmin.

0 5458292 over 4 years ago in reply to jim_m_58

thanks - just did that

0 Michael over 4 years ago

I was just looking at this. I'm guessing that Garmin has definted 20 bytes of application data per BLE packet

from (https://punchthrough.com/maximizing-ble-throughput-part-2-use-larger-att-mtu-2/)

ATT Maximum Transmission Unit (MTU) is the maximum length of an ATT packet. The ATT MTU is defined by the L2CAP and can be anywhere between 23 and infinity. The implementation of the Bluetooth stack is the key factor of determining the ATT MTU on both client and peripheral.

A generic ATT packet has the following structure:

Where OP-Code indicates the ATT Operation such as Write Command, Notification, Read Response or etc. The ATT Data field contains the application data.

When sending a Write, Read and Notification or Indication packets, the associated attribute handle (2 octets) will also need to be included for identification of the data.

For the default case of ATT MTU of 23 bytes, the over head bytes result in 13% of overhead data.