Re: [TEST REQUEST] Windows Bluetooth LE build

[Lubomir I. Ivanov]

On 27 September 2018 at 07:38, Dirk Hohndel  wrote:
>
>> On Sep 26, 2018, at 9:34 PM, Lubomir I. Ivanov  wrote:
>>
>> On 27 September 2018 at 07:31, Steve  wrote:
>>>
>>> No I haven't tested more than this once yet.
>>> I have put the battery on charge and I will test again with a full battery 
>>> as it was downloading for a long time so it could be low battery but will 
>>> confirm later.
>>
>> something to note here is that my DC is a prototype and it only has 10 dives.
>> so they download fairly quick.
>
> Are you coming to Sofia next week, Lubomir? I could bring another dive 
> computer for you to test with.
> One with more dives on it :-)
>

yes, bring some BLE DCs please.

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

[Dirk Hohndel]

> On Sep 26, 2018, at 9:34 PM, Lubomir I. Ivanov  wrote:
> 
> On 27 September 2018 at 07:31, Steve  wrote:
>> 
>> No I haven't tested more than this once yet.
>> I have put the battery on charge and I will test again with a full battery 
>> as it was downloading for a long time so it could be low battery but will 
>> confirm later.
> 
> something to note here is that my DC is a prototype and it only has 10 dives.
> so they download fairly quick.

Are you coming to Sofia next week, Lubomir? I could bring another dive computer 
for you to test with.
One with more dives on it :-)

But this is very encouraging to see progress!

/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

[Lubomir I. Ivanov]

On 27 September 2018 at 07:31, Steve  wrote:
>
> No I haven't tested more than this once yet.
> I have put the battery on charge and I will test again with a full battery as 
> it was downloading for a long time so it could be low battery but will 
> confirm later.
>

thanks,

something to note here is that my DC is a prototype and it only has 10 dives.
so they download fairly quick.

it if fails again might a good idea to share the logs and libdc dump.
you can zip them and attach to an email or via some file sharing
service if they are too big.

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

[Steve]

also double check the batter state.
i try to keep the battery full while testing.

lubomir
--

I had the exact same thought :)

Steve

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

RE: [TEST REQUEST] Windows Bluetooth LE build

[Steve]

On 27 September 2018 at 07:16, Steve  wrote:
>
> May have spoken too soon.
> Got an error dialog with "Dive data import error" message
>
> Last bit of the cmd window log below:

thanks a lot for testing!!

did you try more than once e.g. restarting and trying again?
it worked nicely for me 2 of 2 times for this OSTC+ unit.

> QTime("13:36:36.353") packet READ ""
> read 20
> QTime("13:36:36.354") packet WAIT
> QTime("13:36:48.367") packet SEND "ff"
> read 20
> QTime("13:36:48.375") packet WAIT
> QTime("13:36:48.508") packet RECV "4cff"
> QTime("13:36:48.508") packet READ "4cff"
> Deleting BLE object
> Finishing download thread: "Dive data import error"
> Set the current dive site: 72475123
> Set the current dive site: 72475123
>

this is entering the land of protocols and such in libdivecomputer that i don't 
understand.
so i'm going to have to defer to others.

i guess the biggest point here is that the BTLE Win32 stack works.

lubomir
--



No I haven't tested more than this once yet.
I have put the battery on charge and I will test again with a full battery as 
it was downloading for a long time so it could be low battery but will confirm 
later.

Steve

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

Re: [TEST REQUEST] Windows Bluetooth LE build

[Lubomir I. Ivanov]

On 27 September 2018 at 07:16, Steve  wrote:
>

also double check the batter state.
i try to keep the battery full while testing.

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

[Lubomir I. Ivanov]

On 27 September 2018 at 07:16, Steve  wrote:
>
> May have spoken too soon.
> Got an error dialog with "Dive data import error" message
>
> Last bit of the cmd window log below:

thanks a lot for testing!!

did you try more than once e.g. restarting and trying again?
it worked nicely for me 2 of 2 times for this OSTC+ unit.

> QTime("13:36:36.353") packet READ ""
> read 20
> QTime("13:36:36.354") packet WAIT
> QTime("13:36:48.367") packet SEND "ff"
> read 20
> QTime("13:36:48.375") packet WAIT
> QTime("13:36:48.508") packet RECV "4cff"
> QTime("13:36:48.508") packet READ "4cff"
> Deleting BLE object
> Finishing download thread: "Dive data import error"
> Set the current dive site: 72475123
> Set the current dive site: 72475123
>

this is entering the land of protocols and such in libdivecomputer
that i don't understand.
so i'm going to have to defer to others.

i guess the biggest point here is that the BTLE Win32 stack works.

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

[Steve]

looks like the recent libdc + BLE refactor in Subsurface fixed the issues i was 
having downloading from the OSTC+ on Windows, with my custom Qt build.
so it wasn't an issue in the Qt stack.

thanks goes to Linus, because i was stuck on this not being able to figure out 
what's going on for a long time...

log for proof:
https://pastebin.com/7DHZU855

--

link for testing my latest Subsurface test build for BLE on Win32:
https://www.dropbox.com/s/zslq3ughx9ciehj/_deploy_win32_ble.zip?dl=0

instructions:

prerequisites:
- minimum Windows version for this is 8.1
- make sure that Windows has detected and paired with your DC

steps:
- extract the _deploy_win32_ble.zip ZIP in a folder somewhere
- navigate to the folder with Explorer and start _run.cmd
- a console window should open and next to it the Subsurface window
- start your BLE dive-computer and make it ready for downloading of dives
- in Subsurface goto Import -> Download from divecomputer
- select the following options (and pick paths):
 [x] Save libdivecomputer dumpfile
 [x] Save libdivecomputer logfile
- select the following option:
 [x] Choose bluetooth download mode
- a dialog should open. select "Force LE" for mode, and click "Scan".
- your device should appear in the list. select it and click "Save"
- the "Device or mount point" field should now show your DC.
- click "Download".

report back logs and dump files if it doesn't work for you.

lubomir
--


Looks like it is working well on Windows 10.
I have started to download with the OSTC3+ and it shows about 10% done at the 
moment.
Sample from cmd window below:

read 20
QTime("13:00:55.270") packet WAIT
QTime("13:00:55.304") packet RECV "cf0200d802169aab"
QTime("13:00:55.304") packet RECV "2300de0200eb0200ee0200cf0200"
QTime("13:00:55.306") packet RECV "d40200d302049ab1cf0200ce0200ce0200ca"
QTime("13:00:55.307") packet RECV "0200d70200e002169a9f"
QTime("13:00:55.307") packet READ "cf0200d802169aab"
read 20

I modified your _run.cmd to so it can capture everything as the windows cmd 
window doesn't have a very big scroll buffer:

@echo off
set QT_PLUGIN_PATH=.\plugins
set QT_LOGGING_RULES=qt.bluetooth*=true
subsurface.exe -v -v > cmdwindow.log
pause

Let me know if you actually want the all logs or not.

I can also test the Petrel2 Ext. later tonight if you want just let me know.

Cheers,
Steve


May have spoken too soon.
Got an error dialog with "Dive data import error" message

Last bit of the cmd window log below:

