pc-ble-driver-py missing high-rate notifications

RE: pc-ble-driver-py missing high-rate notifications

hector_leon — Wed, 04 Oct 2023 20:15:10 GMT

Thank you!

RE: pc-ble-driver-py missing high-rate notifications

Karl Ylvisaker — Thu, 28 Sep 2023 11:26:15 GMT

Hello,

[quote user="hector_leon"]How did you developed a tool running on a Windows laptop?[/quote]

As discussed in the previous comments on this ticket you can use the (now deprecated) pc-ble-driver to create an windows application that does Bluetooth through a Nordic BLE Connectivity device.

[quote user="hector_leon"]I need to do the same with C# but I don't know where to start.[/quote]

As far as I know we do not have any application made using C#, could you elaborate on this requirement on your part? I personally have no experience working with C#, but could it not be a possibility to interface your C# based application with a standard C or python application?

Please keep in mind that this ticket is over 3 years old, and so I would not expect the original poster to come back to this ticket quickly. In this case I would therefore recommend opening a new ticket for this issue.

Best regards,
Karl

RE: pc-ble-driver-py missing high-rate notifications

hector_leon — Thu, 28 Sep 2023 01:05:38 GMT

Hello!

How did you developed a tool running on a Windows laptop? I need to do the same with C# but I don't know where to start. I'll appreciate your help.

RE: pc-ble-driver-py missing high-rate notifications

Karl Ylvisaker — Mon, 14 Dec 2020 15:30:34 GMT

Hello Davege,

Attached you will find a zip file for the peripheral project to be used with SDK v.17.0.2. It is modified to send two notifications every connection event, with a connection interval of 15 ms.
The attached python file is the file you should run for the central, with the pc-ble-driver-py python package installed.

Please flash an nRF52 DK with the peripheral firmware, and run a central with the pc-ble-driver-py code, and take a trace of the communication that is happening.
Ideally we should then see multiple notifications per connection event.

Looking forward to hearing back from you,

Best regards,
Karl
devzone.nordicsemi.com/.../8255._5F005F00_ble_5F00_app_5F00_hrs_5F00_multiple_5F00_notifications_5F00_pca10040.zip devzone.nordicsemi.com/.../7242._5F005F00_heart_5F00_rate_5F00_collector_5F00_multiple_5F00_notifications.py

RE: pc-ble-driver-py missing high-rate notifications

davege — Fri, 11 Dec 2020 15:33:31 GMT

Hi,

it would be great to have those, if I can just use a nRF52-DK as a peripheral it is even better.

I can first test and then providing a sniffing trace to you.

Thanks

RE: pc-ble-driver-py missing high-rate notifications

Karl Ylvisaker — Fri, 11 Dec 2020 10:59:57 GMT

Hello Davege,

[quote user="davege"]I'm a bit frustrated as now I'm at the point where it would be extremely useful to get the notifications running.[/quote]

Yes, for course. I am sorry to hear that.

[quote user="davege"]

I tried adding your changes but see no effects whatsoever.

Did something change with the setup you have?

[/quote]

Could you send a trace of the communication when you test it with the changes?
With the changes mentioned in my last comment I am seeing multiple notifications per connection event.

[quote user="davege"]I believe that if you find any kind of solution, that will work also on your end (using Nordic UART characteristic or similar).[/quote]

Using the code from my last comment I am seeing multiple notification per connection event on my end.
If it would be easier for you, I could send you the .py file and .hex file for the peripheral, for you to test this?
If you are not seeing multiple notifications per event it would be really useful to see a sniffer trace.

Best regards,
Karl

RE: pc-ble-driver-py missing high-rate notifications

davege — Fri, 11 Dec 2020 10:22:26 GMT

Hi Karl Ylvisaker,

I tried adding your changes but see no effects whatsoever.

Did something change with the setup you have?

I believe that if you find any kind of solution, that will work also on your end (using Nordic UART characteristic or similar).

I'm a bit frustrated as now I'm at the point where it would be extremely useful to get the notifications running.

Do you know if nRF Connect Desktop is using pc-ble-driver dll underneath for the connection to the dongle?
If this is the case, it may be easy to spot the change in the way the API are invoked on two sides.

