Re: Cleaned up and rebased "libdivecomputer-NG" branch

[Dirk Hohndel]

> On Apr 27, 2018, at 2:53 PM, Dirk Hohndel  wrote:
> 
> 
>> On Apr 27, 2018, at 2:49 PM, Lubomir I. Ivanov  wrote:
>> 
>>> Service "fe25c237-0ece-443c-b0aa-e02033e7029d" discovered (start: 9 end: 9 
>>> ) QLowEnergyServicePrivate(0xc5271c00)
>> 
>> just realized that 9 / 9 mean the start and end handle for this service.
>> so i guess that also confirms that the service has no characteristics
>> if they are equal.
> 
> That makes sense

More testing shows even less reasonable results.

Android only ever sees the Petrel 2 as type 2 (BLE only) device (even though it 
should
be a type 3 (dual stack) device).
Trying to force a BLE bonding from nRF Connect makes the BT stack crash.
Trying to download over BLE from Subsurface-mobile on Android fails as 
described.
But… ignoring the “BLE only” designation and instead downloading via rfcomm 
succeeds.

Hrmpf.

I guess I’ll have to add a special case for Petrel devices that if they fail on 
BLE they should
try BT after all, anyway? Not my preferred solution, but I’m not sure what else 
to try.

/D
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Cleaned up and rebased "libdivecomputer-NG" branch

[Dirk Hohndel]

> On Apr 27, 2018, at 2:49 PM, Lubomir I. Ivanov  wrote:
> 
>> Service "fe25c237-0ece-443c-b0aa-e02033e7029d" discovered (start: 9 end: 9 ) 
>> QLowEnergyServicePrivate(0xc5271c00)
> 
> just realized that 9 / 9 mean the start and end handle for this service.
> so i guess that also confirms that the service has no characteristics
> if they are equal.

That makes sense

> the origin of the handles comes from the java backend.
> the file hasn't seen activity since July 2017.
> 
> it might be hard to figure out what's going on unless some debug code
> is added in this java file near the callers of this function:
> https://github.com/qt/qtconnectivity/blob/5.10.1/src/android/bluetooth/src/org/qtproject/qt5/android/bluetooth/QtBluetoothLE.java#L867
> 
> the comment on top of the function says:
> "//TODO function not yet used"
> 
> yet, i see that's it's being used to make this JNI call
> "leServiceDetailDiscoveryFinished()" which reaches the C++ methods
> that trigger the debug messages such as the one above:
> "Service  discovered (…"

Interesting - definitely there are oddities in that Java code. I just noticed
that my dual stack Petrel 2 isn’t recognized as dual stack at all - only as
BT device.

>>> i guess this can be confirmed by this slot which should trigger when
>>> we start the service details discovery:
>>> https://github.com/Subsurface-divelog/subsurface/blob/master/core/qt-ble.cpp#L47
>>> 
>>> does the same service UUID have characteristics on iOS?
>>> if yes, i think this might be a bug in qt-ble-android.
>>> 
>>> btw, what Qt version is this for Android?
>> 
>> We are still on 5.9.3.
>> I need to figure out why 5.10.1 didn’t build as intended
>> 
> 
> i think that the issue comes from the java backend which hasn't seen
> new contributions, so this could still be present in the latest Qt
> too.
> i would try with another device to narrow down if this is an issue
> with the Android OS version with the Android device BLE hardware.

I’ll have to see what other Android devices I have that support BLE and
have a different Android OS version - since I tend to update fairly actively
to deal with the security issues in Android, I’m not sure how much luck I’m
going to have there…

/D
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Cleaned up and rebased "libdivecomputer-NG" branch

[Lubomir I. Ivanov]

