pc-ble-driver v4.1.2: Bugfix question

[Franz]

Hi,

The release notes of v4.1.2 at https://github.com/NordicSemiconductor/pc-ble-driver/releases

mention the fix

"Fixed an issue where USB connectivity firmware hangs after receiving many notifications"

I could not find more details on this. Can anyone elaborate abuot what behaviour exactly was fixed here? We are sometimes seeing the problem of "lagging" data, i.e. notifications arrive late (with a long time delay) in python using 4.1.1. and the 0.14.2 pc-bledriver-py bindings. Could this be somehow related?

Thanks!

[Øyvind]

Hello, 

The developers in charge of pc-ble-driver are currently on vacation, and one must expect a slow response. I will forward your question and get back to you within this week. 

Kind regards,
Øyvind

[Øyvind]

Hello,

My apologies for the late reply. Our pc-ble-driver expert got back on Monday. He will provide me an answer as soon as possible. 

Kind regards,
Øyvind

[Øyvind]

Hello, 

Finally got an answer on the fix. The issue was too small app_scheduler queue size for USB transport. This is increased in the fix in v4.1.2.

Kind regards,
Øyvind

[Franz]

Ok, thanks! So that should NOT be related to the problems i observed. Can you maybe shortly check with your colleague if he/ she has an explanation for the behaviour i described in the question? We have a number of devices connected (e.g. 6 devices), that all deliver notifications to the nRF52840 dongle running the connectivity firmware. Data is collected in python. Sometimes, it seems like the driver is "slowing down". i.e.  notifications arrive late and the mean interval of notifications (about 3 notifications/s/device) is increasing. I am not sure on how to debug the cause for the increasing delay  -is there some "timestamping" in the driver layer which I could use?

[Øyvind]

Please try with the following answer from our expert:

One can get more extensive logging by setting the driver log level to trace. An example of this is the test_rssi.py test:
python test_rssi.py --port-a COM20 --port-b COM
16 --driver-log-level trace --log-level debug

The timestamps are output in the log.

Example output:

2020-08-18 10:59:55,010 [18692/LogThread] evt> severity(10) message( 20 -> [N/A] type: ACK re
liable: no seq#:0 ack#:0 payload_length:0 data_integrity:0 err_code:0x0)
2020-08-18 10:59:55,010 [18692/LogThread] 21 -> [00 88 00 00 00 00 ] type: VENDOR_SPECIFIC reliable:yes
seq#:4 ack#:0 payload_length:6 data_integrity:1 header_checksum:ce err_code:0x0
2020-08-18 10:59:55,010 [18692/LogThread] evt> severity(10) message( 21 -> [00 88 00 00 00 00 ] type: VEN
DOR_SPECIFIC reliable:yes seq#:4 ack#:0 payload_length:6 data_integrity:1 header_checksum:ce err_code:0x0)
2020-08-18 10:59:55,011 [18692/LogThread] 17/ 0 <- [N/A] type: ACK reliable: no seq#:0 ack#:5 p
ayload_length:0 data_integrity:0 err_code:0x0