read 20
QTime("13:36:36.150") packet WAIT
QTime("13:36:36.184") packet RECV ""
QTime("13:36:36.184") packet RECV ""
QTime("13:36:36.184") packet RECV ""
QTime("13:36:36.185") packet READ ""
read 20
QTime("13:36:36.185") packet READ ""
read 20
QTime("13:36:36.185") packet READ ""
read 20
QTime("13:36:36.186") packet WAIT
QTime("13:36:36.230") packet RECV ""
QTime("13:36:36.230") packet RECV ""
QTime("13:36:36.231") packet RECV ""
QTime("13:36:36.231") packet READ ""
read 20
QTime("13:36:36.232") packet READ ""
read 20
QTime("13:36:36.233") packet READ ""
read 20
QTime("13:36:36.233") packet WAIT
QTime("13:36:36.267") packet RECV ""
QTime("13:36:36.279") packet RECV ""
characteristicWritten "{0003--1000-8000-00802500}" "df"
QTime("13:36:36.345") packet RECV ""
QTime("13:36:36.346") packet RECV ""
QTime("13:36:36.346") packet RECV ""
QTime("13:36:36.347") packet RECV ""
QTime("13:36:36.352") packet READ ""
read 20
QTime("13:36:36.352") packet READ ""
read 20
QTime("13:36:36.353") packet READ ""
read 20
QTime("13:36:36.353") packet READ ""
read 20
QTime("13:36:36.353") packet READ ""
read 20
QTime("13:36:36.353") packet READ ""
read 20
QTime("13:36:36.354") packet WAIT
QTime("13:36:48.367") packet SEND "ff"
read 20
QTime("13:36:48.375") packet WAIT
QTime("13:36:48.508") packet RECV "4cff"
QTime("13:36:48.508") packet READ "4cff"
Deleting BLE object
Finishing download thread: "Dive data import error"
Set the current dive site: 72475123
Set the current 

RE: [TEST REQUEST] Windows Bluetooth LE build

[Steve]

looks like the recent libdc + BLE refactor in Subsurface fixed the issues i was 
having downloading from the OSTC+ on Windows, with my custom Qt build.
so it wasn't an issue in the Qt stack.

thanks goes to Linus, because i was stuck on this not being able to figure out 
what's going on for a long time...

log for proof:
https://pastebin.com/7DHZU855

--

link for testing my latest Subsurface test build for BLE on Win32:
https://www.dropbox.com/s/zslq3ughx9ciehj/_deploy_win32_ble.zip?dl=0

instructions:

prerequisites:
- minimum Windows version for this is 8.1
- make sure that Windows has detected and paired with your DC

steps:
- extract the _deploy_win32_ble.zip ZIP in a folder somewhere
- navigate to the folder with Explorer and start _run.cmd
- a console window should open and next to it the Subsurface window
- start your BLE dive-computer and make it ready for downloading of dives
- in Subsurface goto Import -> Download from divecomputer
- select the following options (and pick paths):
 [x] Save libdivecomputer dumpfile
 [x] Save libdivecomputer logfile
- select the following option:
 [x] Choose bluetooth download mode
- a dialog should open. select "Force LE" for mode, and click "Scan".
- your device should appear in the list. select it and click "Save"
- the "Device or mount point" field should now show your DC.
- click "Download".

report back logs and dump files if it doesn't work for you.

lubomir
--


Looks like it is working well on Windows 10.
I have started to download with the OSTC3+ and it shows about 10% done at the 
moment.
Sample from cmd window below:

read 20
QTime("13:00:55.270") packet WAIT
QTime("13:00:55.304") packet RECV "cf0200d802169aab"
QTime("13:00:55.304") packet RECV "2300de0200eb0200ee0200cf0200"
QTime("13:00:55.306") packet RECV "d40200d302049ab1cf0200ce0200ce0200ca"
QTime("13:00:55.307") packet RECV "0200d70200e002169a9f"
QTime("13:00:55.307") packet READ "cf0200d802169aab"
read 20

I modified your _run.cmd to so it can capture everything as the windows cmd 
window doesn't have a very big scroll buffer:

@echo off
set QT_PLUGIN_PATH=.\plugins
set QT_LOGGING_RULES=qt.bluetooth*=true
subsurface.exe -v -v > cmdwindow.log
pause

Let me know if you actually want the all logs or not.

I can also test the Petrel2 Ext. later tonight if you want just let me know.

Cheers,
Steve

___
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: Mares Smart Dive Computer + Bluelink pro

[Dirk Hohndel]

I have an icon HD somewhere. It will require charging as it hasn't been used in 
a long time...

/D

On September 26, 2018 5:37:55 PM PDT, Linus Torvalds 
 wrote:
>On Wed, Sep 26, 2018 at 3:21 PM Linus Torvalds
> wrote:
>>
>> After switching to the 16@0 version, that is *exactly* the same
>> command sequence that the Mares App does first too.  But when the
>> Mares app does it, it gets the 16 bytes of data.
>>
>> Weird.
>
>So it turns out that "BLE is slow" is actually the *reason* for the
>problem.
>
>There's some really odd timing thing, where when we send the read
>command as two different packets (first the two command bytes, then
>the 8 bytes of offset/length), and wait for the AA ACK in between,
>something times out on the Mares side.
>
>But if I send the command byte as *one* 10-byte packet, it all just
>works.
>
>Which is really strange, because the Mares app itself actually sends
>it as two packets, but apparently sends them quickly enough together
>that the Mares doesn't go "where's the rest?" and give up on us.
>
>Anyway, the attached patch to libdivecomputer makes it work for me.
>I'm really not all that happy with the patch, but hey, it actually
>removes more lines than it adds, and it does make my loaner Mares Quad
>Air happy, so it's clearly doing something good.
>
>Jef - I assume your "send first two bytes separately" model is because
>that's what the Mares app does on a serial line too, and you just
>followed suite?
>
>I'm assuming that with a serial line, things are basically so quick
>that it's simply not an issue. The Qt BLE code is really slow, and
>we've had timing issues with it before (it caused problems on the
>Suunto EON Steel/Core too).
>
>So I think I'll commit this patch, although we *could* make it depend
>on the transport type (ie BLE vs serial). Although I strongly suspect
>that the simpler "just send the whole command" model works on a serial
>line too.
>
>Does anybody have a Mares in the "Icon HD" family with a serial line
>or USB to test? My loaner Quad Air didn't come with any PC interface,
>so now I _just_ have that BlueLink dongle I bought.
>
>Any of the Mares Matrix/Smart/Icon HD/Pucj Pro/Quad/Quad Air family
>would be interesting to hear about.
>
>I do wonder *why* BLE ends up being so slow on this thing - I'm
>consistently seeing delays of 1s for replies to come in, but while
>Fabio's trace from the Mares App also shows _some_ of that, it's not
>nearly as bad.  It may just be that the Mares App doesn't actually
>wait for the AA to come in, so it just streams the BLE traffic better.
>
>Anyway, after all these oddities, I do have a 100% successful
>download. Of course, the dive computer I have as a loaner is entirely
>empty of all dives, so I don't have any *dive* downloads, but it
>successfully read the memory to see that.
>
>And to test the BLE IO, I did try to do a libdivecomputer dumpfile,
>which creates a lot of read activity (even if the data is all 'ff')
>
>Linus

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

Re: Mares Smart Dive Computer + Bluelink pro

[Linus Torvalds]

On Wed, Sep 26, 2018 at 5:37 PM Linus Torvalds
 wrote:
