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

Issues with characteristic values using the pc-ble-driver-py library

Hello!

I am doing some development with pc-ble-driver-py and ran in to some unexpected behaviours when reading characteristics. I have been modifying the nus_collector.py script that was given as an example on this post. I am also using a PCA10028 to scan for devices.

Firstly, when scanning for devices, they last few characters for some devices are missing or corrupted. For example, when receiving the advertising name of a device with the name of "TestDev", the received name is captured as follows:

where the expected output should be:

Upon using nRF Connect (either PC or mobile versions), the correct device name is displayed:

   

This end of device name string corruption does not just happen for this particular device - I have tested scanning other devices where I see a similar behaviour with differing amounts of corruption (e.g. some devices only have 1 character that is corrupted at the end of the string). However, not all of the devices I have scanned display the corruption; some devices have their advertising names being received correctly.



Secondly, when receiving heart rate notifications from a connected device, the data is tens of thousands of values in length. Is there any documentation on how to convert this data so it can be interpreted in beats per minute (bpm)? Note: the heart rate is correctly displayed on nRF Connect (both PC and mobile).

Here is the modified nus_collector.py script that I have been using to test:

Any help with either of these issues would be greatly appreciated!

Regards,

Scott

Parents
  • Hi,

    Which device are you testing this against? Are you running the HRS example from the SDK? Are you seeing this name issue with other peripherals as well, or only this device?

    Could you give an example of the HRS data issue? The data should only contain the bpm value.

    Best regards,
    Jørgen

  • Yes, I have tried the Heart Rate Collector example in the repository and the same behaviour occurred.

  • I tried reproducing this on a similar environment, but I'm not able to see this issue. Did you test with the HRS example from the SDK? Have you made any modifications to the pc-ble-driver-py libraries?

    This is the output when I run the sample you posted above when testing against SDK HRS example:

  • I do see the corruption issue in your output in line 26. "TestDev" is the string of your device name but once the connection is established it is read as "Tes   ·" - the last 4 characters are overwritten.

    This is the output I get when testing against the HRS example in the SDK:

    Corruption can be seen on lines 15, 55, and 72.

  • Hi,

    is currently out-of-office.

    I have not (as of yet) been able to reproduce for received advertising data, but I have reproduced for listing the device name upon connection:

    Clearly something is not right, and I am investigating further.

    Regards,
    Terje

  • Hi,

    We are consistently reproducing the Device Name read issue, and have isolated it to be in either pc-ble-driver or pc-ble-driver-py. (I.e. it is not a connectivity firmware issue, and not a UART issue.)

    Regarding the values read from the Heart Rate Measurement characteristic, those should not be 36660+ bytes long. Via bluetooth.com you can find the format for the HRM value. Studying the log output, it seems the last few bytes of "Heart Rate Received" are corrupted as well. Looks to me like a "use after free" issue somewhere in either pc-ble-driver or pc-ble-driver-py. The team is looking into it.

    Regards,
    Terje

  • Thanks! I will investigate a bit more to see why we could be getting 36000+ bytes for our Heart Rate Measurement...

Reply Children