On 28 April 2018 at 00:03, Dirk Hohndel  wrote:
>
>> On Apr 27, 2018, at 1:48 PM, Lubomir I. Ivanov  wrote:
>>>
>>> I switched to a newer Qt version - it would be strange for them to disable
>>> something as critical as this, but definitely worth investigating further.
>
> It seems that I DIDN’T switch to a newer Qt after all. Strange. Something is 
> mixed
> up in my build script it seems.
>
>> i don't see any changes here that disable debugging output:
>> https://github.com/qt/qtconnectivity/blob/5.10/src/bluetooth/qlowenergycontroller_android.cpp
>> (same goes for 5.10.1 and the 5.11 branches)
>> .
>> the log entry "Service discovery initiated" can be seen and it's
>> visibility is controlled by the same logging rules as those for
>> reading and writing of characteristics and descriptors.
>>
>>> Service "fe25c237-0ece-443c-b0aa-e02033e7029d" discovered (start: 9 end: 9 
>>> ) QLowEnergyServicePrivate(0xc5271c00)
>>
>> ^ so a non-standard service is found here.
>>
>>> .. done discovering services
>>> .. discovering details
>>> .. enabling notifications
>>
>> https://github.com/Subsurface-divelog/subsurface/blob/master/core/qt-ble.cpp#L377
>>
>> at this point given this isn't a HW DC (Shearwater instead?) it should
>> list the descriptors for this service's last characteristic if the
>> service has characteristics.
>> i think the list of characteristics is empty.
>
> It doesn’t seem impossible, given all the issues with their BT/BLE stack
>
>

> Service "fe25c237-0ece-443c-b0aa-e02033e7029d" discovered (start: 9 end: 9 ) 
> QLowEnergyServicePrivate(0xc5271c00)

just realized that 9 / 9 mean the start and end handle for this service.
so i guess that also confirms that the service has no characteristics
if they are equal.

the origin of the handles comes from the java backend.
the file hasn't seen activity since July 2017.

it might be hard to figure out what's going on unless some debug code
is added in this java file near the callers of this function:
https://github.com/qt/qtconnectivity/blob/5.10.1/src/android/bluetooth/src/org/qtproject/qt5/android/bluetooth/QtBluetoothLE.java#L867

the comment on top of the function says:
"//TODO function not yet used"

yet, i see that's it's being used to make this JNI call
"leServiceDetailDiscoveryFinished()" which reaches the C++ methods
that trigger the debug messages such as the one above:
"Service  discovered (..."

>> i guess this can be confirmed by this slot which should trigger when
>> we start the service details discovery:
>> https://github.com/Subsurface-divelog/subsurface/blob/master/core/qt-ble.cpp#L47
>>
>> does the same service UUID have characteristics on iOS?
>> if yes, i think this might be a bug in qt-ble-android.
>>
>> btw, what Qt version is this for Android?
>
> We are still on 5.9.3.
> I need to figure out why 5.10.1 didn’t build as intended
>

i think that the issue comes from the java backend which hasn't seen
new contributions, so this could still be present in the latest Qt
too.
i would try with another device to narrow down if this is an issue
with the Android OS version with the Android device BLE hardware.

lubomir
--
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Cleaned up and rebased "libdivecomputer-NG" branch

[Dirk Hohndel]

> On Apr 27, 2018, at 1:48 PM, Lubomir I. Ivanov  wrote:
>> 
>> I switched to a newer Qt version - it would be strange for them to disable
>> something as critical as this, but definitely worth investigating further.

It seems that I DIDN’T switch to a newer Qt after all. Strange. Something is 
mixed
up in my build script it seems.

> i don't see any changes here that disable debugging output:
> https://github.com/qt/qtconnectivity/blob/5.10/src/bluetooth/qlowenergycontroller_android.cpp
> (same goes for 5.10.1 and the 5.11 branches)
> .
> the log entry "Service discovery initiated" can be seen and it's
> visibility is controlled by the same logging rules as those for
> reading and writing of characteristics and descriptors.
> 
>> Service "fe25c237-0ece-443c-b0aa-e02033e7029d" discovered (start: 9 end: 9 ) 
>> QLowEnergyServicePrivate(0xc5271c00)
> 
> ^ so a non-standard service is found here.
> 
>> .. done discovering services
>> .. discovering details
>> .. enabling notifications
> 
> https://github.com/Subsurface-divelog/subsurface/blob/master/core/qt-ble.cpp#L377
> 
> at this point given this isn't a HW DC (Shearwater instead?) it should
> list the descriptors for this service's last characteristic if the
> service has characteristics.
> i think the list of characteristics is empty.