>
> Anyway, the attached patch to libdivecomputer makes it work for me.
> I'm really not all that happy with the patch, but hey, it actually
> removes more lines than it adds, and it does make my loaner Mares Quad
> Air happy, so it's clearly doing something good.

I pushed this patch out to the libdivecomputer git tree so that we can
get more testing.

I think it will only speed things up (and make the BLE code work), but
maybe I'm being overly optimistic.

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

Re: Mares Smart Dive Computer + Bluelink pro

[Linus Torvalds]

On Wed, Sep 26, 2018 at 3:21 PM Linus Torvalds
 wrote:
>
> After switching to the 16@0 version, that is *exactly* the same
> command sequence that the Mares App does first too.  But when the
> Mares app does it, it gets the 16 bytes of data.
>
> Weird.

So it turns out that "BLE is slow" is actually the *reason* for the problem.

There's some really odd timing thing, where when we send the read
command as two different packets (first the two command bytes, then
the 8 bytes of offset/length), and wait for the AA ACK in between,
something times out on the Mares side.

But if I send the command byte as *one* 10-byte packet, it all just works.

Which is really strange, because the Mares app itself actually sends
it as two packets, but apparently sends them quickly enough together
that the Mares doesn't go "where's the rest?" and give up on us.

Anyway, the attached patch to libdivecomputer makes it work for me.
I'm really not all that happy with the patch, but hey, it actually
removes more lines than it adds, and it does make my loaner Mares Quad
Air happy, so it's clearly doing something good.

Jef - I assume your "send first two bytes separately" model is because
that's what the Mares app does on a serial line too, and you just
followed suite?

I'm assuming that with a serial line, things are basically so quick
that it's simply not an issue. The Qt BLE code is really slow, and
we've had timing issues with it before (it caused problems on the
Suunto EON Steel/Core too).

So I think I'll commit this patch, although we *could* make it depend
on the transport type (ie BLE vs serial). Although I strongly suspect
that the simpler "just send the whole command" model works on a serial
line too.

Does anybody have a Mares in the "Icon HD" family with a serial line
or USB to test? My loaner Quad Air didn't come with any PC interface,
so now I _just_ have that BlueLink dongle I bought.

Any of the Mares Matrix/Smart/Icon HD/Pucj Pro/Quad/Quad Air family
would be interesting to hear about.

I do wonder *why* BLE ends up being so slow on this thing - I'm
consistently seeing delays of 1s for replies to come in, but while
Fabio's trace from the Mares App also shows _some_ of that, it's not
nearly as bad.  It may just be that the Mares App doesn't actually
wait for the AA to come in, so it just streams the BLE traffic better.

Anyway, after all these oddities, I do have a 100% successful
download. Of course, the dive computer I have as a loaner is entirely
empty of all dives, so I don't have any *dive* downloads, but it
successfully read the memory to see that.

And to test the BLE IO, I did try to do a libdivecomputer dumpfile,
which creates a lot of read activity (even if the data is all 'ff')

Linus
 src/mares_iconhd.c | 11 +--
 1 file changed, 1 insertion(+), 10 deletions(-)

