BLE Scan Interval and Scan Window

[zian31]

Hi.
In Qt QLowEnergyConnectionParameters Class, this function can change the scan interval :

setIntervalRange(double minimum, double maximum)

The actual value will be decided by the controller.
Both minimum and maximum are given in milliseconds.
The smallest possible connection interval is 7.5 milliseconds, the largest one is 4000 milliseconds.

It can be very interresting to add in parameters these min and max for scan interval (I don't find any QT function to change the scan window value) :

[emericg]

While I know about QLowEnergyConnectionParameters existence, at the moment I honestly know nothing about what it does or to what it applies. I'll take a look at if I can.
Also would it be useful to set that per connection or just as a global parameter?

[emericg]

You have it here only : [src/device.cpp]

Yes, and I even had this block of code in WatchFlower for a while now:

QLowEnergyConnectionParameters params;
params.setIntervalRange(30, 100);
params.setLatency(0);
params.setSupervisionTimeout(1000); // cannot be changed on Android and is therefore ignored
m_bleController->requestConnectionUpdate(params);

It's commented however, as I said I'm not entirely sure what it does. I think that it is mostly useful if we are creating a BLE peripheral, not connecting to one, but I might be wrong.

What is also not helping is that my Bluetooth is completely broken on my Linux computer, and has been for a while now. I don't even know if that's Linux fault (I know so few people using BLE on Linux that I can't even tell) if that's Qt fault (even fewer people), or if that's just something broken on my install.
But I can uncomment this code on toolBLEx and you can test if there is any change on your use cases?

[zian31]

Thanks ! If you can add these few lines and send me a new file toolBLEx.exe, I can test it. It would be better with : params.setIntervalRange(7.5, 10);
You can be true : it can also be for a BLE peripheral, I hope not.

I use Linux only on a Raspberry and lots of people use the BLE in that case.

PS : I think your software can become a reference : now lots of people are using Android NRFConnect because nothing was working better on a PC or a Raspberry for BLE connections, so that many people are using an emulator (VMWare) to launch NRFConnect on a PC.

[emericg]

I've put these lines in the software, you can download the window build here (once it finishes building) https://github.com/emericg/toolBLEx/actions/runs/6748947266

PS : I think your software can become a reference

Thanks. I created it for the same reasons, I don't want to use an Android app when I'm using a real computer all day long... Other than that, nRF Connect is a great tool.
And that being said, I can't come close to the amount of man power they have working on their software, so it is likely that nRF connect will stay the reference :)

[zian31]

Thanks, I've test the new version, and I don't find any differences in the Advertisement frames continuity (all is OK : byte counter are ok) for the moment.

But these Advertisement frames become blocked at one moment (due to frame parsing problem?) for different BLE periphericals. I have to close the software and reopen it (stop scan, restart scan don't solve the matter), but close-reopen software is not sloving this blocking each time : I think you will need Wireshark4 + Bluetooth Virtual Sniffer (btvs.exe) to debug it on Win10, install is clean and simple.

So it's possible than lost Advertisement frames and problem of parsing of Advertisement frames are linked.

Another strange behavior : when I close the software and reopen it, the same Advertisement frame (with same the byte counter) is shown, so there is a kind of memory of old frames.

Moreover, I'm wondering if the new parameters (new lines with params.setIntervalRange(7.5, 10)) launched inside the new .exe change the OS BLE parameters because the toolBLEx scanning seems to be faster now than before (but also with the old .exe, so that it can have been changed in the OS register, accessible with regedit ?

[zian31]

I don't find anything in the OS Win10 Register concerning these Bluetooth Scan Interval and Scan Window.

Here https://doc.qt.io/qt-6/qlowenergyconnectionparameters.html it's written :

The connection parameters influence how often a master and a slave device synchronize with each other. In general, a lower connection interval and latency means faster communication, but also higher power consumption. How these criteria should be weighed against each other is highly dependent on the concrete use case.

So it should be related to Bluetooth Scan Interval and Scan Window of the scanner and not the peripheral

But it's also written :

Android only indirectly permits the adjustment of this parameter set

So maybe it's only for Android ?

[emericg]

But these Advertisement frames become blocked at one moment

Did that problem appear with these changes, or is that unrelated?

Another strange behavior : when I close the software and reopen it, the same Advertisement frame (with same the byte counter) is shown, so there is a kind of memory of old frames.

That may not be a problem at all. BLE devices can send advertisement packets that are exactly the same, every couple of seconds. Like I said they are printed in the app only when changes are detected. This is a decision I made, otherwise it's easy to get spammed with hundreds of the same packet and fill the UI with it.
And there might also be a memory effect from the Bluetooth stacks but that is another problem entirely.

toolBLEx scanning seems to be faster now than before

From experience, the placebo effect can be strong when trying potential optimizations :) I myself didn't notice any change, but we'll keep looking.

[zian31]

First question : it's unrelated (same with your 2 software versions).

Second question : it's not the same frame every couple of seconds with my tests : there is a byte counter in these frames, so I think it shouldn't be possible to see same frames with same counter value with relauching the software : it seems that frames are memorised in a kind of cached memory ?

Other point : Maybe if same frames are reveived, you can add a special counter at the end with [counter value] ou (counter value) ? Or something else to indicate it ?

Lol for placebo effect, I think it can be true :)

With your new report tabs, I will be able to do more experiment with these adv frames, thanks !

PS: do you try [Wireshark4 + Bluetooth Virtual Sniffer] on Win10 ?