Send long packets for Android using low MTU sizes

Hi,

In a ble_app_uart example I have problems to send long packets if the Android smartphone only accepts MTU sizes of 20 bytes. I'm using the nRF5_SDK_17.1.0, the S132 over the SES IDE and the nR52-DK board.

The application adjusts the MTU size to the value negotiated by the smartphone and it's set to 20 bytes. However, when I send longer packets the smartphone only receives a part. It looks like the device only send one packet and doesn't manages automatically the division of the full packet for sendidn it in different subpackets.

How could I setup the Softdevice so it could automatically manages this sending of a long packet in subpackets? Excuse me if there is other similar case about this, but I have not been able to find it.

Thank you in advance.

Regards,

Joel

Parents
  • Hi,

    I have tested this using the Android nRF Connect app. I have the m_ble_nus_max_data_len  variable set to 20 in the nRF SDK. In nRFConnect Android app I do the next sequence:

    - I connect to the Nordic UART Service of the Dk board program.

    - I open the tab of this service. In the tab, I select Connect.

    - I select the "Nordic UART Service" and the app presents the RX Characteristics values and the TX Characteristics values.

    - I push the icon in the "Tx Characteristics". I understand that this will enable the reception of notifications.

    - I push the icon in the "Rx Characteristics". It opens a window to write a command to my FW. I send it.

    - The DK sends an answer that should be greater than 20 bytes. However, I can only receive 20 bytes and I the app doesn't receive more packets of 20 bytes.

    How could enable the automatic sending of the rest of the packet from the DK to the nRFConnect app?

    Regards,

    Joel

  • jinvers said:
    How could enable the automatic sending of the rest of the packet from the DK to the nRFConnect app?

    You need to send them yourself, 20 bytes at a time.

    But, you may record doing this using Macros, so that you can simply re-play the macro recording afterwards, if you need to send the same set with 20 bytes data later.

    https://github.com/NordicSemiconductor/Android-nRF-Connect/blob/main/documentation/Macros/README.md

  • I suspected this, but I needed a confirmation. Thank you.

    I'm making tests using the event BLE_GATTS_EVT_HVN_TX_COMPLETE for being sure that a packet has been sent before sending the next. And limiting each packet to the size of m_ble_nus_max_data_len variable. And it looks it's working now.

    One question: when I send a string command (ex. 0x23 0x35 0x0A) to the device by using the "Rx Characteristics" window, I can read in the log file that the smartphone receives a notification from the device before thet receiving the confirmation of the sent command from the smartphone.This message in the log file is the next:

    Data written to 6e400002-b5a3-f393-e0a9-e50e24dcca9e, value: (0x) 23-25-0A (line in white colour)

    "#5

    "sent

    I would need to manage in the device this confirmation before sending to the smartphone the first notification package. What event should I control in the device to detect that the smartphone has received that confirmation? 

    Regards,

    Joel

  • Hi,

    jinvers said:

    One question: when I send a string command (ex. 0x23 0x35 0x0A) to the device by using the "Rx Characteristics" window, I can read in the log file that the smartphone receives a notification from the device before thet receiving the confirmation of the sent command from the smartphone.This message in the log file is the next:

    Data written to 6e400002-b5a3-f393-e0a9-e50e24dcca9e, value: (0x) 23-25-0A (line in white colour)

    "#5

    "sent

    The nRF52 does not send any notification in this case. It's likely just the lower level blueooth stack on phone confirming to the phone application that the package was sent. 

    jinvers said:
    I would need to manage in the device this confirmation before sending to the smartphone the first notification package. What event should I control in the device to detect that the smartphone has received that confirmation?

    If the smartphone sends you anyhting, you wil get this data in the nus_data_handler() callback. Here you can check if you get the expected data/command, and if so, you can then start sending notifications to the phone.

  • Thank you Sigurd for your answer.

    The nRF52 does not send any notification in this case. It's likely just the lower level blueooth stack on phone confirming to the phone application that the package was sent. 

    Sometimes this message is displayed before the phone receives the notification and sometimes afterwards. So, my doubt was if we could have a problem If the phone app is waiting to receive this confirmation message before testing the notifications.

    If the smartphone sends you anyhting, you wil get this data in the nus_data_handler() callback. Here you can check if you get the expected data/command, and if so, you can then start sending notifications to the phone.

    Yes, I was using this handler yet to process the command received from the phone. Perhaps I will have to manage some delay before sending the first notification to the phone to let it process the confirmation message before.

    Regards,

    Joel

Reply
  • Thank you Sigurd for your answer.

    The nRF52 does not send any notification in this case. It's likely just the lower level blueooth stack on phone confirming to the phone application that the package was sent. 

    Sometimes this message is displayed before the phone receives the notification and sometimes afterwards. So, my doubt was if we could have a problem If the phone app is waiting to receive this confirmation message before testing the notifications.

    If the smartphone sends you anyhting, you wil get this data in the nus_data_handler() callback. Here you can check if you get the expected data/command, and if so, you can then start sending notifications to the phone.

    Yes, I was using this handler yet to process the command received from the phone. Perhaps I will have to manage some delay before sending the first notification to the phone to let it process the confirmation message before.

    Regards,

    Joel

Children
No Data
Related