diff --git a/src/mares_iconhd.c b/src/mares_iconhd.c
index d5f0ede..daeeef7 100644
--- a/src/mares_iconhd.c
+++ b/src/mares_iconhd.c
@@ -159,7 +159,7 @@ mares_iconhd_transfer (mares_iconhd_device_t *device,
 		return DC_STATUS_CANCELLED;
 
 	// Send the command header to the dive computer.
-	status = dc_iostream_write (device->iostream, command, 2, NULL);
+	status = dc_iostream_write (device->iostream, command, csize, NULL);
 	if (status != DC_STATUS_SUCCESS) {
 		ERROR (abstract->context, "Failed to send the command.");
 		return status;
@@ -179,15 +179,6 @@ mares_iconhd_transfer (mares_iconhd_device_t *device,
 		return DC_STATUS_PROTOCOL;
 	}
 
-	// Send the command payload to the dive computer.
-	if (csize > 2) {
-		status = dc_iostream_write (device->iostream, command + 2, csize - 2, NULL);
-		if (status != DC_STATUS_SUCCESS) {
-			ERROR (abstract->context, "Failed to send the command.");
-			return status;
-		}
-	}
-
 	// Read the packet.
 	status = dc_iostream_read (device->iostream, answer, asize, NULL);
 	if (status != DC_STATUS_SUCCESS) {
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: [TEST REQUEST] Windows Bluetooth LE build

[Lubomir I. Ivanov]

On 27 September 2018 at 01:43, Linus Torvalds
 wrote:
> On Wed, Sep 26, 2018 at 3:05 PM Lubomir I. Ivanov  wrote:
>>
>> thanks goes to Linus, because i was stuck on this not being able to
>> figure out what's going on for a long time...
>
> I suspect that if I fixed something, I fixed it for the same reason
> the debug log got easier to read: less overlapping of IO and GATT
> discovery.
>
> So the Qt windows BLE code may have been confused by IO happening to
> one characteristic while another characteristic is still being
> discovered, or something.
>
> But good to know that there's progress on the Windows side, even if it
> was unintentional.
>

i'm not sure, tbh.

the way i implemented it in Qt was using a job queue:
- writeDescriptor, readDescriptor, writeChar, readChar type jobs are
all added to the same queue in a worker thread.
so read and write cannot happen in parallel, but rather the jobs wait in line.

this was requested by the Qt maintainers.

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

[Linus Torvalds]

On Wed, Sep 26, 2018 at 3:05 PM Lubomir I. Ivanov  wrote:
>
> thanks goes to Linus, because i was stuck on this not being able to
> figure out what's going on for a long time...

I suspect that if I fixed something, I fixed it for the same reason
the debug log got easier to read: less overlapping of IO and GATT
discovery.

So the Qt windows BLE code may have been confused by IO happening to
one characteristic while another characteristic is still being
discovered, or something.

But good to know that there's progress on the Windows side, even if it
was unintentional.

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

Re: Mares Smart Dive Computer + Bluelink pro

[Linus Torvalds]

On Wed, Sep 26, 2018 at 3:13 PM Linus Torvalds
 wrote:
>
> The Mares app sends a "93 36" handshake command first, that's the only
> other difference I see. I'll try that.

Nope. I get AAEA back from that command (like I should), but it
doesn't change any behavior.

The actual "read serial number" command still fails with no data,
whether I do it as 4 bytes at offset 12, or 16 bytes at offset 0 (like
the Mares app).

After switching to the 16@0 version, that is *exactly* the same
command sequence that the Mares App does first too.  But when the
Mares app does it, it gets the 16 bytes of data.

Weird.

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

Re: Mares Smart Dive Computer + Bluelink pro

[Linus Torvalds]

On Wed, Sep 26, 2018 at 3:02 PM Linus Torvalds
 wrote:
>
> I will see if it works if I ask for the 16 bytes at offset zero instead..

Nope, that's not it.

The Mares app sends a "93 36" handshake command first, that's the only
other difference I see. I'll try that.

 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

[Lubomir I. Ivanov]

looks like the recent libdc + BLE refactor in Subsurface fixed the
issues i was having downloading from the OSTC+ on Windows, with my
custom Qt build.
so it wasn't an issue in the Qt stack.

thanks goes to Linus, because i was stuck on this not being able to
figure out what's going on for a long time...

log for proof:
https://pastebin.com/7DHZU855

--

link for testing my latest Subsurface test build for BLE on Win32:
https://www.dropbox.com/s/zslq3ughx9ciehj/_deploy_win32_ble.zip?dl=0

instructions:

prerequisites:
- minimum Windows version for this is 8.1
- make sure that Windows has detected and paired with your DC

steps:
- extract the _deploy_win32_ble.zip ZIP in a folder somewhere
- navigate to the folder with Explorer and start _run.cmd
- a console window should open and next to it the Subsurface window
- start your BLE dive-computer and make it ready for downloading of dives
- in Subsurface goto Import -> Download from divecomputer
- select the following options (and pick paths):
 [x] Save libdivecomputer dumpfile
 [x] Save libdivecomputer logfile
- select the following option:
 [x] Choose bluetooth download mode
- a dialog should open. select "Force LE" for mode, and click "Scan".
- your device should appear in the list. select it and click "Save"
- the "Device or mount point" field should now show your DC.
- click "Download".

report back logs and dump files if it doesn't work for you.

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

Re: Mares Smart Dive Computer + Bluelink pro

[Linus Torvalds]

On Wed, Sep 26, 2018 at 2:14 PM Linus Torvalds
 wrote:
>
> So I don't see why that data read seemed to fail and not return any
> information. Everything else looked really good, and the Mares app
> seems to use the exact same command set, just slightly different
> offset/length values.

Well, my BlueLink arrived, and I have two observations:

 - this is the *slowest* BLE thing I've ever seen in my life.

I think it's a bad interaction with how Qt does Bluez, because I'm
assuming that it works much better on Android, where all the BLE GATT
information is cached (I think). With Bluez, Qt ends up doing the full
discovery by actually talking to the thing over BLE every time, and it
normally takes up to a few tens of seconds to get all the GATT
information.

With the BlueLink, I had to up the BLE timeout for waiting for service
discovery, because it took closer to a minute. Whee.

 - I see the same behavior Fabio sees.

I can see it communicate fine, but it doesn't actually reply with the
serial number data, it just returns EOF immediately.

I guess that counts as "good news". Although this thing is so slow
that it feels like it's almost faster to just debug it over email with
Fabio, than to play with it locally here ;)

I will see if it works if I ask for the 16 bytes at offset zero instead..

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

Re: Mares Smart Dive Computer + Bluelink pro

[Linus Torvalds]

On Wed, Sep 26, 2018 at 1:20 PM Linus Torvalds
 wrote:
>
> It then tried to do a 4-byte read at offset 12,  and *that* failed.
>  But the communication actually was successful: you
> can see how the dive computer returned AA to the command (that's
> "ACK") and then EA to the length/offset (that's EOF). It just didn't
> return the four bytes we actually asked for.

Looking at the original bluetooth capture file from the Mares App, it
uses the very same E742 command to read data, and seems to have the
exact same format for offset/length.

It doesn't actually seem to ever read that exact serial number from
that address, though. The mares app did the following offset/length
reads (this is all little-endian, so "1e1d0100" means offset
0x00011d1e, and length "0001" is 0x0100, aka 256.

 1000
0060 4d00
0020 5900
...

but there are definitely 4-byte reads in there later. And that first
read is a 16-byte read from offset 0, which would *cover* the 4-byte
read we do at offset 12.

When it did that 16-byte read at offset zero, it got

  10 00 00 00 ee 05 01 00 02 00 00 00 b5 e9 00 00

back, so the serial number would *seem* to be those b5 e9 00 00 bytes
(which would be 59831 in 32-bit LE format). But when we do that 4-byte
read at offset 12, we get nothing at all.

So I don't see why that data read seemed to fail and not return any
information. Everything else looked really good, and the Mares app
seems to use the exact same command set, just slightly different
offset/length values.

Jef, do you have any ideas? Have you seen anything like this before?

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

Re: Mares Smart Dive Computer + Bluelink pro

[Linus Torvalds]

On Wed, Sep 26, 2018 at 12:55 PM Fabio Capriati
 wrote:
>
> Hi everyone,
> Something is changed. Now it said that "no new dives are present on computer".

Hmm. It actually successfully opened the device, and got the version
data. That seems to have completed successfully.

It then tried to do a 4-byte read at offset 12, which is this:

// Read the serial number.
unsigned char serial[4] = {0};
rc = mares_iconhd_device_read (abstract, 0x0C, serial, sizeof (serial));
if (rc != DC_STATUS_SUCCESS) {
ERROR (abstract->context, "Failed to read the memory.");
return rc;
}

and *that* failed. But the communication actually was successful: you
can see how the dive computer returned AA to the command (that's
"ACK") and then EA to the length/offset (that's EOF). It just didn't
return the four bytes we actually asked for.

So for some reason we didn't actually get the serial number return.

Odd. Because the *communication* now all looks good.

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

Re: Mares Smart Dive Computer + Bluelink pro

[Fabio Capriati]

Hi everyone,
Something is changed. Now it said that "no new dives are present on
computer".

I'm honered  help this project! Thanks for your work.

Here the "daily chocolate" ;)

Bye




-- subsurface.log --
Empty filename passed to function
"0.040: Failed to open logfile /storage/emulated/0/subsurface.log at mer
set 26 21:46:31 2018 error: Permission denied"
"0.041: Failed to open logfile /storage/emulated/0/Documents/subsurface.log
at mer set 26 21:46:31 2018 error: Permission denied"
"0.042: Successfully opened logfile
/storage/emulated/0/Android/data/org.subsurfacedivelog.mobile/files/Documents/subsurface.log
at mer set 26 21:46:31 2018"
"0.044: Starting Subsurface-mobile:2.1.4(4.8.2.74):Android Oreo
(8.0):arm:it-IT"
"0.045: built with libdivecomputer v0.7.0-devel-Subsurface-NG
(e97886a994c18844bdcb1e1832ce4475dbe409b0)"
"0.045: built with Qt Version 5.11.1, runtime from Qt Version 5.11.1"
"0.045: built with libgit2 0.26.0"
"localDevice OnePlus 3 is valid, starting discovery"

Found new device: "Quad" "LE:00:1A:85:E0:0C:23"
"this could be a Mares Quad"

Paired = "Mares bluelink pro" "LE:00:1A:85:E0:0C:23"

"Created position source android"
"0.135: Created position source android"
"Set GPS service update interval to 300 s"
"0.136: Set GPS service update interval to 300 s"
"0.136: location service is available"
"0.892: Credenziali cloud mancanti"
checkPendingIntents
Using the following font: Roboto at 16pt with mobile_scale: 1
qqwindow devicePixelRatio 3 3
Supported dive computers:
"Aeris: 500 AI (SERIAL), A300 (SERIAL), A300 AI (SERIAL), A300CS (SERIAL),
Atmos 2 (SERIAL), Atmos AI (SERIAL), Atmos AI 2 (SERIAL), Compumask
(SERIAL), Elite (SERIAL), Elite T3 (SERIAL), Epic (SERIAL), F10 (SERIAL),
F11 (SERIAL), Manta (SERIAL), XR-1 NX (SERIAL), XR-2 (SERIAL)"
"Aqualung: i200 (SERIAL), i300 (SERIAL), i450T (SERIAL), i550 (SERIAL),
i750TC (SERIAL, BT)"
"Atomic Aquatics: Cobalt (USB), Cobalt 2 (USB)"
"Beuchat: Mundial 2 (SERIAL), Mundial 3 (SERIAL), Voyager 2G (SERIAL)"
"Cochran: Commander I (SERIAL), Commander II (SERIAL), Commander TM
(SERIAL), EMC-14 (SERIAL), EMC-16 (SERIAL), EMC-20H (SERIAL)"
"Cressi: Drake (SERIAL), Giotto (SERIAL), Leonardo (SERIAL), Newton
(SERIAL)"
"Garmin: Descent Mk1 (USBSTORAGE)"
"Genesis: React Pro (SERIAL), React Pro White (SERIAL)"
"Heinrichs Weikamp: Frog (SERIAL, BT), OSTC (SERIAL), OSTC 2 (SERIAL, BT,
BLE), OSTC 2 TR (SERIAL, BT, BLE), OSTC 2C (SERIAL), OSTC 2N (SERIAL), OSTC
3 (SERIAL), OSTC 4 (SERIAL, BT, BLE), OSTC Mk2 (SERIAL), OSTC Plus (SERIAL,
BT, BLE), OSTC Sport (SERIAL, BT, BLE), OSTC cR (SERIAL)"
"Hollis: DG02 (SERIAL), DG03 (SERIAL), TX1 (SERIAL)"
"Mares: Puck Pro (SERIAL, BLE), Quad (SERIAL, BLE), Quad Air (SERIAL, BLE),
Smart (SERIAL, BLE), Smart Air (SERIAL, BLE)"
"Oceanic: Atom 1.0 (SERIAL), Atom 2.0 (SERIAL), Atom 3.0 (SERIAL), Atom 3.1
(SERIAL), Datamask (SERIAL), F10 (SERIAL), F11 (SERIAL), Geo (SERIAL), Geo
2.0 (SERIAL), OC1 (SERIAL), OCS (SERIAL), OCi (SERIAL), Pro Plus 2
(SERIAL), Pro Plus 2.1 (SERIAL), Pro Plus 3 (SERIAL), VT 4.1 (SERIAL), VT
Pro (SERIAL), VT3 (SERIAL), VT4 (SERIAL), VTX (SERIAL), Veo 1.0 (SERIAL),
Veo 180 (SERIAL), Veo 2.0 (SERIAL), Veo 200 (SERIAL), Veo 250 (SERIAL), Veo
3.0 (SERIAL), Versa Pro (SERIAL)"
"Scubapro: Aladin Sport Matrix (BLE), Aladin Square (USBHID), G2 (USBHID,
BLE), G2 Console (USBHID, BLE)"
"Seemann: XP5 (SERIAL)"
"Shearwater: Nerd (SERIAL, BT), Nerd 2 (BLE), Perdix (SERIAL, BT, BLE),
Perdix AI (BLE), Petrel (SERIAL, BT), Petrel 2 (SERIAL, BT, BLE), Predator
(SERIAL, BT), Teric (BLE)"
"Sherwood: Amphos (SERIAL), Amphos Air (SERIAL), Insight (SERIAL), Insight
2 (SERIAL), Vision (SERIAL), Wisdom (SERIAL), Wisdom 2 (SERIAL), Wisdom 3
(SERIAL)"
"Subgear: XP-Air (SERIAL)"
"Suunto: Cobra (SERIAL), Cobra 2 (SERIAL), Cobra 3 (SERIAL), D3 (SERIAL),
D4 (SERIAL), D4f (SERIAL), D4i (SERIAL), D6 (SERIAL), D6i (SERIAL), D9
(SERIAL), D9tx (SERIAL), DX (SERIAL), EON Core (USBHID, BLE), EON Steel
(USBHID, BLE), Eon (SERIAL), Gekko (SERIAL), HelO2 (SERIAL), Mosquito
(SERIAL), Solution (SERIAL), Solution Alpha (SERIAL), Solution Nitrox
(SERIAL), Spyder (SERIAL), Stinger (SERIAL), Vyper (SERIAL), Vyper 2
(SERIAL), Vyper Air (SERIAL), Vyper Novo (SERIAL), Vytec (SERIAL), Zoop
(SERIAL), Zoop Novo (SERIAL)"
"Tecdiving: DiveComputer.eu (SERIAL, BT)"
"Tusa: Element II (IQ-750) (SERIAL), Zen (IQ-900) (SERIAL), Zen Air
(IQ-950) (SERIAL)"
"Uwatec: Aladin Air Twin (SERIAL), Aladin Air Z (SERIAL), Aladin Air Z
Nitrox (SERIAL), Aladin Air Z O2 (SERIAL), Aladin Pro (SERIAL), Aladin Pro
Ultra (SERIAL), Aladin Sport Plus (SERIAL), Memomouse (SERIAL)"
qqwindow screen has ldpi/pdpi 72 133.858
"1.721: AppState changed to active with no save ongoing and no unsaved
changes"
"2.878: Switching to no cloud mode"
"2.972: Unable to look up revision 'master'"
"2.973: Unable to look up revision 'master'"
"2.973: loading dives from cache failed -1"
"2.976: have cloud credentials, but user asked not to connect to network"
"11.662: DCDownloadThread 

Fwd: Re: [Subsurface-divelog/subsurface] Help needed: Support for XMP metadata in MP4 files (#1684)

[Willem Ferguson]

Please ignore my previous email. I got some text mixed up. Here is an 
improvement:


On 25/09/2018 18:38, bstoeger wrote:


Ping...?

This now uses |libxml2| (dislike the interface and documentation, but 
what can you do) instead of a hand-crafted parser. This seems very low 
risk. I tested it on 2 synthetic examples and ran it on a directory of 
~100 videos. No issues. No confirmation on real-world data though 
(@willemferguson ?).


Code is not nice, but I see no point in polishing it until we try to 
extract more usable data from the XMP block [e.g. GPS?]. But here too, 
working on that makes little sense until we get access to real-world 
examples.


If there is no interest in this feature - let's dump it.

— You are receiving this because you were mentioned. Reply to this 
email directly, view it on GitHub 
, 
or mute the thread 
.



Berthold,

Great apologies for you having to ping me.

The video file does not have any date-time attributes defined because it 
comprises a merger of a number of small videos All of the same date but 
of different times of day). Consequently OpenShot cannot assign 
date-times to the combined video and they all appear as zero values. I 
messed around with the video file, defining different dates to all the 
relevant data attributes of the video. (1) Using Subsurface Version 
4.8.2 (public release) === Selected dive 
date/time: Sat Sep 8 15:23:19 2018 GMT Files with inappropriate 
date/time: 
/home/willem/Downloads/exiftool/Image-ExifTool-11.10/whaleshark.mp4 - 
Fri Sep 28 12:05:05 2018 GMT This is the *Media Create Date* attribute. 
(2) Using Subsurface Version 8.8.2-71 
= Selected dive date/time: Sat Sep 8 
15:23:19 2018 GMT Files with inappropriate date/time: 
/home/willem/Downloads/exiftool/Image-ExifTool-11.10/whaleshark.mp4 - 
Tue Sep 25 12:01:05 2018 GMT


This is the *Date/Time Original* attribute Here are the attributes for 
the video file as seen by ExifTool:


(3) Using original video:

 Here are the results using Subsurface Version 8.8.2-71 
on one of the original video files:


Selected dive date/time: Sun Jul 1 12:17:37 2018 GMT

Files with inappropriate date/time:

/home/willem/Downloads/exiftool/Image-ExifTool-11.10/whaleshark.MOV_original 
- Mon Jul 2 18:02:10 2018 GMT


This is possibly the *Date/Time Original* attribute, but all the 
date-time values are the same in the original file so it is pretty 
ambiguous.


Here are the metadata for the combined video file (.mp4): $ exiftool  
whaleshark.mp4 ExifTool Version Number : 11.10File Name : 
whaleshark.mp4Directory : .File Size : 106 MBFile Modification Date/Time 
: 2018:09:26 19:48:32+02:00File Access Date/Time : 2018:09:26 
19:48:34+02:00File Inode Change Date/Time : 2018:09:26 
19:48:33+02:00File Permissions : rwxrwxrwxFile Type : MP4File Type 
Extension : mp4MIME Type : video/mp4Major Brand : MP4 Base Media v1 [IS0 
14496-12:2003]Minor Version : 0.2.0Compatible Brands : isom, iso2, avc1, 
mp41Movie Data Size : 111009714Movie Data Offset : 48Movie Header 
Version : 0Time Scale : 1000Duration : 0:00:57Preferred Rate : 
1Preferred Volume : 100.00%Preview Time : 0 sPreview Duration : 0 
sPoster Time : 0 sSelection Time : 0 sSelection Duration : 0 sCurrent 
Time : 0 sNext Track ID : 3Track Header Version : 0Track Create Date : 
2018:09:29 12:05:05Track Modify Date : :00:00 00:00:00Track ID : 
1Track Duration : 0:00:57Track Layer : 0Track Volume : 0.00%Image Width 
: 1280Image Height : 720Graphics Mode : srcCopyOp Color : 0 0 
0Compressor ID : avc1Source Image Width : 1280Source Image Height : 720X 
Resolution : 72Y Resolution : 72Bit Depth : 24Video Frame Rate : 
24Matrix Structure : 1 0 0 0 1 0 0 0 1Media Header Version : 0Media 
Create Date : 2018:09:28 12:05:05Media Modify Date : :00:00 
00:00:00Media Time Scale : 44100Media Duration : 0:00:57Media Language 
Code : undHandler Description : SoundHandlerBalance : 0Audio Channels : 
2Audio Bits Per Sample : 16Audio Sample Rate : 44100Handler Type : 
MetadataHandler Vendor ID : AppleEncoder : Lavf57.83.100XMP Toolkit : 
Image::ExifTool 11.10Date/Time Original : 2018:09:25 12:01:05Date/Time 
Modified : 2018:09:26 12:05:05Create Date : 2018:09:27 12:05:05Modify 
Date : 2018:09:09 06:55:00Avg Bitrate : 15.3 MbpsImage Size : 
1280x720Megapixels : 0.922Rotation : 0


The way that Subsurface handles it appears pretty logical. I will be 
diving for the following week and will do some more video photography 
and do some more tests when I am back on Oct 7th.


Here are the metadata for the original video file:

$ exiftool whaleshark.MOV

ExifTool Version Number : 11.10File Name : whaleshark.MOVDirectory : 
.File Size : 210 MBFile Modification Date/Time : 

Re: Mares Smart Dive Computer + Bluelink pro

[Dirk Hohndel]

On Wed, Sep 26, 2018 at 11:43:10AM -0700, Linus Torvalds wrote:
> 
> That, together with the subsurface pull request that I just did on
> github, should finally fix this issue.

New APK is here:

http://subsurface-divelog.org/downloads/test/Subsurface-mobile-4.8.2.74-arm.apk

>  - the subsurface pull request does *not* update the libdivecomputer
> submodule, but for the Mares BlueLink to work, you need *both* the new
> libdivecomputer _and_ the subsurface change.

Of course. Done.

> UPS tracking shows that my BlueLink dongle was loaded on the delivery
> vehicle this morning, so hopefully I'll be able to finally test this
> later today. But all actual credit obviously does to Fabio for his
> patience in testing various broken versions and sending back debug
> information showing which parts needed fixing.

Cool. If Fabio is still awake, he might beat you to it when it comes to
testing, though :-)

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

Re: [Subsurface-divelog/subsurface] Help needed: Support for XMP metadata in MP4 files (#1684)

[Willem Ferguson]

On 25/09/2018 18:38, bstoeger wrote:


Ping...?

This now uses |libxml2| (dislike the interface and documentation, but 
what can you do) instead of a hand-crafted parser. This seems very low 
risk. I tested it on 2 synthetic examples and ran it on a directory of 
~100 videos. No issues. No confirmation on real-world data though 
(@willemferguson ?).


Code is not nice, but I see no point in polishing it until we try to 
extract more usable data from the XMP block [e.g. GPS?]. But here too, 
working on that makes little sense until we get access to real-world 
examples.


If there is no interest in this feature - let's dump it.

— You are receiving this because you were mentioned. Reply to this 
email directly, view it on GitHub 
, 
or mute the thread 
.



Berthold,

Great apologies for you having to ping me.

The video file does not have any date-time attributes defined because it 
comprises a merger of a number of small videos All of the same date but 
of different times of day). Consequently OpenShot cannot assign 
date-times to the combined video and they all appear as zero values. I 
messed around with the video file, defining different dates to all the 
relevant data attributes of the video. (1) Using Subsurface Version 
4.8.2 (public release) === Selected dive 
date/time: Sat Sep 8 15:23:19 2018 GMT Files with inappropriate 
date/time: 
/home/willem/Downloads/exiftool/Image-ExifTool-11.10/whaleshark.mp4 - 
Fri Sep 28 12:05:05 2018 GMT This is the *Media Create Date* attribute. 
(2) Using Subsurface Version 8.8.2-71 
= Selected dive date/time: Sat Sep 8 
15:23:19 2018 GMT Files with inappropriate date/time: 
/home/willem/Downloads/exiftool/Image-ExifTool-11.10/whaleshark.mp4 - 
Tue Sep 25 12:01:05 2018 GMT This is possibly the *Date/Time Original* 
attribute, but all the date-time values are the same in the original 
file so it is pretty ambiguous. Here are the attributes for the video 
file as seen by ExifTool:


(3) Using original video:

 Here are the results using Subsurface Version 8.8.2-71 
on one of the original video files:


Selected dive date/time: Sun Jul 1 12:17:37 2018 GMT

Files with inappropriate date/time:

/home/willem/Downloads/exiftool/Image-ExifTool-11.10/whaleshark.MOV_original 
- Mon Jul 2 18:02:10 2018 GMT


Here are the metadata for the combined video file (.mp4): $ exiftool  
whaleshark.mp4 ExifTool Version Number : 11.10File Name : 
whaleshark.mp4Directory : .File Size : 106 MBFile Modification Date/Time 
: 2018:09:26 19:48:32+02:00File Access Date/Time : 2018:09:26 
19:48:34+02:00File Inode Change Date/Time : 2018:09:26 
19:48:33+02:00File Permissions : rwxrwxrwxFile Type : MP4File Type 
Extension : mp4MIME Type : video/mp4Major Brand : MP4 Base Media v1 [IS0 
14496-12:2003]Minor Version : 0.2.0Compatible Brands : isom, iso2, avc1, 
mp41Movie Data Size : 111009714Movie Data Offset : 48Movie Header 
Version : 0Time Scale : 1000Duration : 0:00:57Preferred Rate : 
1Preferred Volume : 100.00%Preview Time : 0 sPreview Duration : 0 
sPoster Time : 0 sSelection Time : 0 sSelection Duration : 0 sCurrent 
Time : 0 sNext Track ID : 3Track Header Version : 0Track Create Date : 
2018:09:29 12:05:05Track Modify Date : :00:00 00:00:00Track ID : 
1Track Duration : 0:00:57Track Layer : 0Track Volume : 0.00%Image Width 
: 1280Image Height : 720Graphics Mode : srcCopyOp Color : 0 0 
0Compressor ID : avc1Source Image Width : 1280Source Image Height : 720X 
Resolution : 72Y Resolution : 72Bit Depth : 24Video Frame Rate : 
24Matrix Structure : 1 0 0 0 1 0 0 0 1Media Header Version : 0Media 
Create Date : 2018:09:28 12:05:05Media Modify Date : :00:00 
00:00:00Media Time Scale : 44100Media Duration : 0:00:57Media Language 
Code : undHandler Description : SoundHandlerBalance : 0Audio Channels : 
2Audio Bits Per Sample : 16Audio Sample Rate : 44100Handler Type : 
MetadataHandler Vendor ID : AppleEncoder : Lavf57.83.100XMP Toolkit : 
Image::ExifTool 11.10Date/Time Original : 2018:09:25 12:01:05Date/Time 
Modified : 2018:09:26 12:05:05Create Date : 2018:09:27 12:05:05Modify 
Date : 2018:09:09 06:55:00Avg Bitrate : 15.3 MbpsImage Size : 
1280x720Megapixels : 0.922Rotation : 0


The way that Subsurface handles it appears pretty logical. I will be 
diving for the following week and will do some more video photography 
and do some more tests when I am back on Oct 7th.


Here are the metadata for the original video file:

$ exiftool whaleshark.MOV

ExifTool Version Number : 11.10File Name : whaleshark.MOVDirectory : 
.File Size : 210 MBFile Modification Date/Time : 2018:09:13 
07:44:41+02:00File Access Date/Time : 2018:09:13 07:44:54+02:00File 
Inode Change Date/Time : 2018:09:13 

Re: Mares Smart Dive Computer + Bluelink pro

[Linus Torvalds]

On Wed, Sep 26, 2018 at 10:40 AM Linus Torvalds
 wrote:
>
> I suspect I need to put the "repeat read" condition inside
> libdivecomputer itself. Because right now the "user passed in a NULL
> actual pointer" case is insane: dc_iostream_read() will happily return
> a partial buffer with no way to see how much of it was filled.

I have now done that.

Dirk - I have updated the libdivecomputer branch with the current tip being

   e97886a994c1 ("Fix dc_iostream_{read,write} debugging implementation")

which handles the case of a dc_iostream_read/write() user that is not
able or willing to handle partial IO results.

That, together with the subsurface pull request that I just did on
github, should finally fix this issue.

I have actually "tested" this by not only verifying that yes, the EON
Core still works, I also made a fake (and broken) EON Core backend
change that tried to read both partial packets and multi-packet full
buffers. The iostream layer now does the right thing, and the qt-ble
case only needs to handle the partial packet case.

Two notes:

 - the subsurface pull request also implements the 'hh:mm:ss' parsing.
I've tested that too with a manually edited XML file, it seems fine.

 - the subsurface pull request does *not* update the libdivecomputer
submodule, but for the Mares BlueLink to work, you need *both* the new
libdivecomputer _and_ the subsurface change.

UPS tracking shows that my BlueLink dongle was loaded on the delivery
vehicle this morning, so hopefully I'll be able to finally test this
later today. But all actual credit obviously does to Fabio for his
patience in testing various broken versions and sending back debug
information showing which parts needed fixing.

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

Re: Mares Smart Dive Computer + Bluelink pro

[Linus Torvalds]

On Wed, Sep 26, 2018 at 8:13 AM Dirk Hohndel  wrote:
>
> Here's the APK
> http://subsurface-divelog.org/downloads/test/Subsurface-mobile-mares-test.apk

Never mind.

I added hacks to test the Mares case, and while the packet splitting
seems to work fine, the "read multiple packets to satisfy the whole
read" does *not* work.

The reason it doesn't work is annoying: we use the "did the user ask
for the number of bytes returned" to decide whether we should satisfy
the whole read or not.

And yes, Mares passes in "NULL" for the actual byte return, *BUT* the
qt-ble.c code never actually gets a NULL.

Why? Because the dc_iostream_read() will never pass the NULL down to
the low-level IO, it does

size_t nbytes = 0;
...
status = iostream->vtable->read (iostream, data, size, );
if (actual)
*actual = nbytes;

so the qt-ble code will always see a non-NULL "actual" pointer
(because it will be that pointer to the 'nbytes' in the wrapper.

So all that code that says "if the caller doesn't want partial
packets" is basically dead code, and qt-ble.c will always juist return
one packet at a time.

Which is what all our *other* BLE users actually want. The Suunto EON
Steel downloader, for example, doesn't really know how many packets
will come, so waiting for some buffer full condition is absolutely not
correct, and it needs the "return partial" case.

I need to figure out some other way to determine that "should I wait
for more" condition.

I suspect I need to put the "repeat read" condition inside
libdivecomputer itself. Because right now the "user passed in a NULL
actual pointer" case is insane: dc_iostream_read() will happily return
a partial buffer with no way to see how much of it was filled.

Jef, what are the semantics for

ret = dc_iostream_read(iostream, buf, sizeof(buf), NULL);

meant to be when there is only a partial read? Right now it returns
DC_STATUS_SUCCESS and garbage in the end of "buf". Which really does
seem wrong. The caller has no way to know that it got a just a partial
reply..

The serial driver rules seem to be "I will repeat until I get the
whole buffer", so it doesn't have that issue - it will always fill the
buffer completely, or return an error. But enforcing that kind of
behavior is crazy anyway: it makes the whole "actual" pointer totally
pointless.

And as mentioned, that "I need to always fill the whole buffer" isn't
actually possible or acceptable for other protocols like BLE. The
buffer size needs to be a whole packet, but not all packets are full
packets.

So I'd need some way to pass in "wait for the *whole* buffer to fill"
(which is what something like the Mares case needs - the downloader
knows exactly now many bytes to expect) vs "wait for *some* data to
arrive" (which is what something like the EON Steel requires, because
it does *not* know how many bytes it will actually get).

Note that the EON Steel case is really fundamental: even when it knows
how many final bytes to fill in (because it was reading a file), it
does *not* know how many bytes that is in a BLE packet, because the
BLE data is escaped. So it migth want 5 bytes of data in the end, but
with escaping that might be up to 10 bytes of actual data read over
BLE.

We could read things one byte at a time in the EON Steel back-end, but
that would be *horribly* expensive.

Using the "actual" pointer to see whether the user was ready to get a
partial packet or not seemed to be a really good idea., but the
dc_iostream_read() implementation sunk that idea.

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

Re: OT: Aqua Lung I100 Cable

[Simon Eigeldinger]

Hi Linus,

Am 24.09.2018 um 21:32 schrieb Linus Torvalds:

On Mon, Sep 24, 2018 at 12:05 PM Dirk Hohndel  wrote:


Cool. Once Linus merges that, we'll be able to add support for it in 4.8.3


I merged Jef's i100 work, and pushed it out. It looks like the parsing
is literally identical to the I200, just with the header at a
different offset.

Anyway, the "you need a cable that costs almost as much as the dive
computer" is sadly still true (even if a _slight_ exaggeration).


solved the problem now.
Ordered a Mares Puck with the interface for 160 euro and now selling the 
aqualung.


Greetings,
Simon

---
Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft.
https://www.avast.com/antivirus

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

Re: Mares Smart Dive Computer + Bluelink pro

[Dirk Hohndel]

On Wed, Sep 26, 2018 at 08:05:42AM -0700, Dirk Hohndel wrote:
> On Tue, Sep 25, 2018 at 11:42:32PM -0700, Linus Torvalds wrote:
> > On Tue, Sep 25, 2018 at 11:07 PM Linus Torvalds
> >  wrote:
> > > And I guess I also need to make it loop over the packet until it gets
> > > the asked-for data.
> > 
> > Like this attached patch.
> > 
> > Dirk, I've verified that this builds, and still works with the EON
> > Core, but I can't actually test the case that the Mares hits. The code
> > _looks_ simple, but I'd rather not commit it upstream without testing.
> > 
> > Are your scripts able to make a test-build with this patch in, without
> > actually committing it to the master branch?
> 
> But of course. I'll be happy to push something out.
> 
> Fabio - are you using the APK from our website or are you using the Google
> Play beta channel?

Here's the APK
http://subsurface-divelog.org/downloads/test/Subsurface-mobile-mares-test.apk

If you use the beta channel please let me know, pushing to that takes a
little longer, but I can do that as well.

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

Re: Mares Smart Dive Computer + Bluelink pro

[Dirk Hohndel]

On Tue, Sep 25, 2018 at 11:42:32PM -0700, Linus Torvalds wrote:
> On Tue, Sep 25, 2018 at 11:07 PM Linus Torvalds
>  wrote:
> > And I guess I also need to make it loop over the packet until it gets
> > the asked-for data.
> 
> Like this attached patch.
> 
> Dirk, I've verified that this builds, and still works with the EON
> Core, but I can't actually test the case that the Mares hits. The code
> _looks_ simple, but I'd rather not commit it upstream without testing.
> 
> Are your scripts able to make a test-build with this patch in, without
> actually committing it to the master branch?

But of course. I'll be happy to push something out.

Fabio - are you using the APK from our website or are you using the Google
Play beta channel?

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

Re: Mares Smart Dive Computer + Bluelink pro

[Jan Mulder]

On 9/26/18 8:42 AM, Linus Torvalds wrote:

On Tue, Sep 25, 2018 at 11:07 PM Linus Torvalds
 wrote:


So I need to make that BLEObject::read() function just handle the
"user just wants a partial packet" case. Nobody has cared until now.

And I guess I also need to make it loop over the packet until it gets
the asked-for data.


Like this attached patch.

Dirk, I've verified that this builds, and still works with the EON
Core, but I can't actually test the case that the Mares hits. The code
_looks_ simple, but I'd rather not commit it upstream without testing.

Are your scripts able to make a test-build with this patch in, without
actually committing it to the master branch?

The patch *looks* obvious, but..


Tested this on Android device interfacing with my OSTC3 over BLE. Still 
working correctly, So the obvious patch LGTM.


--jan

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

Re: Mares Smart Dive Computer + Bluelink pro

[Linus Torvalds]

On Tue, Sep 25, 2018 at 11:07 PM Linus Torvalds
 wrote:
>
> So I need to make that BLEObject::read() function just handle the
> "user just wants a partial packet" case. Nobody has cared until now.
>
> And I guess I also need to make it loop over the packet until it gets
> the asked-for data.

Like this attached patch.

Dirk, I've verified that this builds, and still works with the EON
Core, but I can't actually test the case that the Mares hits. The code
_looks_ simple, but I'd rather not commit it upstream without testing.

Are your scripts able to make a test-build with this patch in, without
actually committing it to the master branch?

The patch *looks* obvious, but..

   Linus
 core/qt-ble.cpp | 32 +---
 1 file changed, 29 insertions(+), 3 deletions(-)

diff --git a/core/qt-ble.cpp b/core/qt-ble.cpp
index 8d4003d0f..1dda570a7 100644
--- a/core/qt-ble.cpp
+++ b/core/qt-ble.cpp
@@ -191,8 +191,15 @@ dc_status_t BLEObject::read(void *data, size_t size, size_t *actual)
 
 	QByteArray packet = receivedPackets.takeFirst();
 
-	if ((size_t)packet.size() > size)
-		return DC_STATUS_NOMEMORY;
+	// Did we get more than asked for?
+	//
+	// Put back the left-over at the beginning of the
+	// received packet list, and truncate the packet
+	// we got to just the part asked for.
+	if ((size_t)packet.size() > size) {
+		receivedPackets.prepend(packet.mid(size));
+		packet.truncate(size);
+	}
 
 	memcpy((char *)data, packet.data(), packet.size());
 	if (actual)
@@ -501,11 +508,30 @@ static void checkThreshold()
 	}
 }
 
