Re: [TEST REQUEST] Windows Bluetooth LE build
This is what I mentioned the other day. The BT+BLE Petrel is an odd beast. It has two different chips. BT only and BLE only. And once BT connects, BLE turns off. So from anything but a BLE only computer (i.e., iPhone, iPad) you'll only see BT /D On October 3, 2018 1:00:55 AM GMT+02:00, "Lubomir I. Ivanov" wrote: >On Wed, 3 Oct 2018 at 01:38, Steve >wrote: >> >> Subject: Re: [TEST REQUEST] Windows Bluetooth LE build >> >> > >hello, > >> Ok I gave the new program a go on the Petrel2Ext but it is saying it >doesn't support BTLE? >> >> It should be the first Petrel I tried but I haven't had coffee yet so >I tried the other one that I no longer have just in case I picked the >wrong address. >> > > > >> device # 1 >> addr: "00:13:43:0C:65:AC" >> name: "Petrel" >> coreConfiguration: QFlags(0x2) > > > >it detected the Petrel as BT device not BTLE; this is what the 0x2 >means. >if it supports both BT and BTLE it should be (0x1 | 0x2) or 0x1 or 0x3. > >does this device support BTLE? > >if yes, could you please try a couple of things: >- try scanning for the BTLE device again from the Windows Control >Panel? >- try this new build of Subsurface once you have a paired BTLE >computer: >https://www.dropbox.com/s/zslq3ughx9ciehj/_deploy_win32_ble.zip?dl=0 > >the new program can also be used point if the device is detected as BT >/ BTLE. > >thanks >lubomir >-- -- From my phone___ 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 Wed, 3 Oct 2018 at 01:38, Steve wrote: > > Subject: Re: [TEST REQUEST] Windows Bluetooth LE build > > hello, > Ok I gave the new program a go on the Petrel2Ext but it is saying it doesn't > support BTLE? > > It should be the first Petrel I tried but I haven't had coffee yet so I tried > the other one that I no longer have just in case I picked the wrong address. > > device # 1 > addr: "00:13:43:0C:65:AC" > name: "Petrel" > coreConfiguration: QFlags(0x2) it detected the Petrel as BT device not BTLE; this is what the 0x2 means. if it supports both BT and BTLE it should be (0x1 | 0x2) or 0x1 or 0x3. does this device support BTLE? if yes, could you please try a couple of things: - try scanning for the BTLE device again from the Windows Control Panel? - try this new build of Subsurface once you have a paired BTLE computer: https://www.dropbox.com/s/zslq3ughx9ciehj/_deploy_win32_ble.zip?dl=0 the new program can also be used point if the device is detected as BT / BTLE. 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
Subject: Re: [TEST REQUEST] Windows Bluetooth LE build On Mon, 1 Oct 2018 at 16:17, Dirk Hohndel wrote: > > > > On Sep 30, 2018, at 6:40 PM, Lubomir I. Ivanov wrote: > >> > >> Rebooted. Nothing else running, just the cmd.exe > >> > >> Same output - semaphore timeout period has expired. > >> > > did some more testing here. my phone's BT is off all the time, i don't anything to use it with. i'm able to reproduce this error if i pair and connect my phone using NRF Connect with the DC, and then try to connect and write a descriptor using the qt-bt-discovery.exe app. to get out of this scenario i disconnect from the NRF Connect app. at this point qt-bt-discovery.exe writes the descriptor correctly. but this is not consistent - it can lead into all sorts of weird conditions, like: - writing the descriptor from the .EXE app disconnects the phone. - if the phone is disconnected after that, it can no longer connect to the device and the phone BT has to be turned off/on. - if the phone "takes ownership" of the device, the Windows BT has to be turned off/on, but then it decides to forget the the DC 50% of the time. - rediscovering the device in Windows might fail to pair or the discovery process even crashes - OS restart is required. this proves to me that there are ownership issues here, but also that the whole process is quite unreliable. so if another device other than the Windows laptop is connected to the DC, writing to a service will simply fail with the semaphore error and there would be no other indication. could you try turning all suspect local devices off for such a test? ...but something else here, the Qt code is doing everything correctly and i cannot blame it, at this point. for now i can only blame Windows' BT support and BT as a whole. > Also, how do I quit the program? Ctrl-C doesn't appear to work. All I can > figure out is kill the cmd.exe. > That doesn't seem like the right way to do this :-) > i have updated the test app to now properly exit on ctrl+c: https://www.dropbox.com/s/ehkoklydtnrvzxg/_qt-bt-discovery.zip?dl=0 lubomir -- Ok I gave the new program a go on the Petrel2Ext but it is saying it doesn't support BTLE? It should be the first Petrel I tried but I haven't had coffee yet so I tried the other one that I no longer have just in case I picked the wrong address. Steve press to start discovery... discovery started... entering main loop... qt.bluetooth.windows: Emit: "00:15:83:40:A4:77" qt.bluetooth.windows: Emit: "00:13:43:0C:65:AC" qt.bluetooth.windows: Emit: "D4:AE:05:97:A7:78" qt.bluetooth.windows: Emit: "00:07:80:6F:14:15" qt.bluetooth.windows: Emit: "54:42:49:45:46:15" qt.bluetooth.windows: Emit: "18:03:23:32:16:E7" qt.bluetooth.windows: Emit: "00:13:43:0D:DB:D4" discovery finished enumerate devices --- device # 0 addr: "00:15:83:40:A4:77" name: "OBDBLE" coreConfiguration: QFlags(0x1) --- device # 1 addr: "00:13:43:0C:65:AC" name: "Petrel" coreConfiguration: QFlags(0x2) --- device # 2 addr: "D4:AE:05:97:A7:78" name: "Galaxy S8+" coreConfiguration: QFlags(0x2) --- device # 3 addr: "00:07:80:6F:14:15" name: "DS000220" coreConfiguration: QFlags(0x2) --- device # 4 addr: "54:42:49:45:46:15" name: "AS-BT100" coreConfiguration: QFlags(0x2) --- device # 5 addr: "18:03:23:32:16:E7" name: "T energy" coreConfiguration: QFlags(0x2) --- device # 6 addr: "00:13:43:0D:DB:D4" name: "Petrel" coreConfiguration: QFlags(0x2) --- done enumerating devices enter a device # to connect to: 6 error: device does not support BTLE. enter a device # to connect to: 1 error: device does not support BTLE. enter a device # to connect to: ___ 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 Tue, Oct 02, 2018 at 05:01:42PM +0300, Lubomir I. Ivanov wrote: > On Tue, 2 Oct 2018 at 05:27, Lubomir I. Ivanov wrote: > > > > On Mon, 1 Oct 2018 at 16:17, Dirk Hohndel wrote: > > > > > > > > > > On Sep 30, 2018, at 6:40 PM, Lubomir I. Ivanov > > > > wrote: > > > >> > > > >> Rebooted. Nothing else running, just the cmd.exe > > > >> > > > >> Same output - semaphore timeout period has expired. > > > >> > > > > > > > > ...but something else here, the Qt code is doing everything correctly > > and i cannot blame it, at this point. > > for now i can only blame Windows' BT support and BT as a whole. > > > > yeah...the pairing process is super broke and unreliable via the > Windows Control Panel UI. > at this point i'm tempted to go with a helper C# app that does the > pairing for the sake of avoiding the above UI. That seems like a good idea, frankly. Given packing issues I ended up not bringing my Windows laptop, so I can't continue testing until I'm back home on the weekend. But I'll hand you the Perdix Ai on Friday which should allow you vaidate some of the assumptions. 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 Tue, 2 Oct 2018 at 05:27, Lubomir I. Ivanov wrote: > > On Mon, 1 Oct 2018 at 16:17, Dirk Hohndel wrote: > > > > > > > On Sep 30, 2018, at 6:40 PM, Lubomir I. Ivanov > > > wrote: > > >> > > >> Rebooted. Nothing else running, just the cmd.exe > > >> > > >> Same output - semaphore timeout period has expired. > > >> > > > > > ...but something else here, the Qt code is doing everything correctly > and i cannot blame it, at this point. > for now i can only blame Windows' BT support and BT as a whole. > yeah...the pairing process is super broke and unreliable via the Windows Control Panel UI. at this point i'm tempted to go with a helper C# app that does the pairing for the sake of avoiding the above UI. lubomir -- ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