It doesn’t seem impossible, given all the issues with their BT/BLE stack


> i guess this can be confirmed by this slot which should trigger when
> we start the service details discovery:
> https://github.com/Subsurface-divelog/subsurface/blob/master/core/qt-ble.cpp#L47
> 
> does the same service UUID have characteristics on iOS?
> if yes, i think this might be a bug in qt-ble-android.
> 
> btw, what Qt version is this for Android?

We are still on 5.9.3.
I need to figure out why 5.10.1 didn’t build as intended

/D
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Cleaned up and rebased "libdivecomputer-NG" branch

[Lubomir I. Ivanov]

On 27 April 2018 at 22:46, Dirk Hohndel  wrote:
>
>> On Apr 27, 2018, at 11:46 AM, Linus Torvalds  
>> wrote:
>>
>> Hmm. I'm not seeing any errors here either, but I'm surprised to not see
>> any actual *communication* debugging.
>>
>> I wonder if that got turned off in your version of Qt? Because all the
>> messages above are our _own_ qdebug output.
>>
>> The actual *data* transfer debugging is from qt itself, and we turn it on
>> and off with
>>
>> QLoggingCategory::setFilterRules(QStringLiteral("qt.bluetooth* =
>> true"));
>> QLoggingCategory::setFilterRules(QStringLiteral("qt.bluetooth* =
>> false"));
>>
>> and I wonder if maybe Qt itself stopped doing those debug messages?
>>
>> For example, on my desktop, I see not just the "Found service" messages
>> that we output, I also see a lot of other debug data from Qt itself:
>>
>>   ..
>>   Sending read_by_group_type request, startHandle: b endHandle:  2800
>>   Received size: 22 data: "11140b009d02e73320e0aab03c44ce0e37c225fe"
>>   Found uuid: "{fe25c237-0ece-443c-b0aa-e02033e7029d}" start handle: b end
>> handle: 
>>   Found service "{fe25c237-0ece-443c-b0aa-e02033e7029d}"
>>   ..
>>
>> and your log doesn't have any of that. So then the fact that you *also*
>> don't have the actual IO debugging actually makes sense.
>
> I switched to a newer Qt version - it would be strange for them to disable
> something as critical as this, but definitely worth investigating further.
>

i don't see any changes here that disable debugging output:
https://github.com/qt/qtconnectivity/blob/5.10/src/bluetooth/qlowenergycontroller_android.cpp
(same goes for 5.10.1 and the 5.11 branches)
.
the log entry "Service discovery initiated" can be seen and it's
visibility is controlled by the same logging rules as those for
reading and writing of characteristics and descriptors.

> Service "fe25c237-0ece-443c-b0aa-e02033e7029d" discovered (start: 9 end: 9 ) 
> QLowEnergyServicePrivate(0xc5271c00)

^ so a non-standard service is found here.

>  .. done discovering services
> .. discovering details
> .. enabling notifications

https://github.com/Subsurface-divelog/subsurface/blob/master/core/qt-ble.cpp#L377

at this point given this isn't a HW DC (Shearwater instead?) it should
list the descriptors for this service's last characteristic if the
service has characteristics.
i think the list of characteristics is empty.

i guess this can be confirmed by this slot which should trigger when
we start the service details discovery:
https://github.com/Subsurface-divelog/subsurface/blob/master/core/qt-ble.cpp#L47

does the same service UUID have characteristics on iOS?
if yes, i think this might be a bug in qt-ble-android.

btw, what Qt version is this for Android?

lubomir
--
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Cleaned up and rebased "libdivecomputer-NG" branch

[Dirk Hohndel]

> On Apr 27, 2018, at 11:46 AM, Linus Torvalds  
> wrote:
>> I then finally got Android to connect at all.
> 
> Ok, so the firmware update at least made some change. That's a good sign,
> in that it does imply that at least _some_ of the problems were due to a
> bug that the Shearwater people knew about and fixed.

Yes - but there’s still something seriously broken when talking to Android
devices - both using Subsurface and Sheawater’s own app.
>> Deleting BLE object
>> "4.929: No new dives downloaded from dive computer"
> 
> Hmm. I'm not seeing any errors here either, but I'm surprised to not see
> any actual *communication* debugging.
> 
> I wonder if that got turned off in your version of Qt? Because all the
> messages above are our _own_ qdebug output.
> 
> The actual *data* transfer debugging is from qt itself, and we turn it on
> and off with
> 
> QLoggingCategory::setFilterRules(QStringLiteral("qt.bluetooth* =
> true"));
> QLoggingCategory::setFilterRules(QStringLiteral("qt.bluetooth* =
> false"));
> 
> and I wonder if maybe Qt itself stopped doing those debug messages?
> 
> For example, on my desktop, I see not just the "Found service" messages
> that we output, I also see a lot of other debug data from Qt itself:
> 
>   ..
>   Sending read_by_group_type request, startHandle: b endHandle:  2800
>   Received size: 22 data: "11140b009d02e73320e0aab03c44ce0e37c225fe"
>   Found uuid: "{fe25c237-0ece-443c-b0aa-e02033e7029d}" start handle: b end
> handle: 
>   Found service "{fe25c237-0ece-443c-b0aa-e02033e7029d}"
>   ..
> 
> and your log doesn't have any of that. So then the fact that you *also*
> don't have the actual IO debugging actually makes sense.

I switched to a newer Qt version - it would be strange for them to disable
something as critical as this, but definitely worth investigating further.

>> Finishing the thread Dive data import error dives downloaded 0
>> no new dives downloaded
>> "4.932: DCDownloadThread finished”
> 
> Because this would all be successful for the "no dives on the dive
> computer" case other than the complete lack of debug messages..
> 
>> So we are successfully connecting, are discovering the services and then
> we give
>> up right away. Not sure if this adds any more useful information, but I
> thought I’d
>> pass it along.
> 
> I think "we give up right away" may actually be "we exchanged just a couple
> of packets and found that there were no dives".
> 
> Did the firmware update perhaps reset the dive computer entirely and remove
> all dives on the dive computer?

Nope. I just completed an iOS build with the latest code and that connected
without a problem and downloaded the 20 dives on this dive computer via
BLE. This is with the current master.

/D
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Cleaned up and rebased "libdivecomputer-NG" branch

[Linus Torvalds]

On Fri, Apr 27, 2018 at 11:25 AM Dirk Hohndel  wrote:

> Through literally several dozen tries and reboots and random sequences, I
got my
> old BT-only Mac to connect with the Petrel 2 in order to do a Firmware
update to
> the latest (53).
> I then finally got Android to connect at all.

Ok, so the firmware update at least made some change. That's a good sign,
in that it does imply that at least _some_ of the problems were due to a
bug that the Shearwater people knew about and fixed.

> This is in no cloud mode, empty log file:

> "4.696: DCDownloadThread started for Petrel 2 on LE:00:13:43:0D:2B:30"
> Starting download from  BT
> Starting the thread 0
> "4.698: dc_descriptor_get_transports"
> "4.698: SERIAL BT BLE "
> "4.698: get_supported_transports returns"
> "4.698: BLE "
> Creating Android Central/Client support for BTLE
> qt_ble_open( 00:13:43:0D:2B:30 )
> Connection updated: error: QLowEnergyController::Error(NoError) oldState:
QLowEnergyController::ControllerState(ConnectingState) newState:
QLowEnergyController::ControllerState(ConnectedState)
> connected to the controller for device 00:13:43:0D:2B:30
>.. discovering services
> Service discovery initiated
> Found service "{1800--1000-8000-00805f9b34fb}"
>   .. ignoring standard service
> Found service "{180a--1000-8000-00805f9b34fb}"
>   .. ignoring standard service
> Found service "{fe25c237-0ece-443c-b0aa-e02033e7029d}"
>   .. created service object QLowEnergyService(0xc52d6de0)
> Discovery of "{fe25c237-0ece-443c-b0aa-e02033e7029d}" started
> Service "fe25c237-0ece-443c-b0aa-e02033e7029d" discovered (start: 9 end:
9 ) QLowEnergyServicePrivate(0xc5271c00)
>   .. done discovering services
>   .. discovering details
>   .. enabling notifications

Ok, this all looks successful.

> Deleting BLE object
> "4.929: No new dives downloaded from dive computer"

Hmm. I'm not seeing any errors here either, but I'm surprised to not see
any actual *communication* debugging.

I wonder if that got turned off in your version of Qt? Because all the
messages above are our _own_ qdebug output.

The actual *data* transfer debugging is from qt itself, and we turn it on
and off with

 QLoggingCategory::setFilterRules(QStringLiteral("qt.bluetooth* =
true"));
 QLoggingCategory::setFilterRules(QStringLiteral("qt.bluetooth* =
false"));

and I wonder if maybe Qt itself stopped doing those debug messages?

For example, on my desktop, I see not just the "Found service" messages
that we output, I also see a lot of other debug data from Qt itself:

   ..
   Sending read_by_group_type request, startHandle: b endHandle:  2800
   Received size: 22 data: "11140b009d02e73320e0aab03c44ce0e37c225fe"
   Found uuid: "{fe25c237-0ece-443c-b0aa-e02033e7029d}" start handle: b end
handle: 
   Found service "{fe25c237-0ece-443c-b0aa-e02033e7029d}"
   ..

and your log doesn't have any of that. So then the fact that you *also*
don't have the actual IO debugging actually makes sense.

> Finishing the thread Dive data import error dives downloaded 0
> no new dives downloaded
> "4.932: DCDownloadThread finished”

Because this would all be successful for the "no dives on the dive
computer" case other than the complete lack of debug messages..

> So we are successfully connecting, are discovering the services and then
we give
> up right away. Not sure if this adds any more useful information, but I
thought I’d
> pass it along.

I think "we give up right away" may actually be "we exchanged just a couple
of packets and found that there were no dives".

Did the firmware update perhaps reset the dive computer entirely and remove
all dives on the dive computer?

   Linus
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Cleaned up and rebased "libdivecomputer-NG" branch

[Dirk Hohndel]

So Shearwater is not going to win any awards for their Bluetooth implementation,
that seems pretty sure.
Through literally several dozen tries and reboots and random sequences, I got my
old BT-only Mac to connect with the Petrel 2 in order to do a Firmware update to
the latest (53).
I then finally got Android to connect at all. This is in no cloud mode, empty 
log file:

"4.696: DCDownloadThread started for Petrel 2 on LE:00:13:43:0D:2B:30"
Starting download from  BT
Starting the thread 0
"4.698: dc_descriptor_get_transports"
"4.698: SERIAL BT BLE "
"4.698: get_supported_transports returns"
"4.698: BLE "
Creating Android Central/Client support for BTLE
qt_ble_open( 00:13:43:0D:2B:30 )
Connection updated: error: QLowEnergyController::Error(NoError) oldState: 
QLowEnergyController::ControllerState(ConnectingState) newState: 
QLowEnergyController::ControllerState(ConnectedState)
connected to the controller for device 00:13:43:0D:2B:30
  .. discovering services
Service discovery initiated
Found service "{1800--1000-8000-00805f9b34fb}"
 .. ignoring standard service
Found service "{180a--1000-8000-00805f9b34fb}"
 .. ignoring standard service
Found service "{fe25c237-0ece-443c-b0aa-e02033e7029d}"
 .. created service object QLowEnergyService(0xc52d6de0)
Discovery of "{fe25c237-0ece-443c-b0aa-e02033e7029d}" started
Service "fe25c237-0ece-443c-b0aa-e02033e7029d" discovered (start: 9 end: 9 ) 
QLowEnergyServicePrivate(0xc5271c00)
 .. done discovering services
 .. discovering details
 .. enabling notifications
Deleting BLE object
"4.929: No new dives downloaded from dive computer"
Finishing the thread Dive data import error dives downloaded 0
no new dives downloaded
"4.932: DCDownloadThread finished”

So we are successfully connecting, are discovering the services and then we give
up right away. Not sure if this adds any more useful information, but I thought 
I’d
pass it along.

/D
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Any brave dive computer download testers out there?

[Dirk Hohndel]

> On Apr 27, 2018, at 7:29 AM, Jef Driesen  wrote:
> 
> The fingerprint usually contains the raw date/time data, but it depends on 
> the dive computer. Why should the application need to know what's inside? It 
> only needs to store the data somewhere until the next download.

This is our usual argument, Jef. You like black boxes and abstractions. We (as 
the app using libdivecomputer) would prefer having more control and fewer 
abstractions, as often the abstractions that you chose don't work for us as 
well as one might hope.

Additionally, I don't think that the issues around using libdivecomputer across 
multiple devices that share dive information is something that is fully 
appreciated in your design. And of course our desire not to store unnecessary, 
basically redundant data.

> Using something less arbitrary for the fingerprint data, like a hash over the 
> dive data or even the date/time of the dive, doesn't work. There are several 
> reasons for that:
> 
> 1. As explained before, the Uwatec/Scubapro protocol requires sending the 
> timestamp to the dive computer. That already rules out the use of a hash, 
> because we can't retrieve the timestamp back from the hash. Even using the 
> date/time is tricky here, because this timestamp should be relative to the 
> device clock, not the host clock. Since some of those devices rely on the 
> host clock for parsing the date/time, that means you would have to store 
> those values as well. Using the raw dive timestamp as the fingerprint doesn't 
> have those problems.
> 
> 2. Many dive computer protocols support downloading some kind of index with a 
> summary of the available dives. That allows libdivecomputer to check the 
> fingerprint and decide which dives need to be downloaded before actually 
> downloading the dive. That's not only a bit more efficient, but it also 
> allows to deliver much more accurate progress events. That improves the user 
> experience. So this is not only about being a little bit faster. But this is 
> only possible if libdivecomputer can use whatever information is available in 
> the index that can uniquely identify a single dive, and that's of course 
> different for each protocol. Hence the need to use arbitrary data.
> 
> So even if you don't really care about this last argument, then how would you 
> handle the first one?

I don't think there's a lot of point re-hashing these arguments. I actually see 
how this approach that you have taken is valid to solve the problem you were 
trying to solve.
And I'm not 100% convinced that our current approach is the right one - this is 
something where I need to find time to think about the design and come up with 
maybe a better alternative (and then I get to argue with Linus :-) )

> The only alternative solution that I can think of is to replace the 
> fingerprint with the raw dive data itself. That way, the feature would still 
> work exactly the same as before, but with the entire dive as the fingerprint. 
> Internally libdivecomputer can still extract and use whatever piece of info 
> it needs for its implementation. The disadvantage is that you now need to 
> store the entire dive (which is a lot larger than just the fingerprint), but 
> at least it's some more meaningful data.

That seems quite silly - it only makes the "random binary data" argument worse.

/D
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Any brave dive computer download testers out there?

[Jef Driesen]

On 2018-04-23 19:07, Linus Torvalds wrote:

On Mon, Apr 23, 2018 at 12:56 AM, Sébastien Dugué
 wrote:

On Sun, Apr 22, 2018 at 10:09 PM, Linus Torvalds
 wrote:


It still has the exact same problem it always had: it's random binary 
data

that we'd have to encode some way.


  Well, it's not so random. It's in fact a timestamp in the DC format 
which

specifies from which dive we wish to download.


I wish that was the case. It's not.

It's a timestamp on _some_ dive computers. On others, it's other random 
data.


On most dive computers, it's 4 bytes, on others it's 5-6, and on some
it's 16 bytes of random binary data.

On many dive computers it's entirely pointless (yes, yes, you may be
able to avoid downloading that one last dive), but they still have a
fingerprint, and there's no way to know "don't bother".

So to really get it right and download the least amount of dives you 
have to:


 - encode this insane random binary data without knowing what it is

 - also encode the insane garbage "serial number" (that isn't actually
a valid serial number at all, and hasn't even been stable across
libdivecomputer versions)

 - then before downloading, match the garbage serial number and
vendor/device string to find the last dive with that dive computer, in
order to find the other garbage random binary data

honestly, it's nasty nasty nasty.

What we *could* do is to do it knowingly wrong, the way dctool does
it: don't save the fingerprint data with the real dive data at all,
just have a random "last download" cache indexed by device family and
serial number.

That's how the feature is designed to be used, and it would avoid the
nasty "pollute our logs with meaningless and badly defined crazy data
that will never be useful in the future".

"So why don't you do that, then?" I hear you say.

It's probably the best approach, and works fine if you just always
download from the same device (because the cache would be specific to
the installation, not be part of our dive data). And when it doesn't
work, arguably we wouldn't be in any worse condition that we already
are in (ie "download everything" from the devices that can't download
dives one by one), so why not?

The "why not" is because it makes re-downloading dives much nastier.
If you actually want to re-download dives (maybe because you didn't
save the dives after the last download due to some other problem?) you
now need a way to clear the cache data. And the "download all dives"
thing could do that, but then  you wouldn't have the existing "don't
duplicate dives" that we *currently* have.

But it also means that when you download from the same dive computer
on a different device (ie your phone vs your laptop), you'll get get
potentiall ydifferent results. It can be very confusing.

So it's a hack, but it might be acceptable. As long as I don't have to
save that stupid fingerprint - and that broken serial number that
isn't - in the logs, I'm certainly happier with it.


The fingerprint usually contains the raw date/time data, but it depends 
on the dive computer. Why should the application need to know what's 
inside? It only needs to store the data somewhere until the next 
download.


Using something less arbitrary for the fingerprint data, like a hash 
over the dive data or even the date/time of the dive, doesn't work. 
There are several reasons for that:


1. As explained before, the Uwatec/Scubapro protocol requires sending 
the timestamp to the dive computer. That already rules out the use of a 
hash, because we can't retrieve the timestamp back from the hash. Even 
using the date/time is tricky here, because this timestamp should be 
relative to the device clock, not the host clock. Since some of those 
devices rely on the host clock for parsing the date/time, that means you 
would have to store those values as well. Using the raw dive timestamp 
as the fingerprint doesn't have those problems.


2. Many dive computer protocols support downloading some kind of index 
with a summary of the available dives. That allows libdivecomputer to 
check the fingerprint and decide which dives need to be downloaded 
before actually downloading the dive. That's not only a bit more 
efficient, but it also allows to deliver much more accurate progress 
events. That improves the user experience. So this is not only about 
being a little bit faster. But this is only possible if libdivecomputer 
can use whatever information is available in the index that can uniquely 
identify a single dive, and that's of course different for each 
protocol. Hence the need to use arbitrary data.


So even if you don't really care about this last argument, then how 
would you handle the first one?



The only alternative solution that I can think of is to replace the 
fingerprint with the raw dive data itself. That way, the feature would 
still work exactly the same as before, but with the entire dive as the 
fingerprint. 

Re: Build Ubuntu 18.04

[Lubomir I. Ivanov]

hi,

On 27 April 2018 at 13:32, Martin Měřinský  wrote:
> Hi,
> for latest Ubuntu, qtdeclarative5-private-dev package is missing in
> packages list in INSTALL file.
>

Ubuntu should have a package for this one i think?
feel free to send a patch for INSTALL.

> But I'm not able to build it anyway.
>
> ./subsurface/scripts/build.sh
>
> /data/ss/googlemaps/qgeotiledmapgooglemaps.h:4:10: fatal error:
> QtLocation/private/qgeotiledmap_p.h: No such file or directory
>  #include "QtLocation/private/qgeotiledmap_p.h"
>   ^
> compilation terminated.
>



we do have a section in build.sh that tries to pull the private
headers for qt-location and qt-pisitioning:
https://github.com/Subsurface-divelog/subsurface/blob/master/scripts/build.sh#L148

the above errors suggests that this build.sh code isn't working. i
guess you need to find out why.
try adding some "echo" calls in there to see what succeeds and also
look at your folder structure for the private headers.

thanks
lubomir
--
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Build Ubuntu 18.04

[Martin Měřinský]

Hi,
for latest Ubuntu, qtdeclarative5-private-dev package is missing in
packages list in INSTALL file.

But I'm not able to build it anyway.

./subsurface/scripts/build.sh

/data/ss/googlemaps/qgeotiledmapgooglemaps.h:4:10: fatal error:
QtLocation/private/qgeotiledmap_p.h: No such file or directory
 #include "QtLocation/private/qgeotiledmap_p.h"
  ^
compilation terminated.

/data/ss/googlemaps/qgeotiledmappingmanagerenginegooglemaps.h:4:10:
fatal error: QtLocation/private/qgeotiledmappingmanagerengine_p.h: No
such file or directory
 #include "QtLocation/private/qgeotiledmappingmanagerengine_p.h"
  ^~
compilation terminated.

/data/ss/googlemaps/qgeomapreplygooglemaps.h:5:10: fatal error:
QtLocation/private/qgeotilespec_p.h: No such file or directory
 #include 
  ^
compilation terminated.

/data/ss/googlemaps/qplacemanagerenginegooglemaps.cpp:13:10: fatal
error: QtLocation/private/unsupportedreplies_p.h: No such file or
directory
 #include 
  ^~~
compilation terminated.

Can someone please help? Thanks.
Martin M.
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Any brave dive computer download testers out there?

[Willem Ferguson]

On 26/04/2018 18:21, Linus Torvalds wrote:

On Thu, Apr 26, 2018 at 7:44 AM, Jef Driesen  wrote:

I also don't know the exact details on how these port numbers are assigned.
I guess it depends on the dive computer firmware and/or its bluetooth stack.
The valid range for rfcomm ports is 1-30 if I remember correctly.

The Petrel is certainly not the only one which is using a different port
number. I'm currently testing the divecomputer.eu and it seems to use port
6.

Ok, sounds like we should use port 0 too.

And that really makes most of the special cases just go away. So a
patch like the attached.

Dirk? Anybody with an rfcomm device? Willing to test the attached
"remove all the crazy crud" patch?

  Linus

I tried this patch on V4.7.8-82

I get no download, errors.

Starting download from  BT
Starting the thread 0
Failed to connect to device  00:13:43:5B:8F:BE . Device state 
QBluetoothSocket::UnconnectedState . Error: 
QBluetoothSocket::UnknownSocketError
[4.755321] ERROR: No such file or directory (2) [in 
../../src/serial_posix.c:295 (dc_serial_open)]

Finishing the thread Unable to open %s %s (%s) dives downloaded 0

Hope this helps to solve the rfcomm issue.

Kind regards,
willem


--
This message and attachments are subject to a disclaimer.

Please refer to 
http://upnet.up.ac.za/services/it/documentation/docs/004167.pdf 
 for
full 
details.

___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface