RE: [TEST REQUEST] Windows Bluetooth LE build
Latest test binary:
http://subsurface-divelog.org/downloads/test/WINBLE-subsurface-4.8.3-12-g2952cd818617.exe
This basically removes all the Q_OS_WIN code and uses the Linux path for
Windows:
Emit: "DB:3B:75:83:D8:6E"
Starting download from BT
qt_ble_open( DB:3B:75:83:D8:6E )
connected to the controller for device DB:3B:75:83:D8:6E
.. discovering services
Found uuid: "{1800--1000-8000-00805f9b34fb}"
Found service "{1800--1000-8000-00805f9b34fb}"
.. created service object QLowEnergyService(0x777bf90)
Found uuid: "{1801--1000-8000-00805f9b34fb}"
Found service "{1801--1000-8000-00805f9b34fb}"
.. created service object QLowEnergyService(0x777bee8)
Found uuid: "{fe25c237-0ece-443c-b0aa-e02033e7029d}"
Found service "{fe25c237-0ece-443c-b0aa-e02033e7029d}"
.. created service object QLowEnergyService(0x777bde0)
.. done discovering services
Found service "{1800--1000-8000-00805f9b34fb}" "Generic Access"
Found service "{1801--1000-8000-00805f9b34fb}" "Generic Attribute"
Found service "{fe25c237-0ece-443c-b0aa-e02033e7029d}" "Unknown Service"
c: "{27b7570b-359e-45a3-91bb-cf7e70049bd2}"
d: "{2902--1000-8000-00805f9b34fb}"
d: "{2901--1000-8000-00805f9b34fb}"
Using service "{fe25c237-0ece-443c-b0aa-e02033e7029d}" as preferred service
.. enabling notifications
Using read characteristic "{27b7570b-359e-45a3-91bb-cf7e70049bd2}"
now writing "0x0100" to the descriptor "{2902--1000-8000-00805f9b34fb}"
QTime("22:52:48.325") packet SEND "0100ff010400228010c0"
QTime("22:52:48.325") packet WAIT
QTime("22:53:00.326") packet SEND "0100ff0105002e902000c0"
Deleting BLE object
Finishing download thread: "Dive data import error"
Looks great discovering services and stuff, but then we time out waiting for a
response (and the Teric stays in “CMD WAIT” state).
But we find the device and clearly SOME communication is happening.
Subsurface asks us to pair and if we try to pair that fails (the code was
hacked to still allow us to save that address). So my guess is that is where we
still have problems (and yes, the Windows 10 Bluetooth manager lists the Teric
as paired).
/D
From: Dirk Hohndel
Sent: Saturday, September 29, 2018 8:19 PM
To: Lubomir I. Ivanov
Cc: Subsurface Mailing List
Subject: RE: [TEST REQUEST] Windows Bluetooth LE build
Using the dreadful Windows Mail client… but hey, I get to copy and paste :-)
press to start discovery...
discovery started...
entering main loop...
qt.bluetooth.windows: Emit: "DB:3B:75:83:D8:6E"
discovery finished
enumerate devices
---
device # 0
addr: "DB:3B:75:83:D8:6E"
name: "Teric"
coreConfiguration: QFlags(0x1)
---
done enumerating devices
enter a device # to connect to:
0
connecting to device # 0 ; address: "DB:3B:75:83:D8:6E" ...
Unimplemented code.
controller state changed: QLowEnergyController::ControllerState(ConnectingState)
controller state changed: QLowEnergyController::ControllerState(ConnectedState)
I’d call this fully successful :-)
Nice work, Lubomir.
/D
From: Dirk Hohndel
Sent: Saturday, September 29, 2018 6:51 PM
To: Lubomir I. Ivanov
Cc: Subsurface Mailing List
Subject: Re: [TEST REQUEST] Windows Bluetooth LE build
> On Sep 29, 2018, at 6:28 PM, Lubomir I. Ivanov wrote:
>
> this is a minimal Qt application that includes BT device discovery.
>
> 1) it will first ask you to press enter to start
> make sure the BTLE devices are turned on / have battery.
> 2) it might take a while...
It sits there, nothing happens. Forever.
None of the below happens.
> 3) then it should dump a list of found devices each having a name and a #
> configuration legend (QFlags...):
> - 0x0 -> unknown type
> - 0x1 -> BTLE
> - 0x2 -> BT classic
> - 0x3 -> BT smart (can be either BT or BTLE)
> http://doc.qt.io/qt-5/qbluetoothdeviceinfo.html#CoreConfiguration-enum
> 4) in the console pick a # (e.g. 2) and press enter
> 5) it would then try to connect to the device.
> if it succeeds it should print out "ConnectedState", if it fails it
> should print something else.
>
> please try your BTLE DCs and report the results.
>
> this is a mandatory step if we want to continue with our improvements
> and it will narrow our guessing game.
>
> thanks.
> lubomir
> --
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
RE: [TEST REQUEST] Windows Bluetooth LE build
Using the dreadful Windows Mail client… but hey, I get to copy and paste :-) press to start discovery... discovery started... entering main loop... qt.bluetooth.windows: Emit: "DB:3B:75:83:D8:6E" discovery finished enumerate devices --- device # 0 addr: "DB:3B:75:83:D8:6E" name: "Teric" coreConfiguration: QFlags(0x1) --- done enumerating devices enter a device # to connect to: 0 connecting to device # 0 ; address: "DB:3B:75:83:D8:6E" ... Unimplemented code. controller state changed: QLowEnergyController::ControllerState(ConnectingState) controller state changed: QLowEnergyController::ControllerState(ConnectedState) I’d call this fully successful :-) Nice work, Lubomir. /D From: Dirk Hohndel Sent: Saturday, September 29, 2018 6:51 PM To: Lubomir I. Ivanov Cc: Subsurface Mailing List Subject: Re: [TEST REQUEST] Windows Bluetooth LE build > On Sep 29, 2018, at 6:28 PM, Lubomir I. Ivanov wrote: > > this is a minimal Qt application that includes BT device discovery. > > 1) it will first ask you to press enter to start > make sure the BTLE devices are turned on / have battery. > 2) it might take a while... It sits there, nothing happens. Forever. None of the below happens. > 3) then it should dump a list of found devices each having a name and a # > configuration legend (QFlags...): > - 0x0 -> unknown type > - 0x1 -> BTLE > - 0x2 -> BT classic > - 0x3 -> BT smart (can be either BT or BTLE) > http://doc.qt.io/qt-5/qbluetoothdeviceinfo.html#CoreConfiguration-enum > 4) in the console pick a # (e.g. 2) and press enter > 5) it would then try to connect to the device. > if it succeeds it should print out "ConnectedState", if it fails it > should print something else. > > please try your BTLE DCs and report the results. > > this is a mandatory step if we want to continue with our improvements > and it will narrow our guessing game. > > thanks. > lubomir > -- ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [TEST REQUEST] Windows Bluetooth LE build
> On Sep 29, 2018, at 6:28 PM, Lubomir I. Ivanov wrote: > > this is a minimal Qt application that includes BT device discovery. > > 1) it will first ask you to press enter to start > make sure the BTLE devices are turned on / have battery. > 2) it might take a while... It sits there, nothing happens. Forever. None of the below happens. > 3) then it should dump a list of found devices each having a name and a # > configuration legend (QFlags...): > - 0x0 -> unknown type > - 0x1 -> BTLE > - 0x2 -> BT classic > - 0x3 -> BT smart (can be either BT or BTLE) > http://doc.qt.io/qt-5/qbluetoothdeviceinfo.html#CoreConfiguration-enum > 4) in the console pick a # (e.g. 2) and press enter > 5) it would then try to connect to the device. > if it succeeds it should print out "ConnectedState", if it fails it > should print something else. > > please try your BTLE DCs and report the results. > > this is a mandatory step if we want to continue with our improvements > and it will narrow our guessing game. > > thanks. > lubomir > -- ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [TEST REQUEST] Windows Bluetooth LE build
On Sun, 30 Sep 2018 at 04:40, Dirk Hohndel wrote: > > > > On Sep 29, 2018, at 3:58 PM, Lubomir I. Ivanov wrote: > > 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 > > Correct. And that's where we hard code the PowerOff error, btw. > > I have now added a new version that prints the actual error... > > WSALookupServiceBegin results in "No such service is known. The service > cannot be found in the specified name space" > Which is the error string for WSASERVICE_NOT_FOUND > "This error is returned for a bluetooth service discovery request if no > remote bluetooth devices were found." > > And that makes sense because no BT devices were on. But what about my BLE > devices??? I have tons of them. > > But I think this is pointing me in the right direction. Next step: improve > our error and debug messages :-) > the discovery in the latest Qt win/wip branch works for me. it detects my devices and guesses their types. i can connect to the DC device too. if the small app that i just posted works for you we can just replace the WSA (WinBluetoothDeviceDiscoveryAgent) usage with the QBluetoothDeviceDiscoveryAgent from Qt. lubomir -- ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [TEST REQUEST] Windows Bluetooth LE build
> On Sep 29, 2018, at 3:58 PM, Lubomir I. Ivanov wrote: > 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 Correct. And that's where we hard code the PowerOff error, btw. I have now added a new version that prints the actual error... WSALookupServiceBegin results in "No such service is known. The service cannot be found in the specified name space" Which is the error string for WSASERVICE_NOT_FOUND "This error is returned for a bluetooth service discovery request if no remote bluetooth devices were found." And that makes sense because no BT devices were on. But what about my BLE devices??? I have tons of them. But I think this is pointing me in the right direction. Next step: improve our error and debug messages :-) /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [TEST REQUEST] Windows Bluetooth LE build
On Sun, 30 Sep 2018 at 04:34, Dirk Hohndel wrote: > > > > On Sep 29, 2018, at 6:28 PM, Lubomir I. Ivanov wrote: > > > > could you please download the following zip when you have a minute: > > https://www.dropbox.com/s/dem58v91bk6qcjj/qt-bt-discovery.zip?dl=0 > > > sorry, copy pasted a WIP link. here is the actual one: https://www.dropbox.com/s/ehkoklydtnrvzxg/_qt-bt-discovery.zip?dl=0 lubomir -- ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [TEST REQUEST] Windows Bluetooth LE build
> On Sep 29, 2018, at 6:28 PM, Lubomir I. Ivanov wrote: > > could you please download the following zip when you have a minute: > https://www.dropbox.com/s/dem58v91bk6qcjj/qt-bt-discovery.zip?dl=0 > I get a 404 with that link /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [TEST REQUEST] Windows Bluetooth LE build
On Sun, 30 Sep 2018 at 01:14, Dirk Hohndel wrote: > > > > On Sep 29, 2018, at 3:07 PM, Lubomir I. Ivanov 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); > > Dirk, Steve and et al. could you please download the following zip when you have a minute: https://www.dropbox.com/s/dem58v91bk6qcjj/qt-bt-discovery.zip?dl=0 this is a minimal Qt application that includes BT device discovery. 1) it will first ask you to press enter to start make sure the BTLE devices are turned on / have battery. 2) it might take a while... 3) then it should dump a list of found devices each having a name and a # configuration legend (QFlags...): - 0x0 -> unknown type - 0x1 -> BTLE - 0x2 -> BT classic - 0x3 -> BT smart (can be either BT or BTLE) http://doc.qt.io/qt-5/qbluetoothdeviceinfo.html#CoreConfiguration-enum 4) in the console pick a # (e.g. 2) and press enter 5) it would then try to connect to the device. if it succeeds it should print out "ConnectedState", if it fails it should print something else. please try your BTLE DCs and report the results. this is a mandatory step if we want to continue with our improvements and it will narrow our guessing game. thanks. lubomir -- ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [TEST REQUEST] Windows Bluetooth LE build
On Sun, 30 Sep 2018 at 01:14, Dirk Hohndel wrote: > > > > On Sep 29, 2018, at 3:07 PM, Lubomir I. Ivanov 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, ::discoveryCompleted, > this, ::completeLeDevicesDiscovery); > connect(threadLE, ::finished, threadWorkerLE, > ::deleteLater); > connect(threadLE, ::finished, threadLE, ::deleteLater); > threadLE->start(); > > threadClassic = new QThread; > threadWorkerClassic = new ThreadWorkerDeviceDiscovery; > threadWorkerClassic->moveToThread(threadClassic); > connect(threadWorkerClassic, > ::discoveryCompleted, this, > ::completeClassicDevicesDiscovery); > connect(threadClassic, ::finished, threadWorkerClassic, > ::deleteLater); > connect(threadClassic, ::finished, threadClassic, > ::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 lubomir -- ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [TEST REQUEST] Windows Bluetooth LE build
On Sat, Sep 29, 2018 at 3:26 PM Dirk Hohndel wrote: > > But I do care about the Perdix AI and the Teric, because BLE is the only > way to download from them... Oh, agreed. And it might indeed be about that random address thing, for all we know. It *is* one of the things that is special about the Perdix (not that Shearwater is alone about it, as shown by the Garmin doing the same thing. Linus ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [TEST REQUEST] Windows Bluetooth LE build
> On Sep 29, 2018, at 3:23 PM, Linus Torvalds > wrote: > >> The third one (Suunto EON Steel) I couldn't figure out how to even >> pair with Windows 10... > > Yes, the EON Steel and Core are hard to pair to begin with. It's black > magic under Linux too, you need to do special things with bluetoothctl > to just _see_ it when scanning, and even then you need to actually > enable device privacy for the pairing to work. > > Suunto very clearly didn't want people to pair with the EON Steel/Core > manually, and they don't support BLE at all on their desktop > application. You're supposed to use the USB cable for downloads on the > desktop. It seems entirely intentional. And frankly... I don't really care if we don't support those two with BLE under Windows because they DO come with the USB cable and that is SO MUCH faster anyway. It works under iOS and Android as BLE device and that's what really matters. Anybody on Windows can just use USB. But I do care about the Perdix AI and the Teric, because BLE is the only way to download from them... /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [TEST REQUEST] Windows Bluetooth LE build
On Sat, Sep 29, 2018 at 3:03 PM Dirk Hohndel 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. Yeah, the pairing should work at the Windows side, but then if we don't use the proper random address to connect to the device inside subsurface, we'll never connect. That said, I really think it's a Bluez-only thing where you need to have the right "random address" bit when connecting. Afaik nobody else does that, and it really is a misfeature in Bluez that it requires it. So I *think* it should be a non-issue for Windows, and there is something else going on. > The third one (Suunto EON Steel) I couldn't figure out how to even > pair with Windows 10... Yes, the EON Steel and Core are hard to pair to begin with. It's black magic under Linux too, you need to do special things with bluetoothctl to just _see_ it when scanning, and even then you need to actually enable device privacy for the pairing to work. Suunto very clearly didn't want people to pair with the EON Steel/Core manually, and they don't support BLE at all on their desktop application. You're supposed to use the USB cable for downloads on the desktop. It seems entirely intentional. Linus ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [TEST REQUEST] Windows Bluetooth LE build
On Sun, 30 Sep 2018 at 00:07, Steve wrote: > Steve, if you have a minute could you please test this installer again (the link is the same): https://www.dropbox.com/s/zslq3ughx9ciehj/_deploy_win32_ble.zip?dl=0 has a minor update. this is just a shot in the dark but it disables explicit random addresses on Windows for the Petrel. thanks lubomir -- ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [TEST REQUEST] Windows Bluetooth LE build
> On Sep 29, 2018, at 2:57 PM, Linus Torvalds > wrote: > > On Sat, Sep 29, 2018 at 2:47 PM Lubomir I. Ivanov wrote: >> >> random addresses should not be used on Win32. > > Afaik, the dive computers that need random addresses will simply not > respond to the static ones. > > It's not a "choice" you can make. It's the other end that says that > they need a random address. > > Now, it's possible that Windows does the selection automatically > (that's how it *should* work, and Bluez is being stupid about it), but > then it shouldn't matter whether you set the random address bit or > not. 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... /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [TEST REQUEST] Windows Bluetooth LE build
On Sun, 30 Sep 2018 at 00:57, Linus Torvalds wrote: > > On Sat, Sep 29, 2018 at 2:47 PM Lubomir I. Ivanov wrote: > > > > random addresses should not be used on Win32. > > Afaik, the dive computers that need random addresses will simply not > respond to the static ones. > > It's not a "choice" you can make. It's the other end that says that > they need a random address. > > Now, it's possible that Windows does the selection automatically > (that's how it *should* work, and Bluez is being stupid about it), but > then it shouldn't matter whether you set the random address bit or > not. > my suspicion was by raised by the earlier report by Steve, where i saw: > qt_ble_open( 00:13:43:0D:DB:D4 ) > "The system cannot find the path specified." > failed to connect to the controller 00:13:43:0D:DB:D4 with error "Remote > device cannot be found" https://github.com/Subsurface-divelog/subsurface/blob/master/core/qt-ble.cpp#L406-L412 between our `qt_ble_open()` written to `stdout` and the `controller->connectToDevice();` we only have the `use_random_address()` which would result in true for Petrel. so we might want to wrap that in #if define() for Windows just to test it and be sure. of course, the alternative here is that the address is wrong. lubomir -- ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [TEST REQUEST] Windows Bluetooth LE build
On Sat, Sep 29, 2018 at 2:47 PM Lubomir I. Ivanov wrote: > > random addresses should not be used on Win32. Afaik, the dive computers that need random addresses will simply not respond to the static ones. It's not a "choice" you can make. It's the other end that says that they need a random address. Now, it's possible that Windows does the selection automatically (that's how it *should* work, and Bluez is being stupid about it), but then it shouldn't matter whether you set the random address bit or not. Linus ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [TEST REQUEST] Windows Bluetooth LE build
On Sun, 30 Sep 2018 at 00:47, Lubomir I. Ivanov wrote: > > On Sun, 30 Sep 2018 at 00:43, Dirk Hohndel wrote: > > > > > > > On Sep 29, 2018, at 2:29 PM, Lubomir I. Ivanov > > > wrote: > > >> > > >> Subsurface v4.8.2-74-g110fbbf7dbb3, > > >> built with libdivecomputer v0.7.0 > > >> built with Qt Version 5.9.5, runtime from Qt Version 5.10.1 > > > > So these tests are still with an older binary. Would it make sense > > to start testing with newer binaries? > > > > http://subsurface-divelog.org/downloads/test/WINBLE-subsurface-4.8.3-6-g4486c66f498a.exe > > > > I tried to enable the BLE discovery logging, but that didn't quite work, it > > seems. > > You mentioned that this needs a debug build (which doesn't appear to be the > > case on other OSs)... > > so this will need more tinkering :-/ > > > > i'm seeing one problem with our source code. this should be wrapped in: > > #if !defined(Q_OS_WIN) > ... > #endif > > https://github.com/Subsurface-divelog/subsurface/blob/master/core/qt-ble.cpp#L408-L409 > > random addresses should not be used on Win32. > but it feels like the function is a NOP on Windows, we need to test if that's the case by disabling it: http://doc.qt.io/qt-5/qlowenergycontroller.html#setRemoteAddressType lubomir -- ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [TEST REQUEST] Windows Bluetooth LE build
On Sat, Sep 29, 2018 at 2:25 PM Steve wrote:
>
> Ok another test but this time even though I paired with Windows settings
> properly twice and it said it was setup it looked to me as if it was not
> paired correctly so I tried with Bluetooth LE Explorer and paired with that
> (as I did for the OSTC3+) and this time it looks better but still not working.
This actually looks fine:
> Found service "{1800--1000-8000-00805f9b34fb}" "Generic Access"
>c: "{2a00--1000-8000-00805f9b34fb}"
>c: "{2a01--1000-8000-00805f9b34fb}"
> Found service "{180a--1000-8000-00805f9b34fb}" "Device Information"
>c: "{2a29--1000-8000-00805f9b34fb}"
> Found service "{fe25c237-0ece-443c-b0aa-e02033e7029d}" "Unknown Service"
>c: "{27b7570b-359e-45a3-91bb-cf7e70049bd2}"
> d: "{2901--1000-8000-00805f9b34fb}"
> d: "{2902--1000-8000-00805f9b34fb}"
It has discovered the LE GATT services..
> .. ignoring standard service "{1800--1000-8000-00805f9b34fb}"
> .. ignoring standard service "{180a--1000-8000-00805f9b34fb}"
> Using service "{fe25c237-0ece-443c-b0aa-e02033e7029d}" as preferred service
and it picked the usual non-standard one, which is correct for Petrel.
> .. enabling notifications
> Using read characteristic "{27b7570b-359e-45a3-91bb-cf7e70049bd2}"
> now writing "0x0100" to the descriptor
> "{2902--1000-8000-00805f9b34fb}"
And it has enabled notifications on the right descriptor.
> INFO: dc_device_open error value of 0
> QTime("06:47:20.208") packet SEND "0100ff0105002e902000c0"
Now it sends the 2e:90:20:00 command (the rest is header and the END byte)
But the above is the "device close" command. It never sent anything else.
In other words: the above looks 100% correct, with no errors anywhere,
but there's not even an attempt at IO.
Your libdivecomputer log-file backs that up. All it does is open it
successfully, and send the end command. Very odd.
Strange.
Linus
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [TEST REQUEST] Windows Bluetooth LE build
On Sun, 30 Sep 2018 at 00:43, Dirk Hohndel wrote: > > > > On Sep 29, 2018, at 2:29 PM, Lubomir I. Ivanov wrote: > >> > >> Subsurface v4.8.2-74-g110fbbf7dbb3, > >> built with libdivecomputer v0.7.0 > >> built with Qt Version 5.9.5, runtime from Qt Version 5.10.1 > > So these tests are still with an older binary. Would it make sense > to start testing with newer binaries? > > http://subsurface-divelog.org/downloads/test/WINBLE-subsurface-4.8.3-6-g4486c66f498a.exe > > I tried to enable the BLE discovery logging, but that didn't quite work, it > seems. > You mentioned that this needs a debug build (which doesn't appear to be the > case on other OSs)... > so this will need more tinkering :-/ > i'm seeing one problem with our source code. this should be wrapped in: #if !defined(Q_OS_WIN) ... #endif https://github.com/Subsurface-divelog/subsurface/blob/master/core/qt-ble.cpp#L408-L409 random addresses should not be used on Win32. lubomir -- ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [TEST REQUEST] Windows Bluetooth LE build
> On Sep 29, 2018, at 2:29 PM, Lubomir I. Ivanov wrote: >> >> Subsurface v4.8.2-74-g110fbbf7dbb3, >> built with libdivecomputer v0.7.0 >> built with Qt Version 5.9.5, runtime from Qt Version 5.10.1 So these tests are still with an older binary. Would it make sense to start testing with newer binaries? http://subsurface-divelog.org/downloads/test/WINBLE-subsurface-4.8.3-6-g4486c66f498a.exe I tried to enable the BLE discovery logging, but that didn't quite work, it seems. You mentioned that this needs a debug build (which doesn't appear to be the case on other OSs)... so this will need more tinkering :-/ /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [TEST REQUEST] Windows Bluetooth LE build
On Sun, 30 Sep 2018 at 00:25, Steve wrote:
>
> Ok another test but this time even though I paired with Windows settings
> properly twice and it said it was setup it looked to me as if it was not
> paired correctly so I tried with Bluetooth LE Explorer and paired with that
> (as I did for the OSTC3+) and this time it looks better but still not working.
> See attached screenshot and log files.
>
from my experience if i paired within BLE Explorer and then tried to
use Subsurface it would not work as the service path is already used
by another process.
> Output:
>
> Subsurface v4.8.2-74-g110fbbf7dbb3,
> built with libdivecomputer v0.7.0
> built with Qt Version 5.9.5, runtime from Qt Version 5.10.1
> built with libgit2 0.23.0
> can't find Subsurface localization for locale "en-US"
> Plugins Directory: QDir(
> "D:/Documents/Diving/Software/subsurface/_deploy_win32_ble/_deploy_win32_ble/plugins"
> , nameFilters = { "*" }, QDir::SortFlags( Name | IgnoreCase ) ,
> QDir::Filters( Dirs|Files|Drives|AllEntries ) )
> QPixmap::scaleHeight: Pixmap is a null pixmap
> QPixmap::scaleHeight: Pixmap is a null pixmap
> QPixmap::scaleHeight: Pixmap is a null pixmap
> QPixmap::scaleHeight: Pixmap is a null pixmap
> Set the current dive site: 0
> Set the current dive site: 0
>
> File locations:
>
> cloud URL set as
> "https://cloud.subsurface-divelog.org//git/stevewilli...@internode.on.net[stevewilli...@internode.on.net];
> Local git storage:
> C:\Users\steve\AppData\Roaming\Subsurface/cloudstorage/f419375139b19f7f
> Cloud URL:
> https://cloud.subsurface-divelog.org//git/stevewilli...@internode.on.net[stevewilli...@internode.on.net]
> Image filename table: C:\Users\steve\AppData\Roaming\Subsurface/hashes
> Local picture directory:
> C:\Users\steve\AppData\Roaming\Subsurface/picturedata/
>
> QPixmap::scaleHeight: Pixmap is a null pixmap
> Starting download from BT
> Unimplemented code.
> qt_ble_open( 00:13:43:0D:DB:D4 )
> connected to the controller for device 00:13:43:0D:DB:D4
> .. discovering services
> Found uuid: "{1800--1000-8000-00805f9b34fb}"
> Found service "{1800--1000-8000-00805f9b34fb}"
> .. created service object QLowEnergyService(0x9074100)
> Found uuid: "{180a--1000-8000-00805f9b34fb}"
> Found service "{180a--1000-8000-00805f9b34fb}"
> .. created service object QLowEnergyService(0x90743d0)
> Found uuid: "{fe25c237-0ece-443c-b0aa-e02033e7029d}"
> Found service "{fe25c237-0ece-443c-b0aa-e02033e7029d}"
> .. created service object QLowEnergyService(0x9076110)
> Unable to get value for characteristic
> "{27b7570b-359e-45a3-91bb-cf7e70049bd2}" of the service
> "{fe25c237-0ece-443c-b0aa-e02033e7029d}" : "No attribute found within the
> given attribute handle range."
> .. done discovering services
> Found service "{1800--1000-8000-00805f9b34fb}" "Generic Access"
>c: "{2a00--1000-8000-00805f9b34fb}"
>c: "{2a01--1000-8000-00805f9b34fb}"
> Found service "{180a--1000-8000-00805f9b34fb}" "Device Information"
>c: "{2a29--1000-8000-00805f9b34fb}"
> Found service "{fe25c237-0ece-443c-b0aa-e02033e7029d}" "Unknown Service"
>c: "{27b7570b-359e-45a3-91bb-cf7e70049bd2}"
> d: "{2901--1000-8000-00805f9b34fb}"
> d: "{2902--1000-8000-00805f9b34fb}"
> .. ignoring standard service "{1800--1000-8000-00805f9b34fb}"
> .. ignoring standard service "{180a--1000-8000-00805f9b34fb}"
> Using service "{fe25c237-0ece-443c-b0aa-e02033e7029d}" as preferred service
> .. enabling notifications
> Using read characteristic "{27b7570b-359e-45a3-91bb-cf7e70049bd2}"
> now writing "0x0100" to the descriptor
> "{2902--1000-8000-00805f9b34fb}"
> INFO: dc_device_open error value of 0
> QTime("06:46:35.874") packet SEND "0100ff0105002e902000c0"
> Deleting BLE object
> Finishing download thread: "Dive data import error"
> Set the current dive site: 0
> Set the current dive site: 0
> Starting download from BT
> Unimplemented code.
> qt_ble_open( 00:13:43:0D:DB:D4 )
> connected to the controller for device 00:13:43:0D:DB:D4
> .. discovering services
> Found uuid: "{1800--1000-8000-00805f9b34fb}"
> Found service "{1800--1000-8000-00805f9b34fb}"
> .. created service object QLowEnergyService(0x90761b8)
> Found uuid: "{180a--1000-8000-00805f9b34fb}"
> Found service "{180a--1000-8000-00805f9b34fb}"
> .. created service object QLowEnergyService(0x9076218)
> Found uuid: "{fe25c237-0ece-443c-b0aa-e02033e7029d}"
> Found service "{fe25c237-0ece-443c-b0aa-e02033e7029d}"
> .. created service object QLowEnergyService(0x90765f0)
> Unable to get value for characteristic
> "{27b7570b-359e-45a3-91bb-cf7e70049bd2}" of the service
> "{fe25c237-0ece-443c-b0aa-e02033e7029d}" : "No attribute found within the
> given attribute handle range."
> .. done discovering services
> Found service "{1800--1000-8000-00805f9b34fb}" "Generic Access"
>c:
Re: [TEST REQUEST] Windows Bluetooth LE build
On Sun, 30 Sep 2018 at 00:07, Steve wrote:
>
> I found a minute to test with the petrel2 and could not get it to work.
> I also deleted the pairing with the pc and re-paired without success.
> See attached screenshot and log files.
> I don't have a lot of time to test for till Tuesday but might be able to do a
> little before then.
>
> Output:
>
> Subsurface v4.8.2-74-g110fbbf7dbb3,
> built with libdivecomputer v0.7.0
> built with Qt Version 5.9.5, runtime from Qt Version 5.10.1
> built with libgit2 0.23.0
> can't find Subsurface localization for locale "en-US"
> Plugins Directory: QDir(
> "D:/Documents/Diving/Software/subsurface/_deploy_win32_ble/_deploy_win32_ble/plugins"
> , nameFilters = { "*" }, QDir::SortFlags( Name | IgnoreCase ) ,
> QDir::Filters( Dirs|Files|Drives|AllEntries ) )
> QPixmap::scaleHeight: Pixmap is a null pixmap
> QPixmap::scaleHeight: Pixmap is a null pixmap
> QPixmap::scaleHeight: Pixmap is a null pixmap
> QPixmap::scaleHeight: Pixmap is a null pixmap
> Set the current dive site: 0
> Set the current dive site: 0
>
> File locations:
>
> cloud URL set as
> "https://cloud.subsurface-divelog.org//git/stevewilli...@internode.on.net[stevewilli...@internode.on.net];
> Local git storage:
> C:\Users\steve\AppData\Roaming\Subsurface/cloudstorage/f419375139b19f7f
> Cloud URL:
> https://cloud.subsurface-divelog.org//git/stevewilli...@internode.on.net[stevewilli...@internode.on.net]
> Image filename table: C:\Users\steve\AppData\Roaming\Subsurface/hashes
> Local picture directory:
> C:\Users\steve\AppData\Roaming\Subsurface/picturedata/
>
> QPixmap::scaleHeight: Pixmap is a null pixmap
> Starting download from BT
> Unimplemented code.
> qt_ble_open( 00:13:43:0D:DB:D4 )
> "The system cannot find the path specified."
> failed to connect to the controller 00:13:43:0D:DB:D4 with error "Remote
> device cannot be found"
> Finishing download thread: "Unable to open LE:00:13:43:0D:DB:D4 Shearwater
> (Petrel 2)"
> QPixmap::scaleHeight: Pixmap is a null pixmap
> Set the current dive site: 0
> Set the current dive site: 0
> QPixmap::scaleHeight: Pixmap is a null pixmap
> QPixmap::scaleHeight: Pixmap is a null pixmap
> Starting download from BT
> Unimplemented code.
> qt_ble_open( 00:13:43:0D:DB:D4 )
> "The system cannot find the path specified."
> failed to connect to the controller 00:13:43:0D:DB:D4 with error "Remote
> device cannot be found"
> Finishing download thread: "Unable to open LE:00:13:43:0D:DB:D4 Shearwater
> (Petrel 2)"
> Set the current dive site: 0
> Set the current dive site: 0
> QPixmap::scaleHeight: Pixmap is a null pixmap
> QPixmap::scaleHeight: Pixmap is a null pixmap
> QPixmap::scaleHeight: Pixmap is a null pixmap
> Press any key to continue . . .
>
thanks for testing the Petrel too, Steve!
i will have a look at the results.
lubomir
--
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [TEST REQUEST] Windows Bluetooth LE build
> On Sep 29, 2018, at 1:30 PM, Lubomir I. Ivanov wrote: > if such a helper is to be built: > - it has to be built using the Windows SDK and MSVC as standalone app > and not as a library. > - if we get it to work with an older dot-net version it's going to be > OK, if not we need to force users to update their dot-net setup before > using and if we don't want to redistribute the whole target dot-net. > - given it cannot be built using MINGW, we need to create something > like a TCP Socket protocol to make Subsurface communicate with the > helper app. > > i'm not sure i'm liking where this is going. > given the OSTC+ already works, i'd prefer if can we find another solution. > Yeah, I agree. /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [TEST REQUEST] Windows Bluetooth LE build
> On Sep 29, 2018, at 1:24 PM, Lubomir I. Ivanov wrote:
>>
>> In the meantime, I completed a compile of Qt 5.11.2 from source, added
>> your wip/win qtconnectivity and did a make install to make sure that ALL
>> of the files are copied to the right place.
>>
>> I created an installer from that (which is missing FB, printing, user manual,
>> and apparently for some reason even the maps). You can find it on our website
>> as
>> http://subsurface-divelog.org/downloads/test/subsurface-4.8.2-92-gb05b8de05966.exe
>>
>
> do i need to test this installer, given it already worked with -91?
Well, the difference is that this is now all Qt 5.11 based, but you are right,
not much incremental value in you testing that...
> also TMK the -91 would have all the above modules that -92 is missing?
> why do we need to upgrade to 5.11.2?
We don't. I was hoping this would help with BLE, but it didn't.
>> I then purchased a new copy of Windows 10 (the things we do for our
>> hobbies) and installed it on the same laptop that I do my "on hardware"
>> Linux testing on.
>>
>> I paired the Teric with Windows (no problem there at all, found it right
>> away).
>>
>> So now we have:
>> - different laptop
>> - different BT device (this is a USB dongle, other one was built in)
>> - different Windows 10 install
>> - NO anti virus, anything
>>
>> Still the exact same experience in Subsurface
>> Regardless if I select Auto or Force LE, I get the Device discovery error.
>> And I get it fairly quickly.
>>
>> If I put my BT-classic-only Petrel in BT mode, it gets detected within a
>> second or two, and I can immediately download from it (without having
>> to do any pairing first).
>>
>> So BT works, but somehow the BLE scan results in an error.
>>
>
> we might have a lurking bug in our discovery code.
> i need to have a detailed look at it.
I think so.
>> You know the code much better than I do... in the scan path, what can
>> create such an error? One thing that is odd about my office is that I can
>> see more than a dozen BLE devices here on a regular scan. I wonder
>> if one of the unpaired ones is causing this behavior. But give then need
>> to pair first for BLE, that does seem unlikely, doesn't it?
>
> as mentioned multiple times the Windows discovery and device
> enumeration is super shaky.
> i don't have other devices in my room and the detection works fine.
>
> please bring this problem device to Sofia.
I'm bringing you one of them :-)
>> Is there a way to get more debug info from the Qt BLE code to see WHY
>> it created that error?
>>
>
> if QtConnectivity is built in debug mode and if you can try moving
> this from qt-ble.cpp
> QLoggingCategory::setFilterRules(QStringLiteral("qt.bluetooth* = true"));
>
> to btdiscovery.cpp, it might output are better detailed message.
I'll play with that.
> i only got the error if i completely disabled BT from control planel.
> hard to say, will have another look.
>
>> My plan for 4.8.3 is to switch back to my previous MXE setup so we have
>> working Windows binaries with all components (but not BLE). But I really
>> want to push on this BLE story. It feels like we are SO CLOSE.
>>
>
> given it works for me and Steven, it really feels like an isolated error.
> is there are change we can announce -91 for testing so that we can
> gather more feedback?
>
> it feels like my installer is not reaching out to people.
Let me try to add more debug output and then I'll create a new
installer for people to test with.
Thanks
/D
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Subsurface 4.8.3 and Subsurface-mobile 2.1.4 have been released
Hi everyone, Yeah, this was a bit of a rush job, but I think it worked out well. Sources and tags are pushed, including tar balls. The binaries are all up, including for the first time Ubuntu Cosmic (18.10) packages. The mobile app updates have been submitted, but haven't made it to the respective app stores, yet. Announcements are posted on our website and on Facebook (you know the drill: please like and share - the more of you do that, the more people get to see the post - FB is really strange in how even people who follow our page don't see the post unless a certain number of people "interact" with the post...) An extra thanks to the translators who stepped up and added quite a few strings with nearly no warning. And once again we even have the announcement already translated in Dutch, German, Portuguese and Spanish! More translations are always welcome! Please keep the pull requests coming. I think the project is doing remarkably well these days... Thanks /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [TEST REQUEST] Windows Bluetooth LE build
On Sat, 29 Sep 2018 at 20:26, Dirk Hohndel wrote: > > > > On Sep 28, 2018, at 8:19 PM, Lubomir I. Ivanov wrote: > > > > i can investigate their binary a little. > > we also have the option to just ask them - are they friendly? > > They are VERY friendly. I'll reach out to them. yes, after finding it's C# i don't have any immediate questions. > But as you mentioned, their's is > a C# app, so things might be different there. > Can we write a C# helper and pass the information to our app? > > this is not that easy. we spoke about a similar scenario when the Win32 discussions started with Alex about UWP. if such a helper is to be built: - it has to be built using the Windows SDK and MSVC as standalone app and not as a library. - if we get it to work with an older dot-net version it's going to be OK, if not we need to force users to update their dot-net setup before using and if we don't want to redistribute the whole target dot-net. - given it cannot be built using MINGW, we need to create something like a TCP Socket protocol to make Subsurface communicate with the helper app. i'm not sure i'm liking where this is going. given the OSTC+ already works, i'd prefer if can we find another solution. lubomir -- ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [TEST REQUEST] Windows Bluetooth LE build
On Sat, 29 Sep 2018 at 20:26, Dirk Hohndel wrote:
>
>
> > On Sep 28, 2018, at 8:19 PM, Lubomir I. Ivanov wrote:
> >
> > i can investigate their binary a little.
> > we also have the option to just ask them - are they friendly?
>
> They are VERY friendly. I'll reach out to them. But as you mentioned, their's
> is
> a C# app, so things might be different there.
> Can we write a C# helper and pass the information to our app?
>
>
> In the meantime, I completed a compile of Qt 5.11.2 from source, added
> your wip/win qtconnectivity and did a make install to make sure that ALL
> of the files are copied to the right place.
>
> I created an installer from that (which is missing FB, printing, user manual,
> and apparently for some reason even the maps). You can find it on our website
> as
> http://subsurface-divelog.org/downloads/test/subsurface-4.8.2-92-gb05b8de05966.exe
>
do i need to test this installer, given it already worked with -91?
also TMK the -91 would have all the above modules that -92 is missing?
why do we need to upgrade to 5.11.2?
> I then purchased a new copy of Windows 10 (the things we do for our
> hobbies) and installed it on the same laptop that I do my "on hardware"
> Linux testing on.
>
> I paired the Teric with Windows (no problem there at all, found it right
> away).
>
> So now we have:
> - different laptop
> - different BT device (this is a USB dongle, other one was built in)
> - different Windows 10 install
> - NO anti virus, anything
>
> Still the exact same experience in Subsurface
> Regardless if I select Auto or Force LE, I get the Device discovery error.
> And I get it fairly quickly.
>
> If I put my BT-classic-only Petrel in BT mode, it gets detected within a
> second or two, and I can immediately download from it (without having
> to do any pairing first).
>
> So BT works, but somehow the BLE scan results in an error.
>
we might have a lurking bug in our discovery code.
i need to have a detailed look at it.
> You know the code much better than I do... in the scan path, what can
> create such an error? One thing that is odd about my office is that I can
> see more than a dozen BLE devices here on a regular scan. I wonder
> if one of the unpaired ones is causing this behavior. But give then need
> to pair first for BLE, that does seem unlikely, doesn't it?
as mentioned multiple times the Windows discovery and device
enumeration is super shaky.
i don't have other devices in my room and the detection works fine.
please bring this problem device to Sofia.
>
> Is there a way to get more debug info from the Qt BLE code to see WHY
> it created that error?
>
if QtConnectivity is built in debug mode and if you can try moving
this from qt-ble.cpp
QLoggingCategory::setFilterRules(QStringLiteral("qt.bluetooth* = true"));
to btdiscovery.cpp, it might output are better detailed message.
i only got the error if i completely disabled BT from control planel.
hard to say, will have another look.
> My plan for 4.8.3 is to switch back to my previous MXE setup so we have
> working Windows binaries with all components (but not BLE). But I really
> want to push on this BLE story. It feels like we are SO CLOSE.
>
given it works for me and Steven, it really feels like an isolated error.
is there are change we can announce -91 for testing so that we can
gather more feedback?
it feels like my installer is not reaching out to people.
lubomir
--
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Mobile: QML weirdness (likely Kirigami bug)
Ok, yesterday I wrote "So needed: revert both 17ec95e70c3ae58 and 40766db459b21. Bug is related to the page stack and swiping through dives and returning to the list by the breadcrumb (instead of the menu). Sometimes this results in a page that shows both the divelist and the divedetail page on top of each other. Easy to get to a sane state again from that (just select the dive list from the menu), so not a real showstopper, but it look ugly." Further investigation shows that Kirigami commit 26b8bdea24c3930 (Refactor the Global ToolBar concept) first introduces this wrong behavior in Subsurface-mobile. This is very non-trivial commit on the Kirigami side, and I see nothing obvious that could explain the changed behavior. So the question is now: are we (Subsurface-mobile) doing something wrong or is it the mentioned commit that messes things up for us (and prevents us upgrading at this point). I'm highly inclined to blame the Kirigami commit, as things as flicking trough the page stack, using breadcrumb navigation, etc is 99% under control of the Kirigami level of our app. Obviously, a small QML only demonstrator of the issue could prove this. It would be very nice if Marco could take a look as I believe no Subsurface-mobile expertise on this QML/Kirigami level exists. --jan ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: last call 4.8.3
Swedish translation is as good as it gets at the moment. I’m reworking most part of it , and it will take time, so go ahead and release and hope for the best :-) /Johan > 29 sep. 2018 kl. 20:10 skrev Dirk Hohndel : > > > I see that the Swedish translation is in progress, so I'll take my dog for a > walk before cutting 4.8.3 :-) > > If anyone else is working on translations or anything else that should make > it for 4.8.3, please respond soon so I can make sure I include this. > > Also, for those of you doing translations, a draft announcement is on > Transifex as well (thanks to our Dutch, Spanish, and German teams for already > translating that one as well as the new announcement of the public beta > channel for iOS). > > I haven't seen many reports on the last round of test binaries. The reality > is that likely this just wasn't enough time for people to take a look. But > it's either "I release this in the next two hours" or "heck knows when I'll > have time to do it". So I'll cut the release and hope for the best :-) > > In the meantime I have fixed the Fedora build issue (as I assumed, my own > stupidity). > Windows BLE doesn't quite work yet, so I'll put this on hold for a few hours > until after this release. > > Thanks everyone! > > /D > ___ > subsurface mailing list > subsurface@subsurface-divelog.org > http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: last call 4.8.3
> On Sep 29, 2018, at 11:45 AM, Matt Thompson wrote: > > Just ran through a few things on Windows 10. Was able to download dives from > both my Cobalt 2 and Aqualung i750TC. Navigating dives and switching between > computers was working. Map updated correctly when switching between dives. > I was able to upload dives to the cloud and sync them to the mobile version. > > Looks like the basics work for me! Thanks, I appreciate the test... /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: last call 4.8.3
Just ran through a few things on Windows 10. Was able to download dives from both my Cobalt 2 and Aqualung i750TC. Navigating dives and switching between computers was working. Map updated correctly when switching between dives. I was able to upload dives to the cloud and sync them to the mobile version. Looks like the basics work for me! On Sat, Sep 29, 2018 at 1:10 PM Dirk Hohndel wrote: > > I see that the Swedish translation is in progress, so I'll take my dog for > a walk before cutting 4.8.3 :-) > > If anyone else is working on translations or anything else that should > make it for 4.8.3, please respond soon so I can make sure I include this. > > Also, for those of you doing translations, a draft announcement is on > Transifex as well (thanks to our Dutch, Spanish, and German teams for > already translating that one as well as the new announcement of the public > beta channel for iOS). > > I haven't seen many reports on the last round of test binaries. The > reality is that likely this just wasn't enough time for people to take a > look. But it's either "I release this in the next two hours" or "heck knows > when I'll have time to do it". So I'll cut the release and hope for the > best :-) > > In the meantime I have fixed the Fedora build issue (as I assumed, my own > stupidity). > Windows BLE doesn't quite work yet, so I'll put this on hold for a few > hours until after this release. > > Thanks everyone! > > /D > ___ > subsurface mailing list > subsurface@subsurface-divelog.org > http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface > ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
last call 4.8.3
I see that the Swedish translation is in progress, so I'll take my dog for a walk before cutting 4.8.3 :-) If anyone else is working on translations or anything else that should make it for 4.8.3, please respond soon so I can make sure I include this. Also, for those of you doing translations, a draft announcement is on Transifex as well (thanks to our Dutch, Spanish, and German teams for already translating that one as well as the new announcement of the public beta channel for iOS). I haven't seen many reports on the last round of test binaries. The reality is that likely this just wasn't enough time for people to take a look. But it's either "I release this in the next two hours" or "heck knows when I'll have time to do it". So I'll cut the release and hope for the best :-) In the meantime I have fixed the Fedora build issue (as I assumed, my own stupidity). Windows BLE doesn't quite work yet, so I'll put this on hold for a few hours until after this release. Thanks everyone! /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [TEST REQUEST] Windows Bluetooth LE build
> On Sep 28, 2018, at 8:19 PM, Lubomir I. Ivanov wrote: > > i can investigate their binary a little. > we also have the option to just ask them - are they friendly? They are VERY friendly. I'll reach out to them. But as you mentioned, their's is a C# app, so things might be different there. Can we write a C# helper and pass the information to our app? In the meantime, I completed a compile of Qt 5.11.2 from source, added your wip/win qtconnectivity and did a make install to make sure that ALL of the files are copied to the right place. I created an installer from that (which is missing FB, printing, user manual, and apparently for some reason even the maps). You can find it on our website as http://subsurface-divelog.org/downloads/test/subsurface-4.8.2-92-gb05b8de05966.exe I then purchased a new copy of Windows 10 (the things we do for our hobbies) and installed it on the same laptop that I do my "on hardware" Linux testing on. I paired the Teric with Windows (no problem there at all, found it right away). So now we have: - different laptop - different BT device (this is a USB dongle, other one was built in) - different Windows 10 install - NO anti virus, anything Still the exact same experience in Subsurface Regardless if I select Auto or Force LE, I get the Device discovery error. And I get it fairly quickly. If I put my BT-classic-only Petrel in BT mode, it gets detected within a second or two, and I can immediately download from it (without having to do any pairing first). So BT works, but somehow the BLE scan results in an error. You know the code much better than I do... in the scan path, what can create such an error? One thing that is odd about my office is that I can see more than a dozen BLE devices here on a regular scan. I wonder if one of the unpaired ones is causing this behavior. But give then need to pair first for BLE, that does seem unlikely, doesn't it? Is there a way to get more debug info from the Qt BLE code to see WHY it created that error? My plan for 4.8.3 is to switch back to my previous MXE setup so we have working Windows binaries with all components (but not BLE). But I really want to push on this BLE story. It feels like we are SO CLOSE. Thanks /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [TEST REQUEST] Windows Bluetooth LE build
On Sat, 29 Sep 2018 at 18:55, Lubomir I. Ivanov wrote: > > On Sat, 29 Sep 2018 at 04:18, Lubomir I. Ivanov wrote: > > > > On 29 September 2018 at 04:13, Dirk Hohndel wrote: > > > > > >> On Sep 28, 2018, at 6:05 PM, Lubomir I. Ivanov > > >> wrote: > > >>> Nope, much easier. Case sensitive file system. Simply changing it to > > >>> winsock2.h does the trick. > > >>> > > >> > > >> looks like a potential patch i can send. > > > > > > yep. make it all lowercase :-) > > > > patch sent: > > https://codereview.qt-project.org/#/c/241465/ > > > > this patch was merged: > https://codereview.qt-project.org/#/c/241465/ > or rather it's in queue: `Status: INTEGRATING` lubomir -- ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [TEST REQUEST] Windows Bluetooth LE build
On Sat, 29 Sep 2018 at 04:18, Lubomir I. Ivanov wrote: > > On 29 September 2018 at 04:13, Dirk Hohndel wrote: > > > >> On Sep 28, 2018, at 6:05 PM, Lubomir I. Ivanov wrote: > >>> Nope, much easier. Case sensitive file system. Simply changing it to > >>> winsock2.h does the trick. > >>> > >> > >> looks like a potential patch i can send. > > > > yep. make it all lowercase :-) > > patch sent: > https://codereview.qt-project.org/#/c/241465/ > this patch was merged: https://codereview.qt-project.org/#/c/241465/ lubomir -- ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [TEST REQUEST] Windows Bluetooth LE build
On Sat, 29 Sep 2018 at 16:43, Steve wrote: > > > Got a chance to test this again with a good charge in the battery and it > completed successfully all the way this time. > > Let me know if you want the logs but I can report it all it all looks good. > thanks for testing Steve, at least now we know that the OSTC(3)+ works on BLE/Windows lubomir -- ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
RE: [TEST REQUEST] Windows Bluetooth LE build
I haven't had a chance to test again yet as I am away gathering more real test data :). I can test again when I get back on Monday nigh t or Tuesday morning. Sent from mobile device. From: Lubomir I. Ivanov Sent: Saturday, 29 September, 00:23 Subject: Re: [TEST REQUEST] Windows Bluetooth LE build To: Dirk Hohndel Cc: Anton Lundin On 28 September 2018 at 17:44, Dirk Hohndel wrote: > >> On Sep 28, 2018, at 6:36 AM, Anton Lundin wrote: >> >> So, some how we ended up being out of order. >> >> I would need to look at the libdivecomputer log file to. It might tell >> us what actually happened. > > Yes, that would be good to follow up on > >>> i guess the biggest point here is that the BTLE Win32 stack works. >> >> YEY. > > Yes indeed. Now how do I add Lubomir's patches to my built-from-source-anyway Qt libraries for MXE? > So we can get more people to test "official" binaries? > > So cool. So, so cool. i will post some instructions later today. the changes to make win32-ble to work are part of an official branch. > > (and yes, Lubomir, I'll bring with me next week one of my favorite dive computers as that is a BLE device that's very different from the OSTC that you have...) > sounds good. Steve, did you had a change to test again? also please share all the logs + dumps so that we can have a look. thanks. lubomir – Got a chance to test this again with a good charge in the battery and it completed successfully all the way this time. Let me know if you want the logs but I can report it all it all looks good. Steve ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Translations and test binaries [was: rush job before I travel - can we pull off 4.8.3 / 2.1.4 this weekend?]
On 9/29/18 1:11 AM, Dirk Hohndel wrote: Here’s where we are: Test binaries are app for all platforms: Windows: http://subsurface-divelog.org/downloads/test/subsurface-4.8.2-90-ge0e20edd87af.exe Mac: http://subsurface-divelog.org/downloads/test/Subsurface-4.8.2-90-ge0e20edd87af.dmg AppImage: https://github.com/Subsurface-divelog/subsurface/releases/download/continuous/Subsurface-4.8.2-90-ge0e20edd87af-x86_64.AppImage Ubuntu is on Launchpad OpenSUSE is on OBS Fedora builds failed again on OBS, need to look into what I messed up this time - it looks like my fix for the appdata.xml didn’t actually work Android: http://subsurface-divelog.org/downloads/test/Subsurface-mobile-4.8.2.90-arm.apk - but also pushed to Google Play beta channel iOS has been submitted for review, should show up “soon” It would be great to make sure we have at least some testing for these binaries - reports “hey, did a quick test, nothing seems broken” (or the opposite :-( ) would be extremely helpful so that we at least have some indication how much testing this has gotten. Many translations have already been completed - you people are AMAZING!!! If all goes well I’ll create this “quick release” on Saturday :-) Android from play store tested. Swiping through logbook, OSTC download over BT and BLE, scaling UI => all good :-) --jan ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