Thanks,

RE: pc-ble-driver-py missing high-rate notifications

Karl Ylvisaker — Fri, 04 Dec 2020 11:44:19 GMT

Hello again Davege,

[quote user="davege"]

Unfortunately neither myself or my team at the moment has the capacity to move the testing framework implementation to pc-ble-driver, which I used in the past and I can confirm it works great.

So hopefully I'll just wait here to understand if there's any movement.

[/quote]

I totally understand, no worries at all. We will get to the bottom of this.

This might seem trivial, but could you add the following modification to your code, to see if it allows you to receive multiple notification packets per connection event?
If you are using the heart_rate_collector example, this code block should be inserted in the collector class's open function, in the NRF52 section.
It should look like this:

    def open(self):
        self.adapter.driver.open()
        if config.__conn_ic_id__.upper() == "NRF51":
            self.adapter.driver.ble_enable(
                BLEEnableParams(
                    vs_uuid_count=1,
                    service_changed=0,
                    periph_conn_count=0,
                    central_conn_count=1,
                    central_sec_count=0,
                )
            )
        elif config.__conn_ic_id__.upper() == "NRF52":
            gatt_cfg = BLEConfigConnGatt()
            gatt_cfg.att_mtu = self.adapter.default_mtu
            gatt_cfg.tag = CFG_TAG
            self.adapter.driver.ble_cfg_set(BLEConfig.conn_gatt, gatt_cfg)

            conn_cfg = BLEConfigConnGap()
            conn_cfg.conn_count = 1
            conn_cfg.event_length = 320
            self.adapter.driver.ble_cfg_set(BLEConfig.conn_gap, conn_cfg)

            self.adapter.driver.ble_enable()

You will also need to add the BLEConfigConnGap method to the list of globals, imported from driver, which should then look like this:

    global config, BLEDriver, BLEAdvData, BLEEvtID, BLEAdapter, BLEEnableParams, BLEGapTimeoutSrc, BLEUUID, BLEConfigCommon, BLEConfig, BLEConfigConnGatt, BLEConfigConnGap, BLEGapScanParams
    from pc_ble_driver_py import config

    config.__conn_ic_id__ = conn_ic_id
    # noinspection PyUnresolvedReferences
    from pc_ble_driver_py.ble_driver import (
        BLEDriver,
        BLEAdvData,
        BLEEvtID,
        BLEEnableParams,
        BLEGapTimeoutSrc,
        BLEUUID,
        BLEGapScanParams,
        BLEConfigCommon,
        BLEConfig,
        BLEConfigConnGatt,
        BLEConfigConnGap,
    )

The only difference here is that the default event_length parameter is not used, instead, the maximum event_length for the given connection interval is set explicitly.
If you could test this with your own test-script and let me know if you succeed in getting multiple packets per event, that would be great.

If it does not enable you to send multiple notifications per connection event, could you provide a trace of the test, with the code above added?

I will continue to look into this to find the required event_length analytically - instead of just setting it to the maximum value.

[quote user="davege"]Do you believe that marking this ticket as private can be useful to push things a little bit?[/quote]

No, this will not affect the internal requests priority - since the only difference between private tickets and public ones is who may view it.
Private tickets is of course only viewable by the tickets creator and the Technical Support staff here at Nordic.

Looking forward to hearing the results of your test!

Best regards,
Karl

RE: pc-ble-driver-py missing high-rate notifications

davege — Thu, 03 Dec 2020 14:20:29 GMT

Hi Karl Ylvisaker,

thanks for this.

Unfortunately neither myself or my team at the moment has the capacity to move the testing framework implementation to pc-ble-driver, which I used in the past and I can confirm it works great.

So hopefully I'll just wait here to understand if there's any movement.

Do you believe that marking this ticket as private can be useful to push things a little bit?

My company is using Nordic chips for different products, so we are already in contact.

Thanks,

RE: pc-ble-driver-py missing high-rate notifications

Karl Ylvisaker — Mon, 30 Nov 2020 11:03:00 GMT

Hello again Davege,

[quote user="davege"]

In my opinion, it is very unlikely that the problem is on the connectivity firmware running on the DK/dongle.

