[TEST REQUEST] Windows Bluetooth LE build

Lubomir I. Ivanov neolit123 at gmail.com
Sat Sep 29 15:58:43 PDT 2018


On Sun, 30 Sep 2018 at 01:41, Lubomir I. Ivanov <neolit123 at gmail.com> wrote:
>
> On Sun, 30 Sep 2018 at 01:14, Dirk Hohndel <dirk at hohndel.org> wrote:
> >
> >
> > > On Sep 29, 2018, at 3:07 PM, Lubomir I. Ivanov <neolit123 at gmail.com> wrote:
> > >
> > >>
> > >> Interestingly enough, the two BLE dive computers I tried with are
> > >> both Shearwaters who AFAIK require random addresses. I don't
> > >> see, however, how that would cause the error pairing.
> > >>
> > >> The third one (Suunto EON Steel) I couldn't figure out how to even
> > >> pair with Windows 10...
> > >>
> > >> Still trying to figure out how to get the logging to work...
> > >>
> > >
> > >
> > > Dirk notice that Steve is being able to discover the device, but then
> > > fails to connect:
> > > (screenshot).
> > >
> > > from what i've understood on your end it fails finding the device in
> > > the list of BT(LE) devices nearby, so it fails in an earlier step?
> > >
> >
> > But Steve has a Petrel 2, right? And AFAIK the Petrel 2 will ALWAYS
> > switch to BT Classic if the computer supports that. So even though it
> > includes a BLE radio, that only seems to actually work when you connect
> > BLE only. And reading the sources I don't think that's what we do. We
> > seem to scan both at the same time.
> >
> > Actually, this is a part of the sources that REALLY puzzles me...
> >
> >     threadLE = new QThread;
> >     threadWorkerLE = new ThreadWorkerDeviceDiscovery;
> >     threadWorkerLE->moveToThread(threadLE);
> >     connect(threadWorkerLE, &ThreadWorkerDeviceDiscovery::discoveryCompleted, this, &QBluetoothDeviceDiscoveryAgentPrivate::completeLeDevicesDiscovery);
> >     connect(threadLE, &QThread::finished, threadWorkerLE, &ThreadWorkerDeviceDiscovery::deleteLater);
> >     connect(threadLE, &QThread::finished, threadLE, &QThread::deleteLater);
> >     threadLE->start();
> >
> >     threadClassic = new QThread;
> >     threadWorkerClassic = new ThreadWorkerDeviceDiscovery;
> >     threadWorkerClassic->moveToThread(threadClassic);
> >     connect(threadWorkerClassic, &ThreadWorkerDeviceDiscovery::discoveryCompleted, this, &QBluetoothDeviceDiscoveryAgentPrivate::completeClassicDevicesDiscovery);
> >     connect(threadClassic, &QThread::finished, threadWorkerClassic, &ThreadWorkerDeviceDiscovery::deleteLater);
> >     connect(threadClassic, &QThread::finished, threadClassic, &QThread::deleteLater);
> >     threadClassic->start();
> >
> > So this creates to ThreadWorkerDeviceDiscovery objects. How does the LE one know to scan for BLE only, and the Classic one to scan for Classic only?
> > I must be missing something obvious - but this just confuses me.
> >
>
> the BTLE and BT-classic in the Windows API have different discovery methods.
> while i contributed parts of the above code, the separable discovery
> was already in place.
>
> also the above code hasn't seen a lot of testing.
>
> but i don't think we are using QBluetoothDeviceDiscoveryAgent in our
> code on Windows, is that correct?
>
> looking at this i cannot figure out how the discovery on WIndows is happening:
> https://github.com/Subsurface-divelog/subsurface/blob/master/core/btdiscovery.cpp#L101
>

oh, our discovery seems to happen in the front end.
https://github.com/Subsurface-divelog/subsurface/blob/master/desktop-widgets/btdeviceselectiondialog.cpp

with the custom WinBluetoothDeviceDiscoveryAgent
i remembered now.
https://github.com/Subsurface-divelog/subsurface/blob/master/desktop-widgets/btdeviceselectiondialog.cpp#L605

so we are essentially doing:
"To facilitate the discovery of Bluetooth devices and services,
Windows maps the Bluetooth Service Discovery Protocol (SDP) onto the
Windows Sockets namespace interfaces."

the Qt stack on the other hand is doing:
- BluetoothFindFirst(Next)Device... for classic
- SetupDiEnumDeviceInterfaces for LE

i need to experiment if QBluetoothDeviceDiscoveryAgent works on
WIndows with this Qt branch, but the thing about our custom
WinBluetoothDeviceDiscoveryAgent is that it should just work too.

lubomir
--



lubomir
--


More information about the subsurface mailing list