• State Not Answered
  • +1 person also asked this people also asked this
  • Replies 29 replies
  • Subscribers 24 subscribers
  • Views 12431 views
  • Users 0 members are here
Options
Related

Bluetooth Low Energy MTU size for characteristics

Former Member
Former Member over 5 years ago

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

  • 0 over 2 years ago in reply to CYBERMAN54

    No, it's based on the max size that BLE in connect IQ can receive.  While 200 bytes can be sent, you app will only see the truncated amount.  From what I've seen over the last few years, UUID doesn't matter.  If you can't control the server, just hope what you need is in the first 20 or so bytes.

  • 0 over 2 years ago in reply to jim_m_58

    But i _do_  receive longer messages from a certain device, which operates a HM10 Bluetooth module running HMSoft BLE stack. The data is coming in as notifications, triggering onCharacteristicChanged() Callback, and is not truncated, neither chunked. The device is sending it's payload sentences with checkums, and my app validates it. It works, no data gets lost.

    So there is a possibility to process BLE messages longer than 20 bytes.

  • 0 over 1 year ago in reply to CYBERMAN54

     Can share more? Especially interesting since others report HM10 has the same 20 byte MTU limit.

    https://obddiag.net/ble-adventures.html

  • 0 over 1 year ago in reply to N-gineer

    Garmin devices support MTU max. size 20 only. Usually this shouldn't be a problem, if client devices use a full implemented BLE stack which initially negotiate MTU size between GATT Client and Server. Then the connection runs on 20 byte MTU size.

    But this means that the GATT server device must split up it's data into 20 bytes chunks before sending it to the Garmin GATT client. In my case this was not implemented on sensor (= server) side, so no chance to get it working. In those cases the sensor device software needs to be changed / updated.

    HM10 modules use MTU size 20 as default, and if used in serial bridge mode, they do the necessary data chunking automatically, so should work if used in serial bridge mode. But be aware of fake clones of this modules which may sport a crippled firmware.

  • 0 over 1 year ago in reply to CYBERMAN54

    Client side referring to Garmin and Server referring to the HM10?

  • 0 over 1 year ago in reply to N-gineer

    Garmin = BLE central, performing GATT operations on a BLE peripheral (sensor)

    HM10 = GATT server

    Garmin device with IQ always operates as BLE central, since the IQ API provides no methods for acting as a GATT server:
    "The BluetoothLowEnergy module provides access to Generic BLE communication functionality in the central role. Including the ability to scan for peripheral devices, pair with sensors, and performing GATTC operations on a peripheral"
    developer.garmin.com/.../BluetoothLowEnergy.html

  • 0 over 1 year ago in reply to CYBERMAN54

    Ok, I think I understand now. The HM10 runs MTU of 20, but the other device you were working with was trying to send a larger MTU and the handshake between the two on MTU size didn't happen?

  • 0 over 1 year ago in reply to N-gineer

    The point is: if you are fixed on MTU size 20 (as with Garmin) you need an application on GATT server side, which can handle this limitation, if payload is > 20 bytes. In those cases the sensor application must chunk it's payload. This can be done by the application itself, or by some kind of middleware, e.g. using an HM10 in serial bridge mode.

    Otherwise it's impossible to see the full payload of the client on Garmin side.

    This problem affects only to sensors/BLE devices, which send payloads > 20 bytes in one BLE message.

  • 0 over 1 year ago in reply to N-gineer

    It's not MTU handshake problem. Negotiating MTU size works properly with BLE stack of Garmin devices. It always results to MTU=20 for the BLE connection. This may result to a problem for GATT servers which have payloads > 20 bytes and do not chunk this into 20 bytes packets. Thus, it's a problem on application layer of GATT server side.