The reason is that exactly the same dongle running the same FW is not showing the issue when subscribing to notifications from the char via nRF Connect Desktop.

[/quote]

I fully agree with this reasoning.

[quote user="davege"]My feeling is that there is something wrong during the configuration of the board... possibly some settings hardcoded in the serialisation layer transporting data from the DK to the script, when opening the link.[/quote]

I too think that this might be an issue here. I have done some more testing, and it seems that the default ( used in the HRM collector example ) RX/TX window of the pc-ble-driver-py is 1310µs compared to the pc-ble-driver which defaults to 2120µs. However, both of these windows are big enough for multiple packets - so I do not immediately see this as a reason for the single-packet-events of the pc-ble-driver-py. However, I have noted it as the main difference in the connection configuration between the two drivers, in the notes I have made for the developers.

I have created an internal ticket on this with the developers of the pc-ble-driver-py, and I hope to hear from them soon on this issue.
Unfortunately, I am unable to estimate when they will have time to review the case exactly.
Is this issue a blocker for your current development? If so, is there an option for you to use the pc-ble-driver instead, for the time being?
Reviewing the forum for mentions of the pc-ble-driver-py's performance I have come across some posts claiming that it is significantly slower ( lower throughput ) than the pc-ble-driver. I guess this is somewhat to be expected, since the pc-ble-driver-py is an abstraction on top of the existing pc-ble-driver, but nevertheless it is something to consider.

[quote user="davege"]Thanks again for keeping me posted, I'm really curious to understand what's happening :)[/quote]

It is no problem at all - I too am curious to see what the root cause of this behavior should turn out to be! :)

Best regards,
Karl

RE: pc-ble-driver-py missing high-rate notifications

davege — Thu, 26 Nov 2020 21:52:24 GMT

Hi Karl Ylvisaker,

thanks again for your update.

In my opinion, it is very unlikely that the problem is on the connectivity firmware running on the DK/dongle.

The reason is that exactly the same dongle running the same FW is not showing the issue when subscribing to notifications from the char via nRF Connect Desktop.

My feeling is that there is something wrong during the configuration of the board... possibly some settings hardcoded in the serialisation layer transporting data from the DK to the script, when opening the link.

Thanks again for keeping me posted, I'm really curious to understand what's happening :)

Best,

RE: pc-ble-driver-py missing high-rate notifications

Karl Ylvisaker — Wed, 25 Nov 2020 14:07:45 GMT

Hello davege,

Thank you for your continued patience. I was unfortunately out of office for some days again.

I have continued testing today, and can now at least rule out that the issue is with the UART transport layer.
I have also spoken with one of the developers of pc-ble-driver-py today, and he will check if this could be caused by a limited RX buffer in the precompiled connectivity firmware.
I will update you as soon as he gets back to me about this.

[quote user="davege"]thanks a lot for your effort in this.[/quote]

It is no problem at all davege, I am happy to help!

Best regards,
Karl

RE: pc-ble-driver-py missing high-rate notifications

davege — Thu, 19 Nov 2020 21:49:19 GMT

Hi,

thanks a lot for your effort in this.

Do not worry at all, as long as I know there's some activity to understand what's happening, I'm good.

Looking forward to hearing any news.

Best,

RE: pc-ble-driver-py missing high-rate notifications

Karl Ylvisaker — Thu, 19 Nov 2020 16:09:42 GMT

Hello again Davege,

Know that I have not forgotten this issue, and I am still working on it.
Unfortunately, this issue has taken longer than I had anticipated to resolve.

I will update you as soon as I have something.

Best regards,
Karl

RE: pc-ble-driver-py missing high-rate notifications

Karl Ylvisaker — Tue, 17 Nov 2020 16:57:06 GMT

Hello Davege,

Thank you for your patience.
I have today successfully replicated the issue with the setup you described on my end.
I have allocated time tomorrow to keep working on resolving the issue.

Best regards,
Karl

RE: pc-ble-driver-py missing high-rate notifications

Karl Ylvisaker — Tue, 17 Nov 2020 09:27:54 GMT

Hello again Davege,

I am terribly sorry for the very long delay in communications from my side on this.