+// If 'actual' is NULL, we need to get all or nothing
 dc_status_t qt_ble_read(void *io, void* data, size_t size, size_t *actual)
 {
 	checkThreshold();
+
 	BLEObject *ble = (BLEObject *) io;
-	return ble->read(data, size, actual);
+	do {
+		dc_status_t rc;
+		size_t got = 0;
+
+		rc = ble->read(data, size, );
+		if (actual) {
+			*actual = got;
+			return rc;
+		}
+
+		if (rc != DC_STATUS_SUCCESS)
+			return rc;
+
+		data = (void *)(got + (char *)data);
+		size -= got;
+	} while (size);
+
+	return DC_STATUS_SUCCESS;
 }
 
 dc_status_t qt_ble_write(void *io, const void* data, size_t size, size_t *actual)
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Mares Smart Dive Computer + Bluelink pro

[Linus Torvalds]

On Tue, Sep 25, 2018 at 10:53 PM Linus Torvalds
 wrote:
>
> I wonder if the problem is
> that the Mares back-end tries to read in small chunks, and we hit that
>
> if ((size_t)packet.size() > size)
> return DC_STATUS_NOMEMORY;
>
> test instead of actually reading the data.
>
> Hmm.

Ahhah.

Indeed. That's exactly what is going on. The Mares code wants to
actualklky first read the single ACK byte. I had entirely missed that
part.

The BLE code isn't doing a very good job of looking like a serial
stream. We actually *used* to have code to make it act more like a
stream, but then the custom IO changes all changed that.

So I need to make that BLEObject::read() function just handle the
"user just wants a partial packet" case. Nobody has cared until now.

And I guess I also need to make it loop over the packet until it gets
the asked-for data.

Grr.  The problem here is that we actually don't know whether the
divecomputer wants to get packets or wants to see a stream. We used to
have separate code for the "serial emulation" and the "BLE packet",
but all that went away with the whole "convert to libdivecomputer
custom io".

I will have to think about this again, but now I *really* am convinced
I understand what is going on.

And this does explain why the Mares backend gives up. It will wait for
the first packet to come in, but then the DC_STATUS_NOMEMORY error
will cause it to stop immediately.

Anyway, Fabio, you've been an *excellent* candy machine. Thank you.

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