[TEST REQUEST] Windows Bluetooth LE build

[Dirk Hohndel]

> On Sep 30, 2018, at 7:53 AM, Lubomir I. Ivanov <neolit123 at gmail.com> wrote:
>> 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:
> 
> my assumption is that this installer has the QBluetoothDiscoveryAgent
> for Windows, patch applied?

What exactly are you referencing with that? Just to make sure I know which
patch you mean?

> perhaps more testing for this is needed by others, but i would suggest
> we merge such a patch in master too.

I am playing around with being a bit smarter here and will have a patch for
master in a little while - still doing some more testing myself, while I can :-)

>> 
>> Using read characteristic "{27b7570b-359e-45a3-91bb-cf7e70049bd2}"
>> 
>> now writing "0x0100" to the descriptor "{00002902-0000-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"
>> 
> 
> i'm not sure why that is happening.
> given the OSTC+ download works i'm going to assume it's our code is
> not accommodated to the Teric in the case of the Qt win32 stack.
> 
> questions:
> - what is the state of Petrel with the the new discovery code
> (QBluetoothDiscoveryAgent under Windows)?

The Petrel is BT only. Let me check that one and see if it works. Good idea.

> - does Teric work on Linux?

Yes. As does the Perdix AI (which I tested as well and which gives the
exact same output)

>> 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).
> 
> i must admit i'm a bit confused. i'm not sure why Subsurface asks to
> pair - can you show a screenshot? on Windows the pairing should only
> happen via the Control Panel...

Yeah, I was a bit too aggressive in removing things that were Windows
specific. This one I restored, so you can ignore this.

> at this point, after we discover the address of the device we can just
> connect to it and then discover it's services.
> address hacks should not be needed.

Correct. I have a new test binary up and will report back what I see in a moment.

/D