I have allocated time today to work through this issue. I will update you by the end of the day at the latest.
I am again terribly sorry for the long delay on this issue.

Best regards,
Karl

RE: pc-ble-driver-py missing high-rate notifications

davege — Fri, 13 Nov 2020 14:10:30 GMT

Hi Karl Ylvisaker,

is there any progress on this?

Let me know if I may help or if some reason it was not possible to reproduce the problem on your end.

Thanks,

RE: pc-ble-driver-py missing high-rate notifications

davege — Wed, 04 Nov 2020 18:11:58 GMT

Hi,

great to know you are setting up something quick to reproduce the issue.

[quote userid="87869" url="~/f/nordic-q-a/67437/pc-ble-driver-py-missing-high-rate-notifications/278446#278446"]What is the scan timeout parameter that you pass to your scan_start? Is it possible this set to indefinite?[/quote]

This is the full call with the params:

scan_duration = 5
params = BLEGapScanParams(interval_ms=200, window_ms=150, timeout_s=scan_duration)
self.adapter.driver.ble_gap_scan_start(scan_params=params)

I'm not aware about a way to scan forever, but usually with nRF5 SDK on the embedded side, this happens when setting the duration to 0.

One of the problem I have with this python bindings is that they are not documented, so sometimes I'm just guessing I'm doing the right thing given the familiarity I have with the rest of the Nordic offering.

Hopefully with your help I'll know if I'm doing something wrong 🙂

Thanks,

RE: pc-ble-driver-py missing high-rate notifications

Karl Ylvisaker — Wed, 04 Nov 2020 12:59:34 GMT

Hello,

Sorry for my late reply.

[quote user="davege"]apparently we've been writing simultaneously[/quote]

Yes, it appears we did! 🙂

[quote user="davege"]Exactly, that's the mystery to solve![/quote]

Indeed it is, this is most strange. I would assume it might stem from the radio being busy with other tasks ( and thus not following up on the more data prompt ), but something seems amiss in this case.

[quote user="davege"]

It is all very standard, as I just slightly modified the example code for the heart rate that I've found in the repository.

At HW/FW level current setup is:

pc-ble-driver-py 0.15.0 (latest)
nRF52840 Dongle (PCA10059) running connectivity FW 4.1.2 SD API v5 (latest supported)

The python script is just subscribing for notifications (on the selected custom service/char in my case, but I believe it could be whatever, even Nordic UART) and printing that line you've seen in the log with the data received.

I believe there's no scanning active after the connection to the peripheral.

[/quote]

Thank you for specifying! This is very helpful for me to know.

[quote user="davege"]Now wondering if this will keep scanning active even after I receive on_gap_evt_connected callback...[/quote][quote user="davege"]I'm calling this API:[/quote]

What is the scan timeout parameter that you pass to your scan_start? Is it possible this set to indefinite?
Looking through the unmodified example code it seems that the scanning is not stopped on CONNECTED event, but is rather set to time out.

I have reached out to the developers of the pc-ble-driver-py to ask if they have ever heard of similar behavior. I will get back to you as soon as they reply.
I will create a small example to try and reproduce this on my end, using the connection parameters and setup you described.

Best regards,
Karl

RE: pc-ble-driver-py missing high-rate notifications

davege — Mon, 02 Nov 2020 12:06:02 GMT

Hello,

apparently we've been writing simultaneously 🙂

[quote userid="87869" url="~/f/nordic-q-a/67437/pc-ble-driver-py-missing-high-rate-notifications/278042#278042"]Looking closer at the connection length in both traces, it seems like it is set correctly - So I do not see any reason why the central on the one hand pulls for additional notifications, but not in the other ( as you can see in the trace _nok, the peripheral reports that more data is available, but the central never sends another packet to retrieve it ).[/quote]

Exactly, that's the mystery to solve!

[quote userid="87869" url="~/f/nordic-q-a/67437/pc-ble-driver-py-missing-high-rate-notifications/278042#278042"]Could you tell me exactly how you have setup the dongle on your side to collect the notifications, so that I may try to replicate the issue here on my end?
Is the central doing anything else while it is in the connection and receiving the notifications - such as actively scanning for more peripherals?[/quote]

