• State Verified Answer
  • Replies 3 replies
  • Subscribers 69 subscribers
  • Views 1190 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 278018
Options

BLE Uart increase 20 byte limitation

Jeffe

Hello,

Currently I am experiencing some problem getting the NUS to send a TX notification of more than 20 bytes to the central (which is an old custom android application). From the logs on the android application side, it looks like my messages are getting cut off after 20 bytes. I have already increase the NRF_SDH_BLE_GATT_MAX_MTU_SIZE  to 240 and also the MESH_GATT_PACKET_MAX_SIZE to 240 since I am running the NUS alongside Mesh, yet the above issue still remains. Are there any suggestions for this?

Some background:

- The problem is definitely not the android application, because it also used to connect with a raspberry Pi BLE peripheral running the NUS and the raspberry Pi can send notifications of well over 20 bytes just fine

- This is probably unrelated, but for the Mesh side I use PB-Gatt for provisioning and have proxy enabled. So this is a BLE-and-Mesh coexistence kind of application. The mesh proxy service runs alongside the NUS. The mesh part of the software runs perfectly fine. 

- Basically what I'm trying to do is to make the my current software backwards compatible with an old android application that has proven to work with a raspberry Pi BLE peripheral also hosting a NUS. 

Thanks in advance

Parents
  • 0

    Could you enable logging in the GATT module and print the debug logs from the device? It will give information about the MTU request/response after connection between the central and peripheral is established.

  • +1 in reply to Marjeris Romero

    Sorry my bad I forgot to include that information. I use the nRF5 17.0.2 SDK and the nRF5 SDK for Mesh 5.0.0, on the nrf52840

    I don't use the GATT library you mentioned above, as I think I mostly rely on calls to the softdevice for the NUS, or otherwise use the Mesh SDK's gatt functions (mesh_gatt.c and mesh_gatt.h). 

    However, luckily I managed to figure out the problem in the meantime.

    How I solved my problem:

    On a hunch, I decided to  test with the NUS client from the nRF Toolbox to connect to the NUS of my nrf52840 application instead of using the existing old Android App. Curiously enough, the NUS client from the nRF Toolbox Android App **did work** somehow, which at first confused me.

    But I noticed that the nRF Toolbox negotiated the MTU size whereas the custom Android application did nothing in regards to the negotiating a MTU size. So I think what happened is that since my nrf52840 application did not receive a MTU negotiation from the Central, it just assumed that the MTU size is the minimum since there was no response, despite the fact that I set the NRF_SDH_BLE_GATT_MAX_MTU_SIZE  to a large number. 

    Once I changed the custom android application's code to request a MTU size (where before it did nothing of the sort), before discovering services, I was able to send more than 20 bytes. 

    I said in the openning post that there was no issue with the Android Application, but it seemed like my assumption was wrong. I was lead astray and made that wrong assumption because I knew the raspberry Pi BLE peripheral with the NUS service worked (and still works now) with the custom Android application just fine.

    Now the real mystery is why the raspberry Pi was able to work despite not receiving a negotiation from the central about the MTU size. I am not familiar with the codebase running on the raspberry Pi I mentioned so this may stay a mystery forever heheh.

    ------------------------------------------------

    So TLDR; custom android application does not request an MTU size, so due to the lack of such negotiation from the BLE central, the SDK  probably just assumed the minimum ATU size for BLE communication (I think?, not 100% sure but this is the most reasonable conclusion I can think of).  Solved it by making sure the central (the custom Android App) requests a MTU size upon connection and before discovering services. Correct me if I am wrong about that assumption about the SDK. 

    Thank you for your very prompt reply and support!

Reply
  • +1 in reply to Marjeris Romero

    Sorry my bad I forgot to include that information. I use the nRF5 17.0.2 SDK and the nRF5 SDK for Mesh 5.0.0, on the nrf52840

    I don't use the GATT library you mentioned above, as I think I mostly rely on calls to the softdevice for the NUS, or otherwise use the Mesh SDK's gatt functions (mesh_gatt.c and mesh_gatt.h). 

    However, luckily I managed to figure out the problem in the meantime.

    How I solved my problem:

    On a hunch, I decided to  test with the NUS client from the nRF Toolbox to connect to the NUS of my nrf52840 application instead of using the existing old Android App. Curiously enough, the NUS client from the nRF Toolbox Android App **did work** somehow, which at first confused me.

    But I noticed that the nRF Toolbox negotiated the MTU size whereas the custom Android application did nothing in regards to the negotiating a MTU size. So I think what happened is that since my nrf52840 application did not receive a MTU negotiation from the Central, it just assumed that the MTU size is the minimum since there was no response, despite the fact that I set the NRF_SDH_BLE_GATT_MAX_MTU_SIZE  to a large number. 

    Once I changed the custom android application's code to request a MTU size (where before it did nothing of the sort), before discovering services, I was able to send more than 20 bytes. 

    I said in the openning post that there was no issue with the Android Application, but it seemed like my assumption was wrong. I was lead astray and made that wrong assumption because I knew the raspberry Pi BLE peripheral with the NUS service worked (and still works now) with the custom Android application just fine.

    Now the real mystery is why the raspberry Pi was able to work despite not receiving a negotiation from the central about the MTU size. I am not familiar with the codebase running on the raspberry Pi I mentioned so this may stay a mystery forever heheh.

    ------------------------------------------------

    So TLDR; custom android application does not request an MTU size, so due to the lack of such negotiation from the BLE central, the SDK  probably just assumed the minimum ATU size for BLE communication (I think?, not 100% sure but this is the most reasonable conclusion I can think of).  Solved it by making sure the central (the custom Android App) requests a MTU size upon connection and before discovering services. Correct me if I am wrong about that assumption about the SDK. 

    Thank you for your very prompt reply and support!

Children
No Data
Related