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 

  • 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
No Data
Related