It is all very standard, as I just slightly modified the example code for the heart rate that I've found in the repository.

At HW/FW level current setup is:

pc-ble-driver-py 0.15.0 (latest)
nRF52840 Dongle (PCA10059) running connectivity FW 4.1.2 SD API v5 (latest supported)

I believe there's no scanning active after the connection to the peripheral.
I'm calling this API:

self.adapter.driver.ble_gap_scan_start(scan_params=params)

Now wondering if this will keep scanning active even after I receive on_gap_evt_connected callback...

Well, please have a look - if you manage to get a generic example working I could compare your code with mine and check for differences (my script is less than 300 lines, not a big work)...

Thanks,

RE: pc-ble-driver-py missing high-rate notifications

Karl Ylvisaker — Mon, 02 Nov 2020 11:46:59 GMT

Looking closer at the connection length in both traces, it seems like it is set correctly - So I do not see any reason why the central on the one hand pulls for additional notifications, but not in the other ( as you can see in the trace _nok, the peripheral reports that more data is available, but the central never sends another packet to retrieve it ).

Could you tell me exactly how you have setup the dongle on your side to collect the notifications, so that I may try to replicate the issue here on my end?
Is the central doing anything else while it is in the connection and receiving the notifications - such as actively scanning for more peripherals?

Best regards,
Karl

RE: pc-ble-driver-py missing high-rate notifications

davege — Mon, 02 Nov 2020 11:46:50 GMT

Hello,

[quote userid="87869" url="~/f/nordic-q-a/67437/pc-ble-driver-py-missing-high-rate-notifications/278036#278036"]Looking at the traces in combination with your log, it seems that the missing notifications are in fact never sent ( such as the notification number 94 and 97 ).
For this, I am guessing that an error occured when you tried to queue these for sending using the sd_ble_gatts_hvx function. I suspect that these particular calls then returned NRF_ERROR_RESOURCES ( if this is the error you are still seeing ), and since they were not retried by the application they were never queued, and thus never sent. Does this sound plausible to you?[/quote]

Yes, this makes sense. I'm not handling that error with any kind of retry, so I'm expecting those numbers to never really being sent.

[quote userid="87869" url="~/f/nordic-q-a/67437/pc-ble-driver-py-missing-high-rate-notifications/278036#278036"]Looking at the logs, it is apparent that when the transmissions fail there is only 1 notifications being sent per connection event. This is probably causing a buildup, leading to the NRF_ERROR_RESOURCES error.
If you look at the log where it works as intended, there are almost always sent multiple notifications per event, which decreases the chance of a notification buildup on the server side.

What error handling have you implemented for the NRF_ERROR_RESOURCES error?[/quote]

So here's the point: I'm not trying to understand how to handle the error on the Server (this is something I will do for robustness anyway).
What I want to understand is why there's a different behaviour by the Client in the failing case.
If I got it correctly, in the failing log there is always up to 1 notification being sent per connection event.
Why is this the case? Is there any configuration on Client to side to avoid that? Could it be a limitation of the serialisation libraries initialisation of the PCA10059 dongle running on the laptop?

Since the problem is very easy to reproduce, I'd like to know from you if you're seeing the same...
You would just need to queue notifications at a rate higher than the connection interval (like in my case: 10ms vs 15ms) to be in the same situation.

Then someone in the dev team could debug what's happening in the lower layers...

How does it sound?

Thanks,

RE: pc-ble-driver-py missing high-rate notifications

Karl Ylvisaker — Mon, 02 Nov 2020 11:23:34 GMT

Hello again,

Sorry for my late reply.

[quote user="davege"]getting back to you with two traces over Wireshark:[/quote]

Thank you for the traces and their description, these are of great help for me to understand the issue better.

[quote user="davege"]To confirm that notifications are "lost" in the second case, I'm now printing in the python script the value of a counter that I set in the first byte of the notification.[/quote]

Looking at the traces in combination with your log, it seems that the missing notifications are in fact never sent ( such as the notification number 94 and 97 ).
For this, I am guessing that an error occured when you tried to queue these for sending using the sd_ble_gatts_hvx function. I suspect that these particular calls then returned NRF_ERROR_RESOURCES ( if this is the error you are still seeing ), and since they were not retried by the application they were never queued, and thus never sent. Does this sound plausible to you?

