Re: converting logbook formats
Thanks a lot Anton, I was aware of the 'simple solution', but just not a huge fan of uploading privat stuff to any storage beyond my control. But the other solution sounds reasonable. I'll try that. I was about to look into the logbook access in the source... _that_ would have meant effort. cheers /Chris On Mo, 2018-06-11 at 20:27 +0200, Anton Lundin wrote: > On 08 June, 2018 - C. Hoefer wrote: > > > Hello, > > > > I'm trying to start using subsurface mobile. > > > > Is there a tool to convert my xml logbook to the format used with the > > mobile? Back and forth at best. :-) > > The simple answer is Use the cloud service. Its the only supported > source for subsurface mobile. It will handle everything for you. > > > > To answer your literal question, Using Subsurface is the sane way of > doing it. Just create a git repo, ex: > > mkdir ~/TEST > cd ~/TEST > git init . > > and choose save as, and point it to that repo, and add [branch-name] to > it. > > > If you're bat shit crazy like I am, you can then transplant that repo > into the data folder of your mobile device, and you've loaded your > logbook into your mobile device without the cloud service. It requires a > lot of low level hacking, so its not recommended for anyone else. > > > //Anton > > ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Missing pO2 samples from CCR download [was: 4.7.8: a couple of questions]
On 11 June, 2018 - Jef Driesen wrote: > On 11-06-18 20:21, Anton Lundin wrote: > >On 04 June, 2018 - Dirk Hohndel wrote: > > > >>I don't have an outstanding patch from you, so not sure what you are > >>referring to. > > > >There was a diff a while back in this thread, in > >20180523144751.gc12...@hirohito.acc.umu.se , which made the code fall > >back to the voted/averaged ppo2 instead of reporting individual sensors > >if we couldn't find sane calibration values. > > > > > >Jef didn't like it, but I think its a step to a better place than where > >we're right now, and as far as I've read it, both Davide and Martin who > >is affected agrees. > > > > > >Anyway, now when I'm back on solid ground (I still feel the waves in my > >legs) I might get around to making up a commit message and formating it > >as a patch. > > It's not that I really disliked the patch. I just wanted to point > out that it introduces a possible disambiguity in the sense that in > the application you no longer know which type of ppo2 you are > getting (voted or sensor). I would rather go for a solution that > indicates the type. That's exactly what's on my (long) todo list. > Yes, that would have bin great to have, but we don't have it, and its mixed already. Some backends return voted/average/computed and some return sensor values. Return real mV values would be nice to. > But I'm fine with your patch as an interim solution as well. Btw, an > alternative could be to always deliver both the voted *and* the > sensor ppO2. Then you know for sure that the first value is always > the voted value, and the remaining ones (if present) are the sensor > ones. Would we then invent a averaged value for backends who doesn't have it, like the ostc3? This sounds like a even bigger mess to me. //Anton -- Anton Lundin+46702-161604 ___ 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 Montag, 11. Juni 2018 20:50:56 CEST Linus Torvalds wrote:
> 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")
I think the idiomatic way to do this is the
QByteArrayLiteral("\x01\x00")
macro invocation (don't look at the macro definition - you might weep). Here,
the object is compile-time generated. Nevertheless, its use is not "free" as
claimed in the docs. There's still useless code generated owing to reference
counting. Well, perhaps the compiler could decide that deallocating the static
storage is undefined behavior and simply not generate the deallocation branch.
But "gcc -O2" does.
TL;DR: writeCharacteristic() taking a "const QByteArray &" parameter is an
API-bug. It should take an "array_view" (i.e. const pointer + length) to which
QByteArray automatically converts.
Berthold
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Missing pO2 samples from CCR download [was: 4.7.8: a couple of questions]
On Mon, 11 Jun 2018 at 20:21, Anton Lundin wrote: > > On 04 June, 2018 - Dirk Hohndel wrote: > > > I don't have an outstanding patch from you, so not sure what you are > > referring to. > > There was a diff a while back in this thread, in > 20180523144751.gc12...@hirohito.acc.umu.se , which made the code fall > back to the voted/averaged ppo2 instead of reporting individual sensors > if we couldn't find sane calibration values. Diff is on Github issue too: https://github.com/Subsurface-divelog/subsurface/issues/971#issuecomment-391630681 > > Jef didn't like it, but I think its a step to a better place than where > we're right now, and as far as I've read it, both Davide and Martin who > is affected agrees. > > > Anyway, now when I'm back on solid ground (I still feel the waves in my > legs) I might get around to making up a commit message and formating it > as a patch. > Hi guys, This is really a big blocking issue for me. I lost data for my last 50 dives. I tried to temporary overcome the problem downloading dives with Shearwater desktop and then importing them in Subsurface via XML. Even in this case there are errors: - no pO2 samples - average pO2 completely wrong: graph reports a bottom pO2 of 1,92 bar I updated issue #971 with screenshots Bye -- Davide https://vimeo.com/bocio/videos ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Missing pO2 samples from CCR download [was: 4.7.8: a couple of questions]
On 11-06-18 20:21, Anton Lundin wrote: On 04 June, 2018 - Dirk Hohndel wrote: I don't have an outstanding patch from you, so not sure what you are referring to. There was a diff a while back in this thread, in 20180523144751.gc12...@hirohito.acc.umu.se , which made the code fall back to the voted/averaged ppo2 instead of reporting individual sensors if we couldn't find sane calibration values. Jef didn't like it, but I think its a step to a better place than where we're right now, and as far as I've read it, both Davide and Martin who is affected agrees. Anyway, now when I'm back on solid ground (I still feel the waves in my legs) I might get around to making up a commit message and formating it as a patch. It's not that I really disliked the patch. I just wanted to point out that it introduces a possible disambiguity in the sense that in the application you no longer know which type of ppo2 you are getting (voted or sensor). I would rather go for a solution that indicates the type. That's exactly what's on my (long) todo list. But I'm fine with your patch as an interim solution as well. Btw, an alternative could be to always deliver both the voted *and* the sensor ppO2. Then you know for sure that the first value is always the voted value, and the remaining ones (if present) are the sensor ones. Jef ___ 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 11 June 2018 at 21:50, Linus Torvalds wrote:
> On Mon, Jun 11, 2018 at 11:31 AM Lubomir I. Ivanov
> 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.
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 Mon, Jun 11, 2018 at 11:31 AM Lubomir I. Ivanov 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.
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 11 June 2018 at 20:36, Jan Mulder wrote: > On 11-06-18 19:20, Lubomir I. Ivanov wrote: >> >> On 11 June 2018 at 20:00, Jan Mulder wrote: >>> Check for the correct ready byte is not done at the Subsurface side, but >>> in >>> the libdivecomputer procedure hw_ostc3_transfer(...). But not sure that >>> answers your question. >>> >> >> ok i see, >> >> to my understanding libdc has to query the value of the second >> characteristic for the READY command via the Qt BLE. >> >> this characteristic remains with the state "Write without response" >> and does not update it's state to "Notify" in the current Windows Qt >> BLE stack. >> which then does not trigger our slots: >> BLEObject::characteristcStateChanged >> BLEObject::characteristicWritten >> >> as far as i can tell this is a Windows Qt BLE issue - waiting on a >> response from the QtConnectivity folks. >> >> but one strange thing here is that the document says that the second >> characteristic should be in a "Notify" state from the start, which is >> not the case for my OSTC+. >> so i'm still not sure if this is specific to this prototype. >> >> if you or someone else with a OSTC+ can confirm to me what the initial >> parameters of the OSTC+ 's second characteristic are, i would >> appreciate it. >> is it "Write without response" or "Notify" and on what OS / platform? >> >> cc Anton as i see him as a libdc contributor in this area. > > > > Checking with nfConnect on Android. Characteristic 2 is Notify. 1 is write > no response, 3 is write and 4 is indicate. Exactly as is written in the TIO > document sections 6.2 .. 6.5 All this by scanning my OSTC3 > thank you, i forgot about nrfConnect on Android...just tried that myself and the second characteristic is indeed Notify. so the device is fine. the Qt BLE Windows stack on the other hand detects it as "Write without response". this has to be investigated - possible bug. i hope it's a matter of fixing some of the flags here: https://msdn.microsoft.com/en-us/library/windows/hardware/hh450840(v=vs.85).aspx and not being an API level bug. lubomir -- ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: converting logbook formats
On 08 June, 2018 - C. Hoefer wrote: > Hello, > > I'm trying to start using subsurface mobile. > > Is there a tool to convert my xml logbook to the format used with the > mobile? Back and forth at best. :-) The simple answer is Use the cloud service. Its the only supported source for subsurface mobile. It will handle everything for you. To answer your literal question, Using Subsurface is the sane way of doing it. Just create a git repo, ex: mkdir ~/TEST cd ~/TEST git init . and choose save as, and point it to that repo, and add [branch-name] to it. If you're bat shit crazy like I am, you can then transplant that repo into the data folder of your mobile device, and you've loaded your logbook into your mobile device without the cloud service. It requires a lot of low level hacking, so its not recommended for anyone else. //Anton -- Anton Lundin+46702-161604 ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Missing pO2 samples from CCR download [was: 4.7.8: a couple of questions]
On 04 June, 2018 - Dirk Hohndel wrote: > I don't have an outstanding patch from you, so not sure what you are > referring to. There was a diff a while back in this thread, in 20180523144751.gc12...@hirohito.acc.umu.se , which made the code fall back to the voted/averaged ppo2 instead of reporting individual sensors if we couldn't find sane calibration values. Jef didn't like it, but I think its a step to a better place than where we're right now, and as far as I've read it, both Davide and Martin who is affected agrees. Anyway, now when I'm back on solid ground (I still feel the waves in my legs) I might get around to making up a commit message and formating it as a patch. //Anton -- Anton Lundin+46702-161604 ___ 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 11 June, 2018 - Lubomir I. Ivanov wrote: > On 11 June 2018 at 20:00, Jan Mulder wrote: > > On 11-06-18 18:29, Lubomir I. Ivanov wrote: > >> > >> On 11 June 2018 at 18:16, Lubomir I. Ivanov wrote: > >>> > >>> On 11 June 2018 at 17:49, Dirk Hohndel wrote: > > > > On Jun 10, 2018, at 5:36 PM, Lubomir I. Ivanov > > wrote: > > > > 2) so OSTC+ has a certain service with 4 WriteNoResponse > > characteristics (no READ, WRITE-ONLY) which is supposedly the service > > we have to use for communicating to the device. at least we assume > > that in Subsurface but i don't see a concrete reason for this > > assumption. we also assume that the first characteristic is the one we > > want to write the "0xBB" to. > > > This code was written based on documentation of the BLE stack that the > OSTC implements. > I wonder if the four characteristics are in the same order. It would be > interesting > to dump all the information we can get on the four of them both under > Windows > and Linux and see if this points at something odd. > >>> > >>> > >>> where can i find this documentation? > >>> > >>> if someone gives me the Linux UUIDs of the 4 chars i can compare. > >>> even a dump of the whole successful operation of downloading dives > >>> (command exchange etc) would help. > >>> > >> > >> after checking the document, i can confirm that the order and flags of > >> the characteristics (in the service of interest) matches for this > >> prototype OSTC+. > >> > >> Jan, do you remember what procedure we use to verify that second > >> characteristic (0002--1000-8000-00802500) has received the > >> READY command: > >> > >> https://github.com/Subsurface-divelog/libdc/blob/e97a47cca55973199715df0f818b4955e60d3a31/src/hw_ostc3.c#L56 > >> > >> i can only find the writing of the INIT command to the first > >> characteristic (0001--1000-8000-00802500) in our code > >> base: > >> > >> https://github.com/Subsurface-divelog/subsurface/blob/master/core/qt-ble.cpp#L158 > > > > > > Check for the correct ready byte is not done at the Subsurface side, but in > > the libdivecomputer procedure hw_ostc3_transfer(...). But not sure that > > answers your question. > > > > ok i see, > > to my understanding libdc has to query the value of the second > characteristic for the READY command via the Qt BLE. > > this characteristic remains with the state "Write without response" > and does not update it's state to "Notify" in the current Windows Qt > BLE stack. > which then does not trigger our slots: > BLEObject::characteristcStateChanged > BLEObject::characteristicWritten > > as far as i can tell this is a Windows Qt BLE issue - waiting on a > response from the QtConnectivity folks. > > but one strange thing here is that the document says that the second > characteristic should be in a "Notify" state from the start, which is > not the case for my OSTC+. > so i'm still not sure if this is specific to this prototype. > > if you or someone else with a OSTC+ can confirm to me what the initial > parameters of the OSTC+ 's second characteristic are, i would > appreciate it. > is it "Write without response" or "Notify" and on what OS / platform? > > cc Anton as i see him as a libdc contributor in this area. I haven't played around with BLE that much, but I have a OSTC4 which I can test things against, but no windows around. On the higher layers of libdc, it doesn't care if its serial, BT or BTLE, the protocol to talk with OSTC3's (OSTC3, OSTC+, OSTC Sport, OSTC2, OSTC4 and so on) are all the same. It's Jan who figured out how to talk with the BLE chip in those, and its some sort of quasi-standard "serial over BLE" or something. The current BLE code in Subsurface works just great against the OSTC4 I got, on both android and Linux. //Anton -- Anton Lundin+46702-161604 ___ 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 11-06-18 19:20, Lubomir I. Ivanov wrote: On 11 June 2018 at 20:00, Jan Mulder wrote: On 11-06-18 18:29, Lubomir I. Ivanov wrote: On 11 June 2018 at 18:16, Lubomir I. Ivanov wrote: On 11 June 2018 at 17:49, Dirk Hohndel wrote: On Jun 10, 2018, at 5:36 PM, Lubomir I. Ivanov wrote: 2) so OSTC+ has a certain service with 4 WriteNoResponse characteristics (no READ, WRITE-ONLY) which is supposedly the service we have to use for communicating to the device. at least we assume that in Subsurface but i don't see a concrete reason for this assumption. we also assume that the first characteristic is the one we want to write the "0xBB" to. This code was written based on documentation of the BLE stack that the OSTC implements. I wonder if the four characteristics are in the same order. It would be interesting to dump all the information we can get on the four of them both under Windows and Linux and see if this points at something odd. where can i find this documentation? if someone gives me the Linux UUIDs of the 4 chars i can compare. even a dump of the whole successful operation of downloading dives (command exchange etc) would help. after checking the document, i can confirm that the order and flags of the characteristics (in the service of interest) matches for this prototype OSTC+. Jan, do you remember what procedure we use to verify that second characteristic (0002--1000-8000-00802500) has received the READY command: https://github.com/Subsurface-divelog/libdc/blob/e97a47cca55973199715df0f818b4955e60d3a31/src/hw_ostc3.c#L56 i can only find the writing of the INIT command to the first characteristic (0001--1000-8000-00802500) in our code base: https://github.com/Subsurface-divelog/subsurface/blob/master/core/qt-ble.cpp#L158 Check for the correct ready byte is not done at the Subsurface side, but in the libdivecomputer procedure hw_ostc3_transfer(...). But not sure that answers your question. ok i see, to my understanding libdc has to query the value of the second characteristic for the READY command via the Qt BLE. this characteristic remains with the state "Write without response" and does not update it's state to "Notify" in the current Windows Qt BLE stack. which then does not trigger our slots: BLEObject::characteristcStateChanged BLEObject::characteristicWritten as far as i can tell this is a Windows Qt BLE issue - waiting on a response from the QtConnectivity folks. but one strange thing here is that the document says that the second characteristic should be in a "Notify" state from the start, which is not the case for my OSTC+. so i'm still not sure if this is specific to this prototype. if you or someone else with a OSTC+ can confirm to me what the initial parameters of the OSTC+ 's second characteristic are, i would appreciate it. is it "Write without response" or "Notify" and on what OS / platform? cc Anton as i see him as a libdc contributor in this area. Checking with nfConnect on Android. Characteristic 2 is Notify. 1 is write no response, 3 is write and 4 is indicate. Exactly as is written in the TIO document sections 6.2 .. 6.5 All this by scanning my OSTC3 --jan ___ 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 11 June 2018 at 20:00, Jan Mulder wrote: > On 11-06-18 18:29, Lubomir I. Ivanov wrote: >> >> On 11 June 2018 at 18:16, Lubomir I. Ivanov wrote: >>> >>> On 11 June 2018 at 17:49, Dirk Hohndel wrote: > On Jun 10, 2018, at 5:36 PM, Lubomir I. Ivanov > wrote: > > 2) so OSTC+ has a certain service with 4 WriteNoResponse > characteristics (no READ, WRITE-ONLY) which is supposedly the service > we have to use for communicating to the device. at least we assume > that in Subsurface but i don't see a concrete reason for this > assumption. we also assume that the first characteristic is the one we > want to write the "0xBB" to. This code was written based on documentation of the BLE stack that the OSTC implements. I wonder if the four characteristics are in the same order. It would be interesting to dump all the information we can get on the four of them both under Windows and Linux and see if this points at something odd. >>> >>> >>> where can i find this documentation? >>> >>> if someone gives me the Linux UUIDs of the 4 chars i can compare. >>> even a dump of the whole successful operation of downloading dives >>> (command exchange etc) would help. >>> >> >> after checking the document, i can confirm that the order and flags of >> the characteristics (in the service of interest) matches for this >> prototype OSTC+. >> >> Jan, do you remember what procedure we use to verify that second >> characteristic (0002--1000-8000-00802500) has received the >> READY command: >> >> https://github.com/Subsurface-divelog/libdc/blob/e97a47cca55973199715df0f818b4955e60d3a31/src/hw_ostc3.c#L56 >> >> i can only find the writing of the INIT command to the first >> characteristic (0001--1000-8000-00802500) in our code >> base: >> >> https://github.com/Subsurface-divelog/subsurface/blob/master/core/qt-ble.cpp#L158 > > > Check for the correct ready byte is not done at the Subsurface side, but in > the libdivecomputer procedure hw_ostc3_transfer(...). But not sure that > answers your question. > ok i see, to my understanding libdc has to query the value of the second characteristic for the READY command via the Qt BLE. this characteristic remains with the state "Write without response" and does not update it's state to "Notify" in the current Windows Qt BLE stack. which then does not trigger our slots: BLEObject::characteristcStateChanged BLEObject::characteristicWritten as far as i can tell this is a Windows Qt BLE issue - waiting on a response from the QtConnectivity folks. but one strange thing here is that the document says that the second characteristic should be in a "Notify" state from the start, which is not the case for my OSTC+. so i'm still not sure if this is specific to this prototype. if you or someone else with a OSTC+ can confirm to me what the initial parameters of the OSTC+ 's second characteristic are, i would appreciate it. is it "Write without response" or "Notify" and on what OS / platform? cc Anton as i see him as a libdc contributor in this area. 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 11-06-18 18:29, Lubomir I. Ivanov wrote: On 11 June 2018 at 18:16, Lubomir I. Ivanov wrote: On 11 June 2018 at 17:49, Dirk Hohndel wrote: On Jun 10, 2018, at 5:36 PM, Lubomir I. Ivanov wrote: 2) so OSTC+ has a certain service with 4 WriteNoResponse characteristics (no READ, WRITE-ONLY) which is supposedly the service we have to use for communicating to the device. at least we assume that in Subsurface but i don't see a concrete reason for this assumption. we also assume that the first characteristic is the one we want to write the "0xBB" to. This code was written based on documentation of the BLE stack that the OSTC implements. I wonder if the four characteristics are in the same order. It would be interesting to dump all the information we can get on the four of them both under Windows and Linux and see if this points at something odd. where can i find this documentation? if someone gives me the Linux UUIDs of the 4 chars i can compare. even a dump of the whole successful operation of downloading dives (command exchange etc) would help. after checking the document, i can confirm that the order and flags of the characteristics (in the service of interest) matches for this prototype OSTC+. Jan, do you remember what procedure we use to verify that second characteristic (0002--1000-8000-00802500) has received the READY command: https://github.com/Subsurface-divelog/libdc/blob/e97a47cca55973199715df0f818b4955e60d3a31/src/hw_ostc3.c#L56 i can only find the writing of the INIT command to the first characteristic (0001--1000-8000-00802500) in our code base: https://github.com/Subsurface-divelog/subsurface/blob/master/core/qt-ble.cpp#L158 Check for the correct ready byte is not done at the Subsurface side, but in the libdivecomputer procedure hw_ostc3_transfer(...). But not sure that answers your question. --jan ___ 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 11 June 2018 at 18:16, Lubomir I. Ivanov wrote: > On 11 June 2018 at 17:49, Dirk Hohndel wrote: >> >>> On Jun 10, 2018, at 5:36 PM, Lubomir I. Ivanov wrote: >>> >>> 2) so OSTC+ has a certain service with 4 WriteNoResponse >>> characteristics (no READ, WRITE-ONLY) which is supposedly the service >>> we have to use for communicating to the device. at least we assume >>> that in Subsurface but i don't see a concrete reason for this >>> assumption. we also assume that the first characteristic is the one we >>> want to write the "0xBB" to. >> >> This code was written based on documentation of the BLE stack that the >> OSTC implements. >> I wonder if the four characteristics are in the same order. It would be >> interesting >> to dump all the information we can get on the four of them both under Windows >> and Linux and see if this points at something odd. > > where can i find this documentation? > > if someone gives me the Linux UUIDs of the 4 chars i can compare. > even a dump of the whole successful operation of downloading dives > (command exchange etc) would help. > after checking the document, i can confirm that the order and flags of the characteristics (in the service of interest) matches for this prototype OSTC+. Jan, do you remember what procedure we use to verify that second characteristic (0002--1000-8000-00802500) has received the READY command: https://github.com/Subsurface-divelog/libdc/blob/e97a47cca55973199715df0f818b4955e60d3a31/src/hw_ostc3.c#L56 i can only find the writing of the INIT command to the first characteristic (0001--1000-8000-00802500) in our code base: https://github.com/Subsurface-divelog/subsurface/blob/master/core/qt-ble.cpp#L158 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 11-06-18 17:16, Lubomir I. Ivanov wrote: This code was written based on documentation of the BLE stack that the OSTC implements. I wonder if the four characteristics are in the same order. It would be interesting to dump all the information we can get on the four of them both under Windows and Linux and see if this points at something odd. where can i find this documentation? if someone gives me the Linux UUIDs of the 4 chars i can compare. even a dump of the whole successful operation of downloading dives (command exchange etc) would help. There is a long thread in the email archive, titeled "OSTC over BLE experiences and questions". Futher, there is a document called TIO Implementation guide. The latest version is not public any more (requires login from Telit), but obviously, I have the pdf of the version I used (r04) when working on the OSTC BLE interface in 2017. I will send it to Lubomir for further reference. --jan ___ 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 Jun 11, 2018, at 8:16 AM, Lubomir I. Ivanov wrote: >>> 2) so OSTC+ has a certain service with 4 WriteNoResponse >>> characteristics (no READ, WRITE-ONLY) which is supposedly the service >>> we have to use for communicating to the device. at least we assume >>> that in Subsurface but i don't see a concrete reason for this >>> assumption. we also assume that the first characteristic is the one we >>> want to write the "0xBB" to. >> >> This code was written based on documentation of the BLE stack that the >> OSTC implements. >> I wonder if the four characteristics are in the same order. It would be >> interesting >> to dump all the information we can get on the four of them both under Windows >> and Linux and see if this points at something odd. > > where can i find this documentation? > > if someone gives me the Linux UUIDs of the 4 chars i can compare. > even a dump of the whole successful operation of downloading dives > (command exchange etc) would help. Jan, could you help and provide Lubomir with that information? I unfortunately don’t have a working OSTC :-( /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 11 June 2018 at 18:16, Lubomir I. Ivanov wrote: > On 11 June 2018 at 17:49, Dirk Hohndel wrote: >> >>> On Jun 10, 2018, at 5:36 PM, Lubomir I. Ivanov wrote: >>> >>> On 10 June 2018 at 16:04, Lubomir I. Ivanov wrote: BT classical mode works - i was able to download 10 dives, that apparently already existed on the DC. i need to debug the BLE response from the device. >>> >>> status report: >>> so sadly i'm observing a multitude of problems here with this DC >>> (OSTC+) on Windows with BLE. >>> >>> 1) the native WINAPI does not have means to pair or connect to a BLE >>> devices programatically, which means that the user has to find the >>> devices using Control Panel methods and pair / connect to it manually. >> >> So how does the Control Panel do this, then, if there are no API calls >> to connect to a BLE device? > > it does it with calls that are not exposed to user space. > ...or rather only exposed with apps that are UWP based. the source code for BLE explorer is available at github and i see a class used for the pairing and this isn't available to the C API. 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 11 June 2018 at 17:49, Dirk Hohndel wrote: > >> On Jun 10, 2018, at 5:36 PM, Lubomir I. Ivanov wrote: >> >> On 10 June 2018 at 16:04, Lubomir I. Ivanov wrote: >>> >>> BT classical mode works - i was able to download 10 dives, that >>> apparently already existed on the DC. >>> i need to debug the BLE response from the device. >>> >> >> status report: >> so sadly i'm observing a multitude of problems here with this DC >> (OSTC+) on Windows with BLE. >> >> 1) the native WINAPI does not have means to pair or connect to a BLE >> devices programatically, which means that the user has to find the >> devices using Control Panel methods and pair / connect to it manually. > > So how does the Control Panel do this, then, if there are no API calls > to connect to a BLE device? it does it with calls that are not exposed to user space. > Case in point - DM5 does not require the user to somehow pair their > EON Steel with the computer, DM5 simply starts talking to it. Which makes > me think that we should try to just talk the OSTC and check if it responds... > it doesn't work for the OSTC. i've tried writing a native WINAPI test app, bypassing Qt, but there is no API for pairing or connecting. maybe there is a way to hack around it - waiting on response from QtConnectivty too. threads of interest: https://social.msdn.microsoft.com/Forums/vstudio/en-US/e321cb3c-462a-4b16-b7e4-febdb3d0c7d6/windows-10-pairing-a-ble-device-from-code?forum=wdk https://social.msdn.microsoft.com/Forums/en-US/65c9cf4e-e225-4fc3-8c2c-66cd2401d3ed/how-to-establish-a-connection-from-windows-8-pc-to-a-bluetooth-low-energy-device >> 2) so OSTC+ has a certain service with 4 WriteNoResponse >> characteristics (no READ, WRITE-ONLY) which is supposedly the service >> we have to use for communicating to the device. at least we assume >> that in Subsurface but i don't see a concrete reason for this >> assumption. we also assume that the first characteristic is the one we >> want to write the "0xBB" to. > > This code was written based on documentation of the BLE stack that the > OSTC implements. > I wonder if the four characteristics are in the same order. It would be > interesting > to dump all the information we can get on the four of them both under Windows > and Linux and see if this points at something odd. where can i find this documentation? if someone gives me the Linux UUIDs of the 4 chars i can compare. even a dump of the whole successful operation of downloading dives (command exchange etc) would help. > >> when i manually write the "0xBB" (INIT) command to the first >> characteristic the second characteristic becomes READ-ONLY and >> responds with 0x4D (READY) in "BLE explorer". i think the current >> BLE-Win32 stack in QtConnectivity does not handle that and the seconds >> characteristic remains WRITE-ONLY. this has to be discussed with >> QtConnectivity as well, i guess. > > If you write the 0xBB, do you get 0xBB anywhere on the characteristics that > you can see? after writing 0xBB to the first char, the second char (that suddenly becomes readable) either becomes "0xBB - 0x4D" or "0x4D". i don't know what dictates the differences here. > >> 3) i don't think we handle 2) well in Subsurface.also i don't have >> information if the BLE code in Subsurface and the code in >> libdivecomputer works for OSTC+ on other OSes... > > Linus and Jan should be able to answer most questions that you might have > on the BLE code / OSTC BLE interface. A lot of this is still rather fragile > and > hack-ish, but we should be able to figure out how this is supposed to work > and if you boot Linux on your laptop you should be able to create "identical" > interactions on Linux (where this all works) and Windows... i'm not allowed to dual boot this machine. my VMs have trouble gaining access to the BLE hardware - i can try that again. > >> i know that writing to a WriteNoResponse characteristic would not >> trigger our BLEObject::characteristicWritten(). >> BLEObject::characteristcStateChanged() also doesn't trigger. > > I don't understand what you are trying to tell us here. > writing to a characteristic that has the "WriteNoResponse" flag, means that no Qt signal will be emitted that someone wrote to that char. which means that a characteristicWritten() would not be reached. in the case of the OSTC+ we are writing to such a char (the first one). after that it becomes a question of how we detect if someone wrote to it in libdc or subsurface. i wasn't able to find the code for that, but please feel free to correct me as i was kind of tired when checking... >> this obviously needs more debugging, but not sure when i'm going to >> have more time - maybe tomorrow. >> also, i'm very interested how many people will respond to the testing >> request...3, 10, 30? > > Lots of people have these dive computers. The questions you are asking > is about the intersection of people who (a) have a Windows laptop with > BLE and one of these devices (large numbe
Re: [TEST REQUEST] Windows Bluetooth LE build
> On Jun 11, 2018, at 7:44 AM, Lubomir I. Ivanov wrote:
Your debug log doesn't actually have the IO that is done. That seems
to be a Qt issue. We ask for debug output, and some versions of Qt
will give that:
QLoggingCategory::setFilterRules(QStringLiteral("qt.bluetooth*
= true"));
and others will apparently just ignore it.
>>>
>>> Ubuntu installs a global file that overrides. It's up to the user to
>>> configure
>>> what output they want to see, not the application.
>>>
>>> The above line needs to be set by the user in the QT_LOGGING_RULES
>>> environment
>>> variable.
>>
>> So on Windows all we need to do is set that environment variable
>> to get the full debug output we want?
>>
>
> i've added this in the _run.cmd for the test package posted in this thread:
>set QT_LOGGING_RULES=qt.bluetooth*=true
>
> the same DLL outputs the qt.bluetooth* messages in a standalone
> application, so it seems that problem only happens in Subsurface.
> not sure why.
Well, I don't know how you build Qt and Subsurface in your binaries.
But if a sample app built against the same DLLs does show the output...
I'd start with commenting out our attempts to mess with the QLoggingCategory
(we do this in qt-ble.cpp and subsurface-desktop-main.cpp)
We also are using the messageHandler to intercept the qDebug messages.
That might be something worth playing with.
/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 Jun 10, 2018, at 5:36 PM, Lubomir I. Ivanov wrote: > > On 10 June 2018 at 16:04, Lubomir I. Ivanov wrote: >> >> BT classical mode works - i was able to download 10 dives, that >> apparently already existed on the DC. >> i need to debug the BLE response from the device. >> > > status report: > so sadly i'm observing a multitude of problems here with this DC > (OSTC+) on Windows with BLE. > > 1) the native WINAPI does not have means to pair or connect to a BLE > devices programatically, which means that the user has to find the > devices using Control Panel methods and pair / connect to it manually. So how does the Control Panel do this, then, if there are no API calls to connect to a BLE device? Case in point - DM5 does not require the user to somehow pair their EON Steel with the computer, DM5 simply starts talking to it. Which makes me think that we should try to just talk the OSTC and check if it responds... > 2) so OSTC+ has a certain service with 4 WriteNoResponse > characteristics (no READ, WRITE-ONLY) which is supposedly the service > we have to use for communicating to the device. at least we assume > that in Subsurface but i don't see a concrete reason for this > assumption. we also assume that the first characteristic is the one we > want to write the "0xBB" to. This code was written based on documentation of the BLE stack that the OSTC implements. I wonder if the four characteristics are in the same order. It would be interesting to dump all the information we can get on the four of them both under Windows and Linux and see if this points at something odd. > when i manually write the "0xBB" (INIT) command to the first > characteristic the second characteristic becomes READ-ONLY and > responds with 0x4D (READY) in "BLE explorer". i think the current > BLE-Win32 stack in QtConnectivity does not handle that and the seconds > characteristic remains WRITE-ONLY. this has to be discussed with > QtConnectivity as well, i guess. If you write the 0xBB, do you get 0xBB anywhere on the characteristics that you can see? > 3) i don't think we handle 2) well in Subsurface.also i don't have > information if the BLE code in Subsurface and the code in > libdivecomputer works for OSTC+ on other OSes... Linus and Jan should be able to answer most questions that you might have on the BLE code / OSTC BLE interface. A lot of this is still rather fragile and hack-ish, but we should be able to figure out how this is supposed to work and if you boot Linux on your laptop you should be able to create "identical" interactions on Linux (where this all works) and Windows... > i know that writing to a WriteNoResponse characteristic would not > trigger our BLEObject::characteristicWritten(). > BLEObject::characteristcStateChanged() also doesn't trigger. I don't understand what you are trying to tell us here. > this obviously needs more debugging, but not sure when i'm going to > have more time - maybe tomorrow. > also, i'm very interested how many people will respond to the testing > request...3, 10, 30? Lots of people have these dive computers. The questions you are asking is about the intersection of people who (a) have a Windows laptop with BLE and one of these devices (large number), (b) who've seen your announcement (a lot fewer), and (c) who feel comfortable that they can follow the instructions and make this work (that I expect to be a fairly small number - in part because this is not just "run this installer") I will leave on a two week trip on Wednesday and much as I love our users, I will not bring the Windows laptop on this trip. But since Jan is now able to play along, I hope that we'll be able to make progress nonetheless /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 11 June 2018 at 17:40, Dirk Hohndel wrote:
>
>> On Jun 11, 2018, at 4:47 AM, Thiago Macieira wrote:
>>
>> On Sunday, 10 June 2018 01:59:37 CEST Linus Torvalds wrote:
>>> Your debug log doesn't actually have the IO that is done. That seems
>>> to be a Qt issue. We ask for debug output, and some versions of Qt
>>> will give that:
>>>
>>>QLoggingCategory::setFilterRules(QStringLiteral("qt.bluetooth*
>>> = true"));
>>>
>>> and others will apparently just ignore it.
>>
>> Ubuntu installs a global file that overrides. It's up to the user to
>> configure
>> what output they want to see, not the application.
>>
>> The above line needs to be set by the user in the QT_LOGGING_RULES
>> environment
>> variable.
>
> So on Windows all we need to do is set that environment variable
> to get the full debug output we want?
>
i've added this in the _run.cmd for the test package posted in this thread:
set QT_LOGGING_RULES=qt.bluetooth*=true
the same DLL outputs the qt.bluetooth* messages in a standalone
application, so it seems that problem only happens in Subsurface.
not sure why.
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 Jun 11, 2018, at 4:47 AM, Thiago Macieira wrote:
>
> On Sunday, 10 June 2018 01:59:37 CEST Linus Torvalds wrote:
>> Your debug log doesn't actually have the IO that is done. That seems
>> to be a Qt issue. We ask for debug output, and some versions of Qt
>> will give that:
>>
>>QLoggingCategory::setFilterRules(QStringLiteral("qt.bluetooth*
>> = true"));
>>
>> and others will apparently just ignore it.
>
> Ubuntu installs a global file that overrides. It's up to the user to
> configure
> what output they want to see, not the application.
>
> The above line needs to be set by the user in the QT_LOGGING_RULES
> environment
> variable.
So on Windows all we need to do is set that environment variable
to get the full debug output we want?
/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 Jun 11, 2018, at 6:52 AM, Jan Mulder wrote: > > On 11-06-18 15:18, Jan Mulder wrote: > >> I will try to fire up my Windows machine, to check what is happing there >> in BLE context (but disclaimer: I'm far from a Windows developer). > > Tried the Windows BLE build on Windows 8.1. OSTC3 correctly paired on OS > level. Download over BT does work correctly, Download over BLE gives the same > parsing errors as Lubomirs test device (so nothing seems wrong with that > device). I'm curious, Jan. Can you use the BLE Explorer to try and manually interact with the OSTC3 and see if it sends the echo back at all? I got my Perdix AI into command mode and was able to interact with it - which makes me think that maybe we are "just" getting something wrong with the characteristics... /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 11 June 2018 at 16:52, Jan Mulder wrote: > On 11-06-18 15:18, Jan Mulder wrote: > >> >> I will try to fire up my Windows machine, to check what is happing there >> in BLE context (but disclaimer: I'm far from a Windows developer). > > > Tried the Windows BLE build on Windows 8.1. OSTC3 correctly paired on OS > level. Download over BT does work correctly, Download over BLE gives the > same parsing errors as Lubomirs test device (so nothing seems wrong with > that device). > thanks for confirming, at least now i know that my prototype device acts like a regular device. i wrote an email to the QtConnectivity maintainers and the lead WIN32 contributor to discuss some of the issues at hand here. i'm particularly interested in that particular characteristic that changes it's flags from "writable" to "readable" and how that should be handled. 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 11-06-18 15:18, Jan Mulder wrote: I will try to fire up my Windows machine, to check what is happing there in BLE context (but disclaimer: I'm far from a Windows developer). Tried the Windows BLE build on Windows 8.1. OSTC3 correctly paired on OS level. Download over BT does work correctly, Download over BLE gives the same parsing errors as Lubomirs test device (so nothing seems wrong with that device). --jan ___ 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 10 June 2018 at 16:04, Lubomir I. Ivanov wrote:
>>
>> BT classical mode works - i was able to download 10 dives, that
>> apparently already existed on the DC.
>> i need to debug the BLE response from the device.
>>
>
> status report:
> so sadly i'm observing a multitude of problems here with this DC
> (OSTC+) on Windows with BLE.
>
> 1) the native WINAPI does not have means to pair or connect to a BLE
> devices programatically, which means that the user has to find the
> devices using Control Panel methods and pair / connect to it manually.
> only at that point the GATT calls start working as the device services
> get mounted to virtual paths. Qt is also affected and i will discuss
> this with QtConnectivity.
>
> this has been the case since the BLE API release in Windows 8.1:
>
https://social.msdn.microsoft.com/Forums/en-US/65c9cf4e-e225-4fc3-8c2c-66cd2401d3ed/how-to-establish-a-connection-from-windows-8-pc-to-a-bluetooth-low-energy-device
>
> i found a comment that says that supposedly the Windows 10 "creator
> update" makes the GATT calls work without pairing, but i cannot
> confirm that as i have this ("whatever-")update installed.
>
> the weird thing is the "BLE explorer" application which is UWP based
> supports pairing and connection...to my understanding it uses C++
> calls that make it possible to pair / connect to a device and the same
> C++ calls are not available to non-UWP apps. i need to investigate
> this more.
>
> overall the state of BLE on Windows is quite poor according to users.
>
> i really need to see a report where a paired DC handles the GATT part.
> thus far the reports are only about DC not being paired (e.g. no mount
> paths).
>
> 2) so OSTC+ has a certain service with 4 WriteNoResponse
> characteristics (no READ, WRITE-ONLY) which is supposedly the service
> we have to use for communicating to the device. at least we assume
> that in Subsurface but i don't see a concrete reason for this
> assumption. we also assume that the first characteristic is the one we
> want to write the "0xBB" to.
>
> when i manually write the "0xBB" (INIT) command to the first
> characteristic the second characteristic becomes READ-ONLY and
> responds with 0x4D (READY) in "BLE explorer". i think the current
> BLE-Win32 stack in QtConnectivity does not handle that and the seconds
> characteristic remains WRITE-ONLY. this has to be discussed with
> QtConnectivity as well, i guess.
>
> 3) i don't think we handle 2) well in Subsurface.also i don't have
> information if the BLE code in Subsurface and the code in
> libdivecomputer works for OSTC+ on other OSes...
Subsurface and connected libdivecomputer did work perfectly with my
OSTC3 (which presents itself als OSTC Plus) some time ago. I even did
firmware upgrades over BLE (all on Linux). Just tested current master
for a normal download over BLE and that works (and it reminds me that I
do not like using BLE when classic BT is available (all Linux)).
> i know that writing to a WriteNoResponse characteristic would not
> trigger our BLEObject::characteristicWritten().
> BLEObject::characteristcStateChanged() also doesn't trigger.
>
> this obviously needs more debugging, but not sure when i'm going to
> have more time - maybe tomorrow.
> also, i'm very interested how many people will respond to the testing
> request...3, 10, 30?
I will try to fire up my Windows machine, to check what is happing there
in BLE context (but disclaimer: I'm far from a Windows developer).
--jan
___
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 Sunday, 10 June 2018 01:59:37 CEST Linus Torvalds wrote:
> Your debug log doesn't actually have the IO that is done. That seems
> to be a Qt issue. We ask for debug output, and some versions of Qt
> will give that:
>
> QLoggingCategory::setFilterRules(QStringLiteral("qt.bluetooth*
> = true"));
>
> and others will apparently just ignore it.
Ubuntu installs a global file that overrides. It's up to the user to configure
what output they want to see, not the application.
The above line needs to be set by the user in the QT_LOGGING_RULES environment
variable.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
