[TEST REQUEST] Windows Bluetooth LE build

[Lubomir I. Ivanov]

On 11 June 2018 at 21:56, Lubomir I. Ivanov <neolit123 at gmail.com> wrote:
> On 11 June 2018 at 21:50, Linus Torvalds <torvalds at linux-foundation.org> wrote:
>> On Mon, Jun 11, 2018 at 11:31 AM Lubomir I. Ivanov <neolit123 at gmail.com> wrote:
>>>
>>> the Qt BLE Windows stack on the other hand detects it as "Write
>>> without response".
>>> this has to be investigated - possible bug.
>>
>> That's how you enable notifications - you write a 16-bit value to the
>> notification thing that has the notification bit enabled (and you
>> don't ask for responses).
>>
>> BLE is kind of odd. We also do things kind of oddly, because the way
>> we generate that 16-bit value is with
>>
>>     QByteArray::fromHex("0100")
>>
>> which is just another way to say "two bytes: 0x01 and 0x00", which is
>> just the little-endian layout of 0x0001.
>>
>> So it's that
>>
>>     qDebug() << "now writing \"0x0100\" to the descriptor" <<
>> d.uuid().toString();
>>     ble->preferredService()->writeDescriptor(d, QByteArray::fromHex("0100"));
>>
>> that should enable notifications on the notification characteristic.
>>
>
> thanks, i will check if it succeeds with this stack.
>

update:

i wrote a couple of minimal apps that for the GATT service of interest
in the OSTC+, write data to the first characteristic and wait for a
notification from the second characteristic.
- BLE WINAPI native C.
- BLE WINAPI via Qt.

the first app works and is able to catch the 0x4D response from the DC.
there seems to be a bug in Qt notification code.
too bad that the author of the code:
- doesn't speak good english.
- usually is busy and doesn't respond to email.
but still i'm going to ask if notifications have been tested at all.

my goal right not is to investigate the bug in Qt and try to fix it.

side observation:
in the case of the OSTC+ there is no need to write the 0100 to the
second char's descriptor to make it notifiable as it already is.
i haven't looked at what 0200 does yet.

lubomir
--