Looking at the logs, it is apparent that when the transmissions fail there is only 1 notifications being sent per connection event. This is probably causing a buildup, leading to the NRF_ERROR_RESOURCES error.
If you look at the log where it works as intended, there are almost always sent multiple notifications per event, which decreases the chance of a notification buildup on the server side.

What error handling have you implemented for the NRF_ERROR_RESOURCES error?

[quote user="davege"]

I also tried to increase the NRF_SDH_BLE_GAP_EVENT_LENGTH to 12 (15ms), but nothing changed.

I don't think that increasing that value above 15ms could make sense, since anyway that is the connection interval.

[/quote]

Great! This is correct - the event length is limited by the interval either way. You could set it to 500, it would be no change unless you also change the interval.

Looking forward to resolving this issue together!

Best regards,
Karl

RE: pc-ble-driver-py missing high-rate notifications

davege — Wed, 28 Oct 2020 22:38:40 GMT

Hello,

getting back to you with two traces over Wireshark:

one is a case when I'm not seeing any NRF_ERROR_RESOURCE error on the Server/Peripheral (my smartphone enabling notifications)
the other is instead the case of pc-ble-driver-py running from laptop through the connectivity dongle, with multiple error when calling the SD notification API.

To confirm that notifications are "lost" in the second case, I'm now printing in the python script the value of a counter that I set in the first byte of the notification.

I also tried to increase the NRF_SDH_BLE_GAP_EVENT_LENGTH to 12 (15ms), but nothing changed.

I don't think that increasing that value above 15ms could make sense, since anyway that is the connection interval.

I hope this may help in understanding the root cause of the issue.

Thanks and please keep me posted,

devzone.nordicsemi.com/.../dataReceived_5F00_notifmissing.txt devzone.nordicsemi.com/.../capture_5F00_nok.pcapng devzone.nordicsemi.com/.../capture_5F00_ok.pcapng

RE: pc-ble-driver-py missing high-rate notifications

Karl Ylvisaker — Tue, 27 Oct 2020 09:10:45 GMT

Hi,

[quote user="davege"]thanks for the follow-up.[/quote]

No problem at all, I am happy to help!

[quote user="davege"]

Interesting the role of the connection event length...I did not think about it.

At the moment, NRF_SDH_BLE_GAP_EVENT_LENGTH is set to 6 (so 7.5ms).

[/quote]

Could you try increasing this by a lot ( as a test ), to see if it then behaves as you inteded?

[quote user="davege"]But I want to reiterate again this: the same settings on the Server side are working fine when I'm notifying another Client device (typical example is the nRF Connect app running on the phone or even on Desktop with the same dongle!).[/quote]

Yes - I see now that I did not address this in your previous reply - this could very well be caused by the
Since it is the central that actually determines the connection parameters, and parameter negotiations, then it might very well be different when connected to different centrals.
Typically, smartphones have a very rigid set of rules for which connection parameters they allow - you may not set this as you please, when using the smartphones integrated BLE module. This differs from when you are using a central device that you have programmed yourself ( or nRF Connect for Desktop application ), since you may then set the parameters yourself, as you please.

This will be very easy to see in a sniffer trace, since the content of the connection request and parameter negotiation will be viewable.

[quote user="davege"]Tomorrow I'll try to capture a log of the connection between the two devices with the Sniffer.[/quote][quote user="davege"]Let me know if there's something in particular I should filter out, if not I'll dump one log for each of the cases (one presenting NRF_ERROR_RESOURCE error, the other without) to see the difference.[/quote]

Great, that should make the issue a lot easier to address. Please remember to select your device from the device menu, as shown in the included image, to make the sniffer follow into your connection. If you leave the option at the default ( as shown in the image ) then your sniffer will only listen for advertisements.

Do not filter anything else out - it is best if I get the unfiltered log. It does not matter if it is thousands of packets, as long as you mention which packets the issue is demonstrated in ( i.e " In the exchange starting at packet number .. and ending at packet number .. you can see the behavior ... ", or similar ).

Looking forward to resolving this issue together!

Best regards,
Karl