On Sun, 30 Sep 2018 at 01:41, Lubomir I. Ivanov <[email protected]> wrote: > > On Sun, 30 Sep 2018 at 01:14, Dirk Hohndel <[email protected]> wrote: > > > > > > > On Sep 29, 2018, at 3:07 PM, Lubomir I. Ivanov <[email protected]> > > > 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 -- _______________________________________________ subsurface mailing list [email protected] http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
