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

Data length update with pc-ble-driver-py library

Hi everyone,

I am trying to start a data length update procedure from a central that I am developing with python using the library pc-ble-driver-py.

However, I keep having the error 0x13 which corresponds to a timeout (generated in the function "ble_gap_data_length_update"). I had to add the event "on_gap_evt_data_length_updated" in the adapter.py file, but still nothing.

I saw on the github of the library that this event has been removed at a previous commit saying that only the API v3 supports this event.

Does this mean that I cannot start a data length from the central with API v5? why is the event "gap_evt_data_length_update = driver.BLE_GAP_EVT_DATA_LENGTH_UPDATE" still figure in the driver.py file? 

Can the central still receive and treat a data length update request from a peripheral?

Thanks in advance

Imen

Parents
  • More details about trying to get data_length_update to work

    Peripheral flashed on a nrf52832 with  nRF5_SDK_15.3.0 ble_app_multirole_lesc exemple.

    When I do a ble_gap_data_length_update() with all parameters set to BLE_GAP_DATA_LENGTH_AUTO “0”  (or any other value), none error is returned and I get the right event on_gap_evt_data_length but with strange values that  change after each try for on the pc-ble-driver-py:

     

    Exemple with all parameter set to 0 (BLE_GAP_DATA_LENGTH_AUTO):

    Result on the pc-ble-driver-py (nrf52832)

    • Max tx octets = 27 (ok)
    • Max rx octets = 483 (??)
    • Max tx times us = 256 (??)
    • Max rx time us = 0 (??)

     

    Result on the JLink viewer connected to the peripheral nrf52832 with ble_app_multirole_lesc, I have the right parameters:

            BLE_GAP_EVT_DATA_LENGTH_UPDATE: Data length update to 27 on connection 0x1

    • Max tx octets = 27 (ok)
    • Max rx octets = 27 (ok)
    • Max tx times us = 2120 (ok)
    • Max rx time us = 2120 (ok)

     

    I get the parameters with following lines:

      print("data_length_params max_tx_octets = " + str(data_length_params.max_tx_octets))

            print("data_length_params max_rx_octets = " + str(data_length_params.max_rx_octets))

            print("data_length_params max_tx_time_us = " + str (data_length_params.max_tx_time_us))

            print("data_length_params max_rx_time_us = " + str (data_length_params.max_rx_time_us))

     

     

    Other exemples call ble_gap_data_length_update() with BLEGapDataLengthParams(max_tx_octets=100, max_rx_octets=100, max_tx_time_us=0, max_rx_time_us=0):

     

    On the Central with pc-ble-driver:

    • Max tx octets = 27 (ok)
    • Max rx octets = 1000 (??)
    • Max tx times us = 256 (??)
    • Max rx time us = 0 (??)

     

    Other try:

    • Max tx octets = 27 (ok)
    • Max rx octets = 20850 (??)
    • Max tx times us = 0 (??)
    • Max rx time us = 29184 (??)

     

    Other try:

    • Max tx octets = 14363 ((??))
    • Max rx octets = 192 (??)
    • Max tx times us = 0 (??)
    • Max rx time us = 0 (??)

    With the JLink viewer connected to the peripheral nrf52832 with ble_app_multirole_lesc I have the good parameters:

                    BLE_GAP_EVT_DATA_LENGTH_UPDATE: Data length update to 27 on connection 0x1

    • Max tx octets = 27 (ok)
    • Max rx octets = 27 (ok)
    • Max tx times us = 912 (ok)
    • Max rx time us = 912 (ok)

     Do you have any idea what makes the event get me different values everytime with the same config asked? I believe the problem comes form pc-driver-ble-py knowing that the peripheral gets the right values

    Thanks, Imen

  • Hello Imen,

    I tried installing the latest 0.11.4 release to replicate this, but it appears to only support SD API v3 for the 52 series. Are you testing with a different branch? 

    Regards,

    Vidar 

  • Sorry, I thought v.0.11.4 was the latest, and I wasn't sure how you were able to use API v5 with that release. What I see now after updating to 0.14 is that the packet length gets correctly updated when receiving the request from the peer device, but the parameters reported to on_gap_evt_data_length_update() were still invalid like they were in your case.

    I used the heart rate collector script for my test and only added on_gap_evt_data_length_update() function so I could log the DL parameters. 

        def on_gap_evt_data_length_update(
            self, ble_driver, conn_handle, data_length_params
        ):
            print("Max rx octets: {}".format(data_length_params.max_rx_octets))
            print("Max tx octets: {}".format(data_length_params.max_tx_octets))
            print("Max rx time: {}".format(data_length_params.max_rx_time_us))
            print("Max tx time: {}".format(data_length_params.max_tx_time_us))
    Result from one of the tests I di:

    Max rx octets: 400
    Max tx octets: 151 
    Max rx time: 0
    Max tx time: 0

    And the corresponding result from  the ble_app_hrs peripheral SDK example running on the other side:

    <debug> nrf_ble_gatt: Data length updated to 151 on connection 0x0.
    <debug> nrf_ble_gatt: max_rx_octets: 151
    <debug> nrf_ble_gatt: max_tx_octets: 151
    <debug> nrf_ble_gatt: max_rx_time: 1320
    <debug> nrf_ble_gatt: max_tx_time: 1320

    I have not been able to figure out why the event parameters are not correctly forwarded from the Softdevice, but it looks like it might be a bug in the driver implementation. I have reported this as a bug internally. 

    Data Length Update Procedure 

  • Thank you for confirming the problem, I will be very happy to know when it is resolved, thank you

    Imen

  • I will update the ticket when I have more details. Hopefully, it's an easy fix. 

  • Any update on the data length problem? thanks

  • The task has been added to the current sprint, which ends January 7, but as there are a few holidays in the next couple of weeks, I'm not sure how much time they will get to spend on it. But were you able to get longer data packets as I did? You can use the debug output from the peripheral to confirm.

Reply Children
Related