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: 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

Re: Any brave dive computer download testers out there?

[Linus Torvalds]

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
 core/qtserialbluetooth.cpp | 32 ++--
 1 file changed, 2 insertions(+), 30 deletions(-)

diff --git a/core/qtserialbluetooth.cpp b/core/qtserialbluetooth.cpp
index bc274dbd9..13f4ee8c5 100644
--- a/core/qtserialbluetooth.cpp
+++ b/core/qtserialbluetooth.cpp
@@ -113,34 +113,6 @@ static dc_status_t qt_serial_open(qt_serial_t **io, dc_context_t *context, const
 	timer.setSingleShot(true);
 	loop.connect(, SIGNAL(timeout()), SLOT(quit()));
 
-#if defined(Q_OS_LINUX) && !defined(Q_OS_ANDROID)
-	// First try to connect on RFCOMM channel 1. This is the default channel for most devices
-	QBluetoothAddress remoteDeviceAddress(devaddr);
-	serial_port->socket->connectToService(remoteDeviceAddress, 1, QIODevice::ReadWrite | QIODevice::Unbuffered);
-	timer.start(msec);
-	loop.exec();
-
-	if (serial_port->socket->state() == QBluetoothSocket::ConnectingState) {
-		// It seems that the connection on channel 1 took more than expected. Wait another 15 seconds
-		qDebug() << "The connection on RFCOMM channel number 1 took more than expected. Wait another 15 seconds.";
-		timer.start(3 * msec);
-		loop.exec();
-	} else if (serial_port->socket->state() == QBluetoothSocket::UnconnectedState) {
-		// Try to connect on channel number 5. Maybe this is a Shearwater Petrel2 device.
-		qDebug() << "Connection on channel 1 failed. Trying on channel number 5.";
-		serial_port->socket->connectToService(remoteDeviceAddress, 5, QIODevice::ReadWrite | QIODevice::Unbuffered);
-		timer.start(msec);
-		loop.exec();
-
-		if (serial_port->socket->state() == QBluetoothSocket::ConnectingState) {
-			// It seems that the connection on channel 5 took more than expected. Wait another 15 seconds
-			qDebug() << "The connection on RFCOMM channel number 5 took more than expected. Wait another 15 seconds.";
-			timer.start(3 * msec);
-			loop.exec();
-		}
-	}
-#elif defined(Q_OS_ANDROID) || (QT_VERSION >= 0x050500 && defined(Q_OS_MAC))
-	// Try to connect to the device using the uuid of the Serial Port Profile service
 	QBluetoothAddress remoteDeviceAddress(devaddr);
 #if defined(Q_OS_ANDROID)
 	QBluetoothUuid uuid = QBluetoothUuid(QUuid("{1101--1000-8000-00805f9b34fb}"));
@@ -148,7 +120,7 @@ static dc_status_t qt_serial_open(qt_serial_t **io, dc_context_t *context, const
 	serial_port->socket->setPreferredSecurityFlags(QBluetooth::NoSecurity);
 	serial_port->socket->connectToService(remoteDeviceAddress, uuid, QIODevice::ReadWrite | QIODevice::Unbuffered);
 #else
-	serial_port->socket->connectToService(remoteDeviceAddress, 1, QIODevice::ReadWrite | QIODevice::Unbuffered);
+	serial_port->socket->connectToService(remoteDeviceAddress, QIODevice::ReadWrite | QIODevice::Unbuffered);
 #endif
 	timer.start(msec);
 	loop.exec();
@@ -160,7 +132,7 @@ static dc_status_t qt_serial_open(qt_serial_t **io, dc_context_t *context, const
 		timer.start(4 * msec);
 		loop.exec();
 	}
-#endif
+
 	if (serial_port->socket->state() != QBluetoothSocket::ConnectedState) {
 
 		// Get the latest error and try to match it with one from libdivecomputer
___
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?

[Linus Torvalds]

On Thu, Apr 26, 2018 at 2:29 AM, Pedro Neves  wrote:
>
> @ Linus: my sytem (Arch Linux) detects the G2 :
>
> usb 1-10: new full-speed USB device number 6 using xhci_hcd
> [ 3494.833727] usb 1-10: New USB device found, idVendor=2e6c, idProduct=3201
> [ 3494.833730] usb 1-10: New USB device strings: Mfr=1, Product=2,
> SerialNumber=3
> [ 3494.833732] usb 1-10: Product: G2 dive computer
> [ 3494.833733] usb 1-10: Manufacturer: Uwatec AG
> [ 3494.833734] usb 1-10: SerialNumber: 
> [ 3494.835381] hid-generic 0003:2E6C:3201.0004: hiddev2,hidraw3: USB HID
> v1.00 Device [Uwatec AG G2 dive computer] on usb-:00:14.0-10/input0
>
> But fails to add an interface for it.

All you need is the raw usb device, something like

   /dev/bus/usb/001/010

and you need to have access rights to it.

> Have you used the USB connection to
> download data from your G2? Any hints?

Yup, it "JustWorks(tm)" for me.

But you need to have an udev rule to make sure you can access it. Something like

   SUBSYSTEM=="usb",ATTR{idVendor}=="2e6c",ATTR{idProduct}=="3201",MODE="0666"

in a udev rule file. I'm not sure where Arch Linux keeps its udev
rules, but usually it's one (or both) of

/etc/udev/rules.d
/usr/lib/udev/rules.d/

and after you've created your own file (call it "91-Scubapro-G2.udev"
or something, you need to make sure udev knows about the new rules (no
need to reboot, do "udevadm control --reload").

Oh. Or just do some googling. This looks like the proper docs:

https://wiki.archlinux.org/index.php/udev

and obviously you can do better than MODE="0666" that just gives
everybody access. Some distros have a "plugdev" group that console
users get added to, but you can do anything like just making you the
owner (USER="nevesdiver" in the udev rule) etc.

 Linus
___
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-25 22:12, Linus Torvalds wrote:
On Wed, Apr 25, 2018 at 11:51 AM, Dirk Hohndel  
wrote:


I have a Petrel (single stack BT) and Petrel 2 (dual stack) and will 
test
those over lunch today. I'll try to test Mac and Android 
(embarrassingly,

I currently don't have a Linux laptop with working BLE...)


Note that the magic channel/port number thing is Linux 
desktop-specific:


  #if defined(Q_OS_LINUX) && !defined(Q_OS_ANDROID)

And it was literally the Petrel 2 that triggered that "try channel 5".

I have no idea how that is supposed to work, or what the crazy rules
about rfcomm ports even -are-. I'm just looking at the code, and going
"eww".

Also note that on Linux and Windows, we could just use the
libdivecomputer bluetooth backend that just uses the raw socket.

Also, Jef just uses port 0 for everything.

So the whole "port/channel" thing may be entirely pointless.


In the libdivecomputer rfcomm implementation, port 0 means 
auto-detection. On linux it does an SDP discovery internally to find the 
correct rfcomm port number, and on Windows it uses the rfcomm uuid 
instead of the port number. That way, it should always just work. And on 
the hardware I tested, it does indeed.


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.


Jef
___
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?

[Pedro Neves]

Hi all:

I've just tested downloading from my Scubapro G2 using the latest master 
built with libdivecomputer v0.7.0-devel-Subsurface-NG. It failed the 
first time, but worked fine at the second attempt.


Now I'd like to test downloading from G2 using USB.

@ Linus: my sytem (Arch Linux) detects the G2 :

usb 1-10: new full-speed USB device number 6 using xhci_hcd
[ 3494.833727] usb 1-10: New USB device found, idVendor=2e6c, idProduct=3201
[ 3494.833730] usb 1-10: New USB device strings: Mfr=1, Product=2, 
SerialNumber=3

[ 3494.833732] usb 1-10: Product: G2 dive computer
[ 3494.833733] usb 1-10: Manufacturer: Uwatec AG
[ 3494.833734] usb 1-10: SerialNumber: 
[ 3494.835381] hid-generic 0003:2E6C:3201.0004: hiddev2,hidraw3: USB HID 
v1.00 Device [Uwatec AG G2 dive computer] on usb-:00:14.0-10/input0


But fails to add an interface for it. Have you used the USB connection 
to download data from your G2? Any hints?


Cheers:

Pedro
___
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?

[Anton Lundin]

On 25 April, 2018 - Linus Torvalds wrote:

> On Wed, Apr 25, 2018 at 10:38 AM, Anton Lundin  wrote:
> >
> > I've tested it now, via the serial layer, libftdi layer, classic bt
> > layer, and with your latest patch BLE and they all work.
> 
> Ok, so for you the classic BT case now works too with that patch that
> I sent out a couple of hours ago (the "supported transports" thing)?
> 
> This is the OSTC, I assume?

The BT/BLE was tested against a dual stack OSTC4.
 

//Anton


-- 
Anton Lundin+46702-161604
___
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?

[Linus Torvalds]

On Wed, Apr 25, 2018 at 11:51 AM, Dirk Hohndel  wrote:
>
> I have a Petrel (single stack BT) and Petrel 2 (dual stack) and will test
> those over lunch today. I'll try to test Mac and Android (embarrassingly,
> I currently don't have a Linux laptop with working BLE...)

Note that the magic channel/port number thing is Linux desktop-specific:

  #if defined(Q_OS_LINUX) && !defined(Q_OS_ANDROID)

And it was literally the Petrel 2 that triggered that "try channel 5".

I have no idea how that is supposed to work, or what the crazy rules
about rfcomm ports even -are-. I'm just looking at the code, and going
"eww".

Also note that on Linux and Windows, we could just use the
libdivecomputer bluetooth backend that just uses the raw socket.

Also, Jef just uses port 0 for everything.

So the whole "port/channel" thing may be entirely pointless.

   Linus
___
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 25/04/2018 20:51, Dirk Hohndel wrote:

On Apr 25, 2018, at 11:44 AM, Linus Torvalds  
wrote:

On Wed, Apr 25, 2018 at 10:38 AM, Anton Lundin  wrote:

I've tested it now, via the serial layer, libftdi layer, classic bt
layer, and with your latest patch BLE and they all work.

Ok, so for you the classic BT case now works too with that patch that
I sent out a couple of hours ago (the "supported transports" thing)?

This is the OSTC, I assume?

Now we just need somebody to test the Petrel 2. That's the one that I
hope that the patch from today finally fixes.

I have a Petrel (single stack BT) and Petrel 2 (dual stack) and will test
those over lunch today. I'll try to test Mac and Android (embarrassingly,
I currently don't have a Linux laptop with working BLE...)

/D

This latest version appears not to be available on the download page
It says "last updated 6 days ago".

https://github.com/Subsurface-divelog/subsurface/releases/tag/continuous-NG

Is this correct?

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

Re: Any brave dive computer download testers out there?

[Linus Torvalds]

On Wed, Apr 25, 2018 at 10:38 AM, Anton Lundin  wrote:
>
> I've tested it now, via the serial layer, libftdi layer, classic bt
> layer, and with your latest patch BLE and they all work.

Ok, so for you the classic BT case now works too with that patch that
I sent out a couple of hours ago (the "supported transports" thing)?

This is the OSTC, I assume?

Now we just need somebody to test the Petrel 2. That's the one that I
hope that the patch from today finally fixes.

  Linus
___
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?

[Anton Lundin]

On 18 April, 2018 - Linus Torvalds wrote:

> On Wed, Apr 18, 2018 at 3:37 PM, Robert Helling  wrote:
> >
> > Couldn’t get the dive computer configuration to work either with BLE or 
> > classic.
> 
> Did this work with the previous release (4.7.8 or whatever)?
> 
> I had been hoping that I got the config thing right, but I've never
> used it or tested it (I'm not sure I even have any of the dive
> computers that are supported), so that was purely a "it builds".

I've tested it now, via the serial layer, libftdi layer, classic bt
layer, and with your latest patch BLE and they all work.

( I have a patch pending for fixing the ostc3 config code against firmware
2.97, that I should clean up and sed out to, any day now )


//Anton


-- 
Anton Lundin+46702-161604
___
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?

[Chirana Gheorghita Eugeniu Theodor]

Ok ... than i can confirm that for perdix does not work either. One of my
friends tested the official release

On Wed, Apr 25, 2018, 11:43 Long, Martin  wrote:

>
> On 25 April 2018 at 09:07, Chirana Gheorghita Eugeniu Theodor <
> off...@adaptcom.ro> wrote:
>
>> Hmm very weird.
>> I use now latest 4.7.8 and successfully connects to Petrel 1 but will not
>> connect to mh older tusa zen iq-900 over usb ftdi.
>>
>
> It's likely to connect to Petrel one because it is single (legacy) stack
> with no BLE. However, Petrel 2, being dual stack, means subsurface only
> offers BLE, which is the broken bit.
>
___
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?

[Chirana Gheorghita Eugeniu Theodor]

Hmm very weird.
I use now latest 4.7.8 and successfully connects to Petrel 1 but will not
connect to mh older tusa zen iq-900 over usb ftdi.

On Wed, Apr 25, 2018, 10:26 Long, Martin  wrote:

> The BLE thing has basically made subsurface unusable for me for the last
> month or so. Oddly, it works fine with my Perdix AI, but not with the
> dual-stack Petrel 2 that's wired up to my rebreather - last time I was able
> to use it was when I was able to select and force the legacy BT stack.
>
> Does this branch expose both addresses again? If so I might have to fire
> up the build environment again.
>
>
> ___
> 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

Fwd: Re: Any brave dive computer download testers out there?

[Willem Ferguson]

On 24/04/2018 20:08, Linus Torvalds wrote:

On Tue, Apr 24, 2018 at 11:03 AM, Willem Ferguson
 wrote:

Initial handshaking took maybe 40s, showing error message in red bar at
bottom of screen "Timeout"

Hmm. It looks like it first tried to do a BLE download, and that
failed (and this is what took a longish time).

And then because of the failure, it fell back on old-style BT rfcomm, and:


But, if not interrupted, the download proceeded perfectly shortly after the
timeout message and download exited normally on the GUI.

.. apparently rfcomm works for you and the fallback was successful.

Has BLE ever worked for you?


NOPE

I did the same download by setting the dropdown option in the BT setup
panel to 'Force Classical'. Took about 25 sec to do handshaking, still
getting "Timeout while trying to connect". Does not appear to make
difference and successful end result is same as previously, downloading
all my dives. Interesting error message at end of log. I have never
managed to get the BLE working. My Petrel is pretty recent, so I am
reasonably sure it can do both. But the user manual and the Shearwater
website does not provide any insight into this.

Desktop$ ./Subsurface-4.7.8-73-ga12ea13d51f5-x86_64.AppImage
can't find Subsurface localization for locale "en-ZA"
Missing CAP_NET_ADMIN permission. Cannot determine whether a found
address is of random or public type.
Starting download from  BT
Starting the thread 0
Enabling GATT request timeout behavior 2
qt_ble_open( 00:13:43:5B:8F:BE )
Creating default GAP/GATT services
addresstypeToUse: "Random"
No settings found for peer device.
HCI event triggered, type: e
HCI event triggered, type: e
timeout while trying to connect to the controller 00:13:43:5B:8F:BE
void QBluetoothSocketPrivate::_q_readNotify() 28 error: -1 "Resource
temporarily unavailable"
Connection on channel 1 failed. Trying on channel number 5.
INFO: dc_device_open error value of 0
[39.400513] ERROR: Failed to download the dive. [in
../../src/shearwater_petrel.c:330 (shearwater_petrel_device_foreach)]
Finishing the thread Dive data import error dives downloaded 9

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

Re: Any brave dive computer download testers out there?

[Linus Torvalds]

On Tue, Apr 24, 2018 at 11:25 AM, Willem Ferguson
 wrote:
>
> I did the same download by setting the dropdown option in the BT setup panel
> to 'Force Classical'.

The new code just ignores the classic/ble/auto setting right now.

I'd rather do it using the "dc_transports" model that we now use for
everything else anyway, the old model was totally different.

> Interesting error message at end of log. I have never managed to get the BLE
> working. My Petrel is pretty recent, so I am reasonably sure it can do both.

The Shearwater dive computers can be temperamental when it comes to BLE.

I've never used the rfcomm thing (my Perdix AI doesn't support it),
but the BLE works reliably for me - once it has connected once. But
getting it to connect that first time can be a crap-shoot.

So the Shearwater BLE code seems to have some history, and probably
remembers who it paired with last or something. And apparently you
have never been able to get it to get to that paired state.

Linus
___
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 24/04/2018 20:08, Linus Torvalds wrote:

On Tue, Apr 24, 2018 at 11:03 AM, Willem Ferguson
 wrote:

Initial handshaking took maybe 40s, showing error message in red bar at
bottom of screen "Timeout"

Hmm. It looks like it first tried to do a BLE download, and that
failed (and this is what took a longish time).

And then because of the failure, it fell back on old-style BT rfcomm, and:


But, if not interrupted, the download proceeded perfectly shortly after the
timeout message and download exited normally on the GUI.

.. apparently rfcomm works for you and the fallback was successful.

Has BLE ever worked for you?


NOPE

I did the same download by setting the dropdown option in the BT setup 
panel to 'Force Classical'. Took about 25 sec to do handshaking, still 
getting "Timeout while trying to connect". Does not appear to make 
difference and successful end result is same as previously, downloading 
all my dives. Interesting error message at end of log. I have never 
managed to get the BLE working. My Petrel is pretty recent, so I am 
reasonably sure it can do both. But the user manual and the Shearwater 
website does not provide any insight into this.


Desktop$ ./Subsurface-4.7.8-73-ga12ea13d51f5-x86_64.AppImage
can't find Subsurface localization for locale "en-ZA"
Missing CAP_NET_ADMIN permission. Cannot determine whether a found 
address is of random or public type.

Starting download from  BT
Starting the thread 0
Enabling GATT request timeout behavior 2
qt_ble_open( 00:13:43:5B:8F:BE )
Creating default GAP/GATT services
addresstypeToUse: "Random"
No settings found for peer device.
HCI event triggered, type: e
HCI event triggered, type: e
timeout while trying to connect to the controller 00:13:43:5B:8F:BE
void QBluetoothSocketPrivate::_q_readNotify() 28 error: -1 "Resource 
temporarily unavailable"

Connection on channel 1 failed. Trying on channel number 5.
INFO: dc_device_open error value of 0
[39.400513] ERROR: Failed to download the dive. [in 
../../src/shearwater_petrel.c:330 (shearwater_petrel_device_foreach)]

Finishing the thread Dive data import error dives downloaded 9

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

Re: Any brave dive computer download testers out there?

[Linus Torvalds]

On Tue, Apr 24, 2018 at 11:03 AM, Willem Ferguson
 wrote:
>
> Initial handshaking took maybe 40s, showing error message in red bar at
> bottom of screen "Timeout"

Hmm. It looks like it first tried to do a BLE download, and that
failed (and this is what took a longish time).

And then because of the failure, it fell back on old-style BT rfcomm, and:

> But, if not interrupted, the download proceeded perfectly shortly after the
> timeout message and download exited normally on the GUI.

.. apparently rfcomm works for you and the fallback was successful.

Has BLE ever worked for you?

   Linus
___
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]

I thought I should attach the log of my BT download from a Petrel 2.

Initial handshaking took maybe 40s, showing error message in red bar at 
bottom of screen "Timeout"


But, if not interrupted, the download proceeded perfectly shortly after 
the timeout message and download exited normally on the GUI.


Desktop$ ./Subsurface-4.7.8-73-ga12ea13d51f5-x86_64.AppImage
Starting download from  BT
Starting the thread 0
Bluez 5 detected.
Enabling GATT request timeout behavior 2
qt_ble_open( 00:13:43:5B:8F:BE )
Creating default GAP/GATT services
Missing CAP_NET_ADMIN permission. Cannot determine whether a found 
address is of random or public type.

addresstypeToUse: "Random"
No settings found for peer device.
HCI event triggered, type: e
HCI event triggered, type: e
timeout while trying to connect to the controller 00:13:43:5B:8F:BE
void QBluetoothSocketPrivate::_q_readNotify() 28 error: -1 "Resource 
temporarily unavailable"

Connection on channel 1 failed. Trying on channel number 5.
INFO: dc_device_open error value of 0
Finishing the thread  dives downloaded 11

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

Re: Any brave dive computer download testers out there?

[Linus Torvalds]

On Tue, Apr 24, 2018 at 5:27 AM, Sébastien Dugué
 wrote:
> On Mon, Apr 23, 2018 at 7:07 PM, Linus Torvalds 
>  wrote:
>>
>> 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.
>
>   My bad, I assumed that feature was only present in the Uwatec DCs where it's
> a timestamp.
>
>   And I cannot imagine how something else might be useful for that purpose...

Well, the fingerprint can anything, which is part of the problem. It
can be an offset into the dive computer buffer. It could be just an
index into the dive computer dive table. It could be the first few
bytes of the dive download that contains the unparsed dive data (which
probably *includes* the dive date, but can have a internal dive
computer dive number)

So in practice it really is random data, and it's not useful to
subsurface directly. We actually do use it to generate a "dive ID"
(that is used to check for duplicates), but that is a fairly simple
and well-defined thing (it's the first four bytes of a SHA1 hash -
either of the fingerprint data, or if the dive computer gives a
particular "Dive ID" string.

And I *really* don't want to save it to our dive logs, because it's
not useful long-term. It's not useful to a user, but it's not even
useful to subsurface long term - only the last dive matters. So saving
it for every dive is fundamentally wrong - it's not how it would ever
be used.

But I think I've come up with an approach that is viable, exactly
*because* we do have a dive ID anyway. We can save the fingerprint
*and* the dive ID in the cache file, and then when we *use* the
fingerprint, we just verify that we have a dive that matches the dive
ID associated with that fingerprint.

So at worst, we'll never use the fingerprint at all, because the last
time somebody did a download, they didn't save the dives (or maybe
they just did't save them into the file we're now using, or didn't
save the *last* dive or whatever).

But then we're no worse off than we are now.

And if we *do* have the dive that is associated with the fingerprint,
then we'll use it, and only download new dives up until that point.

The attached patch seems to work in my (very limited!) testing.

Testers welcome. It should apply fine to any modern subsurface tree
(ie you don't have to have the "NG" branch, but it won't hurt, and
it's what I tested and used as a base).

Linus
 core/libdivecomputer.c | 146 +
 core/libdivecomputer.h |   2 +
 2 files changed, 148 insertions(+)

diff --git a/core/libdivecomputer.c b/core/libdivecomputer.c
index c547a85b2..990904878 100644
--- a/core/libdivecomputer.c
+++ b/core/libdivecomputer.c
@@ -8,6 +8,9 @@
 #include 
 #include 
 #include 
+#include 
+#include 
+#include 
 #include "gettext.h"
 #include "dive.h"
 #include "device.h"
@@ -21,6 +24,9 @@
 
 #include "libdivecomputer.h"
 #include "core/version.h"
+#include "core/qthelper.h"
+#include "core/membuffer.h"
+#include "core/file.h"
 
 //
 // If we have an old libdivecomputer, it doesn't
@@ -785,6 +791,16 @@ static int dive_cb(const unsigned char *data, unsigned int size,
 	dive->dc.model = strdup(devdata->model);
 	dive->dc.diveid = calculate_diveid(fingerprint, fsize);
 
+	/* Should we add it to the cached fingerprint file? */
+	if (fingerprint && fsize && !devdata->fingerprint) {
+		devdata->fingerprint = calloc(fsize, 1);
+		if (devdata->fingerprint) {
+			devdata->fsize = fsize;
+			devdata->fdiveid = dive->dc.diveid;
+			memcpy(devdata->fingerprint, fingerprint, fsize);
+		}
+	}
+
 	// Parse the dive's header data
 	rc = libdc_header_parser (parser, devdata, dive);
 	if (rc != DC_STATUS_SUCCESS) {
@@ -924,6 +940,121 @@ static unsigned int fixup_suunto_versions(device_data_t *devdata, const dc_event
 
 	return serial;
 }
+#ifndef O_BINARY
+  #define O_BINARY 0
+#endif
+static void do_save_fingerprint(device_data_t *devdata, const char *tmp, const char *final)
+{
+	int fd, written = -1;
+
+	fd = subsurface_open(tmp, O_WRONLY | O_BINARY | O_CREAT | O_TRUNC, 0666);
+	if (fd < 0)
+		return;
+
+	/* The fingerprint itself.. */
+	written = write(fd, devdata->fingerprint, devdata->fsize);
+
+	/* ..followed by the dive ID of the fingerprinted dive */
+	if (write(fd, >fdiveid, 4) != 4)
+		written = -1;
+
+	/* I'd like to do fsync() here too, but does Windows support it? */
+	if (close(fd) < 0)
+		written = -1;
+
+	if (written == devdata->fsize) {
+		if (!subsurface_rename(tmp, final))
+			return;
+	}
+	unlink(tmp);
+}
+
+/*
+ * Save the fingerprint after a successful download
+ */
+static void save_fingerprint(device_data_t *devdata)
+{
+	char *dir, *tmp, *final;
+
+	if (!devdata->fingerprint)
+		return;
+
+	dir = format_string("%s/fingerprints", system_default_directory());
+	subsurface_mkdir(dir);
+	tmp = format_string("%s/%04x.tmp", dir, devdata->deviceid);
+	final = format_string("%s/%04x", dir, 

Re: Any brave dive computer download testers out there?

[Sébastien Dugué]

On Mon, Apr 23, 2018 at 7:07 PM, 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.

  My bad, I assumed that feature was only present in the Uwatec DCs where it's
a timestamp.

  And I cannot imagine how something else might be useful for that purpose...

  Seb.
___
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?

[Matt Thompson]

On Mon, Apr 23, 2018 at 9:59 AM, Matt Thompson  wrote:

>
> On Mon, Apr 23, 2018 at 9:51 AM, Dirk Hohndel  wrote:
>
>>
>> > On Apr 23, 2018, at 7:43 AM, Matt Thompson  wrote:
>>
>> > I do have the USB drivers for the D4i installed on macOS and Windows.
>> On all three platforms I was able to successfully download dives using
>> Subsurface 4.7.8.  I take that to mean that I have the correct permissions
>> on the platforms so it is just down to the difference between the -NG and
>> 4.7.8 branches.  I can generate Subsurface and libdivecomputer logs if that
>> would help.
>>
>> This is the logic that I care the most about.
>> If you have situations where 4.7.8 can successfully download, but NG
>> cannot, then I want to see the Subsurface and libdivecomputer logs and
>> understand why that is the case so we can fix this.
>> I am very eager to get NG merged into master, but not at the cost of
>> significant regressions.
>>
>> /D
>>
>> I'll generate the logs this evening and post them here.
>
>
> Here is the libdivecomputer log from macOS.  I verified once again that I
can successfully download dives from 4.7.8 but not from -NG.  I'm not sure
how to generate subsurface logs.  If someone can point me in the right
direction I'll generate that as well.

The console output from the same run was:
Starting download from  /dev/tty.usbserial-STVBTFOQ
Starting the thread 0
INFO: dc_device_open error value of 0
[135.739204] ERROR: Failed to receive the answer. [in
../../src/suunto_d9.c:253 (suunto_d9_device_packet)]
[138.712562] ERROR: Unexpected echo. [in ../../src/suunto_d9.c:239
(suunto_d9_device_packet)]
[141.818176] ERROR: Unexpected echo. [in ../../src/suunto_d9.c:239
(suunto_d9_device_packet)]
[141.836584] ERROR: Failed to read the memory header. [in
../../src/suunto_common2.c:255 (suunto_common2_device_foreach)]
Finishing the thread Dive data import error dives downloaded 0

-Matt


subsurface.log
Description: Binary data
___
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?

[Robert Helling]

Hi,

not that  really followed this and have anything significant to say about dive 
computer download but…

> On 23. Apr 2018, at 20:57, Linus Torvalds  
> wrote:
> 
> It's dangerous because the rule is "once we've downloaded the dives on
> one machine, we don't want to download them again".
> 
> You can see the breakage by:

and you know the obvious solution: store a random base64 encoded string 
(containing what libdc thinks is the „serial number“ and the „fingerprint“) 
with the dive computer field for a dive. Even if that is and additional 100 
bytes it will not significantly bloat our files. And if you don’t want this 
information in the dive, store your hash table of latest dives in the log, as 
it is specific to the log and not the machine. I have great respect for your 
opinion on aesthetic views but here it seems to stop us from doing the right 
thing.

Of course it would be great if libdc provided the information for which dive 
computers this is worthwhile doing (where it prevents downloading the whole 
log).

Just my $.02

Robert


signature.asc
Description: Message signed with OpenPGP
___
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?

[Linus Torvalds]

On Mon, Apr 23, 2018 at 10:07 AM, Linus Torvalds
 wrote:
>
> 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 here's a patch for people to play with if they want to.

This is literally how the fingerprint thing is meant to be used, and
it works, but it's a bit dangerous.

It's dangerous because the rule is "once we've downloaded the dives on
one machine, we don't want to download them again".

You can see the breakage by:

 (a) applying this patch

 (b) downloading some dives into a new empty xml file, or as a
different user (so that you actually download things)

 (c) *NOT* saving the end result, closing subsurface

 (d) opening subsurface again with the same empt xml file, and trying
to download

At that point, the fingerprint code says "I've already downloaded all
the dives on this machine, so you have nothing new to download".

Which is exactly how the feature is designed, so hey, it's doing what
it meant to do. You don't want to re-download the same dives over and
over again, do you?

And if you *do* want to re-download them, you'd better just check the
"Force download all dives" checkbox.

Note that this patch saves the fingerprint in the downloader. It would
probably be better to at *least* wait until the user has pressed "ok"
with the most recent dive checked. That still doesn't mean "saved",
but it's a lot closer.

This has been very lightly tested, and did the right thing with my Perdix AI.

  Linus
 core/libdivecomputer.c | 91 ++
 core/libdivecomputer.h |  2 ++
 2 files changed, 93 insertions(+)

diff --git a/core/libdivecomputer.c b/core/libdivecomputer.c
index c547a85b2..1f7eec2f5 100644
--- a/core/libdivecomputer.c
+++ b/core/libdivecomputer.c
@@ -8,6 +8,9 @@
 #include 
 #include 
 #include 
+#include 
+#include 
+#include 
 #include "gettext.h"
 #include "dive.h"
 #include "device.h"
@@ -21,6 +24,9 @@
 
 #include "libdivecomputer.h"
 #include "core/version.h"
+#include "core/qthelper.h"
+#include "core/membuffer.h"
+#include "core/file.h"
 
 //
 // If we have an old libdivecomputer, it doesn't
@@ -778,6 +784,14 @@ static int dive_cb(const unsigned char *data, unsigned int size,
 		goto error_exit;
 	}
 
+	if (!devdata->fingerprint) {
+		devdata->fingerprint = calloc(fsize, 1);
+		if (devdata->fingerprint) {
+			devdata->fsize = fsize;
+			memcpy(devdata->fingerprint, fingerprint, fsize);
+		}
+	}
+
 	import_dive_number++;
 	dive = alloc_dive();
 
@@ -924,6 +938,70 @@ static unsigned int fixup_suunto_versions(device_data_t *devdata, const dc_event
 
 	return serial;
 }
+#ifndef O_BINARY
+  #define O_BINARY 0
+#endif
+static void do_save_fingerprint(device_data_t *devdata, const char *tmp, const char *final)
+{
+	int fd, written;
+
+	fd = subsurface_open(tmp, O_WRONLY | O_BINARY | O_CREAT | O_TRUNC, 0666);
+	if (fd < 0)
+		return;
+	written = write(fd, devdata->fingerprint, devdata->fsize);
+	if (!close(fd) && written == devdata->fsize) {
+		if (subsurface_rename(tmp, final))
+			return;
+	}
+	unlink(tmp);
+}
+
+/*
+ * Save the fingerprint after a successful download
+ *
+ * NOTE! This should really only be done after the dive data has been
+ * accepted and saved, but there is no real sane way to do that.
+ */
+void save_fingerprint(device_data_t *devdata)
+{
+	char *dir, *tmp, *final;
+
+	if (!devdata->fingerprint)
+		return;
+
+	dir = format_string("%s/fingerprints", system_default_directory());
+	subsurface_mkdir(dir);
+	tmp = format_string("%s/%04x.tmp", dir, devdata->deviceid);
+	final = format_string("%s/%04x", dir, devdata->deviceid);
+	free(dir);
+
+	do_save_fingerprint(devdata, tmp, final);
+	free(tmp);
+	free(final);
+	free(devdata->fingerprint);
+	devdata->fingerprint = NULL;
+}
+
+/*
+ * Look up the fingerprint from the fingerprint caches, and
+ * give it to libdivecomputer to avoid downloading already
+ * downloaded dives.
+ */
+static void lookup_fingerprint(dc_device_t *device, device_data_t *devdata)
+{
+	char *cachename;
+	struct memblock mem;
+
+	if (devdata->force_download)
+		return;
+	cachename = format_string("%s/fingerprints/%04x",
+		system_default_directory(), devdata->deviceid);
+	if (readfile(cachename, ) > 0) {
+		dc_device_set_fingerprint(device, mem.buffer, mem.size);
+		free(mem.buffer);
+	}
+	free(cachename);
+}
 
 static void event_cb(dc_device_t *device, dc_event_type_t event, const void *data, void *userdata)
 {
@@ -964,6 +1042,7 @@ static void event_cb(dc_device_t *device, dc_event_type_t event, const void *dat
 devinfo->firmware, devinfo->firmware,
 devinfo->serial, devinfo->serial);
 		

Re: Any brave dive computer download testers out there?

[Linus Torvalds]

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.

Linus
___
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?

[Matt Thompson]

On Mon, Apr 23, 2018 at 9:51 AM, Dirk Hohndel  wrote:

>
> > On Apr 23, 2018, at 7:43 AM, Matt Thompson  wrote:
>
> > I do have the USB drivers for the D4i installed on macOS and Windows.
> On all three platforms I was able to successfully download dives using
> Subsurface 4.7.8.  I take that to mean that I have the correct permissions
> on the platforms so it is just down to the difference between the -NG and
> 4.7.8 branches.  I can generate Subsurface and libdivecomputer logs if that
> would help.
>
> This is the logic that I care the most about.
> If you have situations where 4.7.8 can successfully download, but NG
> cannot, then I want to see the Subsurface and libdivecomputer logs and
> understand why that is the case so we can fix this.
> I am very eager to get NG merged into master, but not at the cost of
> significant regressions.
>
> /D
>
> I'll generate the logs this evening and post them here.

-Matt
___
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 23, 2018, at 7:43 AM, Matt Thompson  wrote:

> I do have the USB drivers for the D4i installed on macOS and Windows.  On all 
> three platforms I was able to successfully download dives using Subsurface 
> 4.7.8.  I take that to mean that I have the correct permissions on the 
> platforms so it is just down to the difference between the -NG and 4.7.8 
> branches.  I can generate Subsurface and libdivecomputer logs if that would 
> help.

This is the logic that I care the most about.
If you have situations where 4.7.8 can successfully download, but NG cannot, 
then I want to see the Subsurface and libdivecomputer logs and understand why 
that is the case so we can fix this.
I am very eager to get NG merged into master, but not at the cost of 
significant regressions.

/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?

[Matt Thompson]

 Thanks, Jef.

On Mon, Apr 23, 2018 at 4:59 AM, Jef Driesen 
wrote:

> On 2018-04-20 04:56, Matt Thompson wrote:
>
>> My Atomic Cobalt2 worked on Windows and macOS but failed on Linux.  I
>> think
>> the failure on Linux is a configuration issue on my part but for
>> completeness I get the following in the console:
>> ERROR: Failed to open the usb device. [in ../../src/atomics_cobalt.c:117
>> (atomics_cobalt_device_open)]
>> INFO: dc_deveice_open error value of -6
>> I get that error on both Subsurface-4.7.8-73-ga12ea13d5
>> 1f5-x86_64.AppImage
>> and Subsurface-4.7.8-x86_64.AppImage.
>>
>
> This looks like a permission error. Have you installed the necessary udev
> rules?
>
> I added the udev rule in the Subsurface FAQ but it didn't help.  Tonight
I'll try the one you pointed me at below and post back.

Download this file:
>
> https://raw.githubusercontent.com/libdivecomputer/libdivecom
> puter/master/contrib/udev/libdivecomputer.rules
>
> and copy it to /etc/udev/rules.d/ directory.
>
> (This assumes you are in the plugdev group.)
>
> My Suunto D4i failed on all three platforms.  It gave various errors on the
>> platforms:
>> Windows 10:
>>  the red banner at the bottom of the main window with the message
>> "Unsupported operation"
>>
>
> Difficult to tell without further info. Did you install the USB driver?
>
> Fedora: A message box  with the message "Unable to open /dev/ttyUSB0" and a
>> message on the console "ERROR: Failed to receive the answer. [in
>> ../../src/suunto_d9.c:253 (suunto_d9_device_packet)]
>>
>
> Looks again like a permission error. Make sure you're in the dialout group:
>
> sudo usermod -a -G dialout $USER
>
> (You'll have to logout and login again before this takes effect.)
>
> macOS: A message box with the message "Error downloading dive data"
>>
>
> No idea.
>
> I do have the USB drivers for the D4i installed on macOS and Windows.  On
all three platforms I was able to successfully download dives using
Subsurface 4.7.8.  I take that to mean that I have the correct permissions
on the platforms so it is just down to the difference between the -NG and
4.7.8 branches.  I can generate Subsurface and libdivecomputer logs if that
would help.

Thanks,
-Matt
___
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-20 04:56, Matt Thompson wrote:
My Atomic Cobalt2 worked on Windows and macOS but failed on Linux.  I 
think

the failure on Linux is a configuration issue on my part but for
completeness I get the following in the console:
ERROR: Failed to open the usb device. [in 
../../src/atomics_cobalt.c:117

(atomics_cobalt_device_open)]
INFO: dc_deveice_open error value of -6
I get that error on both 
Subsurface-4.7.8-73-ga12ea13d51f5-x86_64.AppImage

and Subsurface-4.7.8-x86_64.AppImage.


This looks like a permission error. Have you installed the necessary 
udev rules?


Download this file:

https://raw.githubusercontent.com/libdivecomputer/libdivecomputer/master/contrib/udev/libdivecomputer.rules

and copy it to /etc/udev/rules.d/ directory.

(This assumes you are in the plugdev group.)

My Suunto D4i failed on all three platforms.  It gave various errors on 
the

platforms:
Windows 10:
 the red banner at the bottom of the main window with the message
"Unsupported operation"


Difficult to tell without further info. Did you install the USB driver?

Fedora: A message box  with the message "Unable to open /dev/ttyUSB0" 
and a

message on the console "ERROR: Failed to receive the answer. [in
../../src/suunto_d9.c:253 (suunto_d9_device_packet)]


Looks again like a permission error. Make sure you're in the dialout 
group:


sudo usermod -a -G dialout $USER

(You'll have to logout and login again before this takes effect.)


macOS: A message box with the message "Error downloading dive data"


No idea.

Jef
___
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?

[Sébastien Dugué]

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.

  Seb.
___
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?

[Sébastien Dugué]

On Sun, Apr 22, 2018 at 9:42 PM, Dirk Hohndel  wrote:
>
>> On Apr 22, 2018, at 12:22 PM, Jef Driesen  wrote:
>>
>> No, the protocol doesn't support that. But it does support downloading only 
>> the new dives. Unfortunately, the only way to take advantage of that is by 
>> means of the libdivecomputer fingerprint feature.
>>
>> This is actually one of those cases where trying to implement the download 
>> only new dives feature entirely on the application side (without using the 
>> fingerprint feature) will always be inefficient. That's because the protocol 
>> works a bit different here. Unlike most other dive computers, it's the dive 
>> computer that does the work. You need to send a timestamp (of the most 
>> recent previously download dive) to the dive computer, and then the dive 
>> computer will only send back the newer dives.
>>
>> The result is that if you don't use the fingerprint feature, then you will 
>> always request ALL dives And once you have all dives, you can ignore the 
>> ones you already had. But at that point you have already downloaded them all.
>
> I know we initially didn't use the fingerprint (5 or so years ago) because 
> back then something was broken with it.
> Linus, is there still a design reason why we can't use it? Because that 
> sounds like a HUGE inefficiency for dive computers like the G2 over BLE...
>

  Not only the G2. My Galileo and TEC 2G  both have the capability and
right now it's so long
downloading all dives before filtering the last few dives...

  Seb.
___
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?

[Rick Walsh]

On 19 April 2018 at 07:01, Dirk Hohndel  wrote:

>
> We now have binaries for Windows, Mac, and Linux (AppImage only) available
> in order for people to test this.
>
> https://github.com/Subsurface-divelog/subsurface/releases/ta
> g/continuous-NG
>
> I'm a bit late to the party, but I've tested the continuous-NG AppImage
(on Fedora 27) and Android (Galaxy S7) builds.

Linux with Shearwater Petrel 2.
Cannot pair in BLE (nothing new here) or Auto modes.  The "Cannot connect
due to pending active LE connections" error message might be interesting,
but I don't know why it occurs.
Can pair in Classic BT mode, but download of dives fails in new logbook
(cannot use my real log since it already contains my last dives).

[rick@localhost Downloads]$ ./Subsurface-4.7.8-73-ga12ea13d51f5-x86_64.AppImage
-v
Subsurface v4.7.8-73-ga12ea13d51f5,
built with libdivecomputer v0.7.0-devel-Subsurface-NG (
b5f53eeb1f5fac951d694c5173470f99d005bf45)
built with Qt Version 5.9.3, runtime from Qt Version 5.9.3
built with libgit2 0.26.0
"validateGL(): created OpenGLContext."
"validateGL(): obtained QOpenGLFunctions."
"validateGL(): detected OpenGL version 3.0."
can't find Qt localization for locale "en-AU" searching in
"/tmp/.mount_SubsurA3AowW/usr/translations"
can't find Subsurface localization for locale "en-AU"
Plugins Directory:  QDir( "/tmp/.mount_SubsurA3AowW/usr/bin" , nameFilters
= { "*" },  QDir::SortFlags( Name | IgnoreCase ) , QDir::Filters(
Dirs|Files|Drives|AllEntries ) )
...
Missing CAP_NET_ADMIN permission. Cannot determine whether a found address
is of random or public type.
Failed to create pairing "org.bluez.Error.InProgress"
Failed to create pairing "org.freedesktop.DBus.Error.NoReply"
Failed to create pairing "org.bluez.Error.InProgress"
Failed to create pairing "org.bluez.Error.InProgress"
Failed to create pairing "org.freedesktop.DBus.Error.NoReply"
Starting download from  BT
Starting the thread 0
Enabling GATT request timeout behavior 2
qt_ble_open( 00:13:43:0E:6B:D0 )
Creating default GAP/GATT services
Cannot connect due to pending active LE connections
HCI event triggered, type: f
RemoteDeviceManager job queue status: true
RemoteDeviceManager finished attempting to close external connections
addresstypeToUse: "Random"
No settings found for peer device.
HCI event triggered, type: 5
HCI event triggered, type: e
HCI event triggered, type: e
HCI event triggered, type: e
HCI event triggered, type: e
timeout while trying to connect to the controller  00:13:43:0E:6B:D0
The connection on RFCOMM channel number 1 took more than expected. Wait
another 15 seconds.
void QBluetoothSocketPrivate::_q_readNotify() 19 error: -1 "Resource
temporarily unavailable"
Failed to connect to device  00:13:43:0E:6B:D0 . Device state
QBluetoothSocket::UnconnectedState . Error:  QBluetoothSocket::
UnknownSocketError
[17.322698] 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
Set the current dive site: 0

Linux with Hollis DG03 (via USB/serial cable).
Download works for 6 dives, then produces a ringbuffer error.  Probably
nothing to do with the current changes.  I previously (last year?) had a
similar error, that Jef fixed in libdivecomputer, but it's here again.  I
rarely download dives from this dive computer (it's a backup that I
sometimes take in the water), so it doesn't get much testing anymore.

^TStarting download from  /dev/ttyUSB0
Starting the thread 0
INFO: dc_device_open error value of 0
[0.351396] ERROR: Invalid ringbuffer pointer detected (0x00fea0 0x001190).
[in ../../src/oceanic_common.c:363 (oceanic_common_device_profile)]
[10.953339] ERROR: Invalid ringbuffer pointer detected (0x00fea0 0x001190).
[in ../../src/oceanic_common.c:441 (oceanic_common_device_profile)]
Finishing the thread Dive data import error dives downloaded 6


Android with Petrel 2
Download failed.  extract from subsurface.log is below.

"23.711: DCDownloadThread started for Petrel 2 on LE:00:13:43:0E:6B:D0"
Starting download from  BT
Starting the thread 0
Creating Android Central/Client support for BTLE
qt_ble_open( 00:13:43:0E:6B:D0 )
"LocalDeviceBroadcastReceiver::onReceive() - event:
android.bluetooth.device.action.ACL_CONNECTED"
Connection updated: error: QLowEnergyController::Error(NoError) oldState:
QLowEnergyController::ControllerState(ConnectingState) newState:
QLowEnergyController::ControllerState(ConnectedState)
connected to the controller for device 00:13:43:0E:6B:D0
  .. 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(0xc92907b0)
Discovery of "{fe25c237-0ece-443c-b0aa-e02033e7029d}" started
 .. done discovering services
 .. discovering details

Re: Any brave dive computer download testers out there?

[Linus Torvalds]

On Sun, Apr 22, 2018 at 1:19 PM, Dirk Hohndel  wrote:
>
> Yeah, it's ugly, but it should make a huge difference in BLE download speed
> if I understand correctly what's going on.

The whole thing is basically completely mis-designed and retarded. On
most dive computers it actually is *worse* than what we do right now.

It also depends on actually remembering the fingerprint, and giving it
back to the right device. Which is hard to begin with, since you don't
get the proper serial number from libdivecomputer, so it's not even
easy to know which fingerprint to use.

So now you have to remember garbage that is irrelevant in 99% of all
cases, that is ugly random data that could be any size, and that you
have to then also match up with the right dive computer based on other
garbage data that isn't even reliable.

Really?

I really don't want to touch it with a ten-foot pole.

Linus
___
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 22, 2018, at 1:09 PM, Linus Torvalds  
> wrote:
> 
> 
> 
> On Sun, Apr 22, 2018, 12:42 Dirk Hohndel  > wrote:
> 
> I know we initially didn't use the fingerprint (5 or so years ago) because 
> back then something was broken with it.
> Linus, is there still a design reason why we can't use it?
> 
> It still has the exact same problem it always had: it's random binary data 
> that we'd have to encode some way. 
> 
> In practice, I suspect it's always just a number, but the interface is nasty.
> 
> It would be much better as a string. Of course. Now it can be anything, so 
> even if it's a string we'd have to encode it somehow.
> 
> And for most dive computers it's pure garbage, and it's impossible to tell 
> which dive computer it actually matters for. So you have to encode this 
> garbage whether it's useful or not.

You make it sound so wonderful... libdivecomputer returns a char * and a size 
to us - which is different for different dive computers. Lovely.
So all we can do is store the size and base64 encode the binary data that we 
get.

Yeah, it's ugly, but it should make a huge difference in BLE download speed if 
I understand correctly what's going on.

/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?

[Linus Torvalds]

On Sun, Apr 22, 2018, 12:42 Dirk Hohndel  wrote:

>
> I know we initially didn't use the fingerprint (5 or so years ago) because
> back then something was broken with it.
> Linus, is there still a design reason why we can't use it?


It still has the exact same problem it always had: it's random binary data
that we'd have to encode some way.

In practice, I suspect it's always just a number, but the interface is
nasty.

It would be much better as a string. Of course. Now it can be anything, so
even if it's a string we'd have to encode it somehow.

And for most dive computers it's pure garbage, and it's impossible to tell
which dive computer it actually matters for. So you have to encode this
garbage whether it's useful or not.

Linus

  Linus
___
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 22-04-18 18:37, Linus Torvalds wrote:

On Sun, Apr 22, 2018 at 3:52 AM, Jérémie Guichard  wrote:


I just tried Scubapro G2 over bluetooth on Android build and it did not
work, but I must say this was already the case on Android for the normal
release.


Hmm. I just tried my G2 over USB, and that worked fine.

But bluetooth connects and starts downloading the data fine, but then
it doesn't import:

 Dive data import error dives downloaded 0

but I did get one "Failed to receive the packet" error. The BLE packet
handling is a _lot_ less reliable than serial is.

Hmm. I tried again, and it worked and downloaded all 78 dives on my G2.

So the bluetooth case works (at least on Linux desktop), it's just:

  (a) really really damn slow, and you can't interrupt it in the middle
because it doesn't download one dive at a time

  (b) fragile and does bad things if you get any BLE errors.

and that makes it less than wonderful (to the point of maybe being useless).

Jef, even when I already have all dives, the G2 download will
apparently just download the whole memory dump and then parse later.
That _really_ doesn't work very well. Is there no way to download one
dive at a time?


No, the protocol doesn't support that. But it does support downloading only the 
new dives. Unfortunately, the only way to take advantage of that is by means of 
the libdivecomputer fingerprint feature.


This is actually one of those cases where trying to implement the download only 
new dives feature entirely on the application side (without using the 
fingerprint feature) will always be inefficient. That's because the protocol 
works a bit different here. Unlike most other dive computers, it's the dive 
computer that does the work. You need to send a timestamp (of the most recent 
previously download dive) to the dive computer, and then the dive computer will 
only send back the newer dives.


The result is that if you don't use the fingerprint feature, then you will 
always request ALL dives And once you have all dives, you can ignore the ones 
you already had. But at that point you have already downloaded them all.


Jef
___
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?

[Linus Torvalds]

On Sun, Apr 22, 2018 at 3:52 AM, Jérémie Guichard  wrote:
>
> I just tried Scubapro G2 over bluetooth on Android build and it did not
> work, but I must say this was already the case on Android for the normal
> release.

Hmm. I just tried my G2 over USB, and that worked fine.

But bluetooth connects and starts downloading the data fine, but then
it doesn't import:

Dive data import error dives downloaded 0

but I did get one "Failed to receive the packet" error. The BLE packet
handling is a _lot_ less reliable than serial is.

Hmm. I tried again, and it worked and downloaded all 78 dives on my G2.

So the bluetooth case works (at least on Linux desktop), it's just:

 (a) really really damn slow, and you can't interrupt it in the middle
because it doesn't download one dive at a time

 (b) fragile and does bad things if you get any BLE errors.

and that makes it less than wonderful (to the point of maybe being useless).

Jef, even when I already have all dives, the G2 download will
apparently just download the whole memory dump and then parse later.
That _really_ doesn't work very well. Is there no way to download one
dive at a time?

   Linus
___
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 22, 2018, at 6:17 AM, Jef Driesen  wrote:
> 
> It looks like some data got transferred succesfully. But then the logging 
> stops. Can you send the libdivecomputer logfile? That should give some more 
> info. (I'm not sure whether android app supports saving libdc log.)

It does, it's in the settings. And subsurface.log and libdivecomputer.log will 
be in the root of your storage device.
The latest beta builds actually show a few more interactions with the DC than 
earlier versions did.

/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]

It looks like some data got transferred succesfully. But then the logging 
stops. Can you send the libdivecomputer logfile? That should give some more 
info. (I'm not sure whether android app supports saving libdc log.)

Jef

On April 22, 2018 12:52:48 PM GMT+02:00, "Jérémie Guichard" 
 wrote:
>Hi guys,
>
>I just tried Scubapro G2 over bluetooth on Android build and it did not
>work, but I must say this was already the case on Android for the
>normal
>release.
>This use case was working few month ago but cannot remember the version
>it
>was.
>
>I'm not sure it actually helps but I attached the log file.
>
>Jeremie
>
>
>
>2018-04-20 23:10 GMT+07:00 Murillo Bernardes :
>
>> Successfully downloaded dives on a Mac from:
>> - Oceanic OCi over USB
>> - Perdix AI over BLE
>>
>> Murillo Bernardes
>>
>> On Fri, Apr 20, 2018 at 1:05 PM, Jérémie Guichard
>
>> wrote:
>>
>>> Hey guys,
>>>
>>> Just tried this build on Windows 10: https://github.com/Subsurf
>>> ace-divelog/subsurface/releases/download/continuous-NG/
>>> subsurface-4.7.8-73-ga12ea13d51f5.exe
>>>
>>> With Scubapro G2 and Suunto Zoop over USB. Seems to work like a
>charm.
>>>
>>> Jeremie
>>>
>>> 2018-04-20 9:56 GMT+07:00 Matt Thompson :
>>>


 On Wed, Apr 18, 2018 at 4:01 PM, Dirk Hohndel 
>wrote:

>
> We now have binaries for Windows, Mac, and Linux (AppImage only)
> available in order for people to test this.
>
> https://github.com/Subsurface-divelog/subsurface/releases/ta
> g/continuous-NG
>
>
> I tested all three of my computers on Windows 10, macOS 10.13.4,
>and
 Fedora 27.

 My Aqualung i750TC worked correctly on all three platforms using
>the USB
 cable.

 My Atomic Cobalt2 worked on Windows and macOS but failed on Linux. 
>I
 think the failure on Linux is a configuration issue on my part but
>for
 completeness I get the following in the console:
 ERROR: Failed to open the usb device. [in
>../../src/atomics_cobalt.c:117
 (atomics_cobalt_device_open)]
 INFO: dc_deveice_open error value of -6
 I get that error on both
>Subsurface-4.7.8-73-ga12ea13d51f5-x86_64.AppImage
 and Subsurface-4.7.8-x86_64.AppImage.

 My Suunto D4i failed on all three platforms.  It gave various
>errors on
 the platforms:
 Windows 10:
  the red banner at the bottom of the main window with the message
 "Unsupported operation"

 Fedora: A message box  with the message "Unable to open
>/dev/ttyUSB0"
 and a message on the console "ERROR: Failed to receive the answer.
>[in
 ../../src/suunto_d9.c:253 (suunto_d9_device_packet)]

 macOS: A message box with the message "Error downloading dive data"



 ___
 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
>>>
>>>
>>
>> ___
>> 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: Any brave dive computer download testers out there?

[Jérémie Guichard]

Hi guys,

I just tried Scubapro G2 over bluetooth on Android build and it did not
work, but I must say this was already the case on Android for the normal
release.
This use case was working few month ago but cannot remember the version it
was.

I'm not sure it actually helps but I attached the log file.

Jeremie



2018-04-20 23:10 GMT+07:00 Murillo Bernardes :

> Successfully downloaded dives on a Mac from:
> - Oceanic OCi over USB
> - Perdix AI over BLE
>
> Murillo Bernardes
>
> On Fri, Apr 20, 2018 at 1:05 PM, Jérémie Guichard 
> wrote:
>
>> Hey guys,
>>
>> Just tried this build on Windows 10: https://github.com/Subsurf
>> ace-divelog/subsurface/releases/download/continuous-NG/
>> subsurface-4.7.8-73-ga12ea13d51f5.exe
>>
>> With Scubapro G2 and Suunto Zoop over USB. Seems to work like a charm.
>>
>> Jeremie
>>
>> 2018-04-20 9:56 GMT+07:00 Matt Thompson :
>>
>>>
>>>
>>> On Wed, Apr 18, 2018 at 4:01 PM, Dirk Hohndel  wrote:
>>>

 We now have binaries for Windows, Mac, and Linux (AppImage only)
 available in order for people to test this.

 https://github.com/Subsurface-divelog/subsurface/releases/ta
 g/continuous-NG


 I tested all three of my computers on Windows 10, macOS 10.13.4, and
>>> Fedora 27.
>>>
>>> My Aqualung i750TC worked correctly on all three platforms using the USB
>>> cable.
>>>
>>> My Atomic Cobalt2 worked on Windows and macOS but failed on Linux.  I
>>> think the failure on Linux is a configuration issue on my part but for
>>> completeness I get the following in the console:
>>> ERROR: Failed to open the usb device. [in ../../src/atomics_cobalt.c:117
>>> (atomics_cobalt_device_open)]
>>> INFO: dc_deveice_open error value of -6
>>> I get that error on both Subsurface-4.7.8-73-ga12ea13d51f5-x86_64.AppImage
>>> and Subsurface-4.7.8-x86_64.AppImage.
>>>
>>> My Suunto D4i failed on all three platforms.  It gave various errors on
>>> the platforms:
>>> Windows 10:
>>>  the red banner at the bottom of the main window with the message
>>> "Unsupported operation"
>>>
>>> Fedora: A message box  with the message "Unable to open /dev/ttyUSB0"
>>> and a message on the console "ERROR: Failed to receive the answer. [in
>>> ../../src/suunto_d9.c:253 (suunto_d9_device_packet)]
>>>
>>> macOS: A message box with the message "Error downloading dive data"
>>>
>>>
>>>
>>> ___
>>> 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
>>
>>
>
> ___
> subsurface mailing list
> subsurface@subsurface-divelog.org
> http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
>
>


subsurface.log
Description: Binary data
___
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?

[Jérémie Guichard]

Hey guys,

Just tried this build on Windows 10:
https://github.com/Subsurface-divelog/subsurface/releases/download/continuous-NG/subsurface-4.7.8-73-ga12ea13d51f5.exe

With Scubapro G2 and Suunto Zoop over USB. Seems to work like a charm.

Jeremie

2018-04-20 9:56 GMT+07:00 Matt Thompson :

>
>
> On Wed, Apr 18, 2018 at 4:01 PM, Dirk Hohndel  wrote:
>
>>
>> We now have binaries for Windows, Mac, and Linux (AppImage only)
>> available in order for people to test this.
>>
>> https://github.com/Subsurface-divelog/subsurface/releases/ta
>> g/continuous-NG
>>
>>
>> I tested all three of my computers on Windows 10, macOS 10.13.4, and
> Fedora 27.
>
> My Aqualung i750TC worked correctly on all three platforms using the USB
> cable.
>
> My Atomic Cobalt2 worked on Windows and macOS but failed on Linux.  I
> think the failure on Linux is a configuration issue on my part but for
> completeness I get the following in the console:
> ERROR: Failed to open the usb device. [in ../../src/atomics_cobalt.c:117
> (atomics_cobalt_device_open)]
> INFO: dc_deveice_open error value of -6
> I get that error on both Subsurface-4.7.8-73-ga12ea13d51f5-x86_64.AppImage
> and Subsurface-4.7.8-x86_64.AppImage.
>
> My Suunto D4i failed on all three platforms.  It gave various errors on
> the platforms:
> Windows 10:
>  the red banner at the bottom of the main window with the message
> "Unsupported operation"
>
> Fedora: A message box  with the message "Unable to open /dev/ttyUSB0" and
> a message on the console "ERROR: Failed to receive the answer. [in
> ../../src/suunto_d9.c:253 (suunto_d9_device_packet)]
>
> macOS: A message box with the message "Error downloading dive data"
>
>
>
> ___
> 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: Any brave dive computer download testers out there?

[Matt Thompson]

On Wed, Apr 18, 2018 at 4:01 PM, Dirk Hohndel  wrote:

>
> We now have binaries for Windows, Mac, and Linux (AppImage only) available
> in order for people to test this.
>
> https://github.com/Subsurface-divelog/subsurface/releases/
> tag/continuous-NG
>
>
> I tested all three of my computers on Windows 10, macOS 10.13.4, and
Fedora 27.

My Aqualung i750TC worked correctly on all three platforms using the USB
cable.

My Atomic Cobalt2 worked on Windows and macOS but failed on Linux.  I think
the failure on Linux is a configuration issue on my part but for
completeness I get the following in the console:
ERROR: Failed to open the usb device. [in ../../src/atomics_cobalt.c:117
(atomics_cobalt_device_open)]
INFO: dc_deveice_open error value of -6
I get that error on both Subsurface-4.7.8-73-ga12ea13d51f5-x86_64.AppImage
and Subsurface-4.7.8-x86_64.AppImage.

My Suunto D4i failed on all three platforms.  It gave various errors on the
platforms:
Windows 10:
 the red banner at the bottom of the main window with the message
"Unsupported operation"

Fedora: A message box  with the message "Unable to open /dev/ttyUSB0" and a
message on the console "ERROR: Failed to receive the answer. [in
../../src/suunto_d9.c:253 (suunto_d9_device_packet)]

macOS: A message box with the message "Error downloading dive data"
___
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?

[Miika Turkia]

On Wed, Apr 18, 2018 at 10:12 PM, Miika Turkia 
wrote:

> On Wed, Apr 18, 2018 at 9:47 PM, Linus Torvalds <
> torva...@linux-foundation.org> wrote:
>
>> On Wed, Apr 18, 2018 at 11:31 AM, Miika Turkia 
>> wrote:
>> >
>> > I failed with BT download (OSTC Sport). But my download fails also with
>> the
>> > release version of Subsurface. Unpairing-pairing works but no download
>> with
>> > subsurface on Linux desktop for me :(
>>
>> Is the OSTC sport a rfcomm (legacy BT) device?
>>
>> I don't have any of those, so I couldn't test it.
>>
>
> Yep, good old fashioned fast bluetooth (when it works). I just tested with
> some appimages that are laying around on my machine and it works with
>
> Subsurface v4.7.4-3-g6addfe16605b,
> built with libdivecomputer v0.6.0-devel-Subsurface-branch (
> 7de3a549ee588fef4702ee9d894e390aca43950d)
>
> The latest appimage and normal binary are both not working. So the stuff
> broke down some time between the 4.7.4 and 4.7.8, but I have currently no
> idea when. I might have a change to look into this tomorrow, but after that
> it'll be at least a week when I have no change of doing anything related.
>

When using Subsurface version 6addfe16605b0257f6c42b0adb75c8ae157626f5; BT
download with libdivecomputer 54f6bff9290906a62628c85e1adb3a74ca487722
works but with 8ae735a4d70307ebe2a42d315697f02ce71dbe88 does not. Running
out of time for now so have to leave at this.

miika
___
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 19/04/2018 18:03, Hartley Horwitz wrote:

I plead ignorance.  I didn't realize that CCR use IrDA.
My point was that I'd be happy to forgo some of the new wiz-bang 
features and just have a stable 'old' version of Subsurface if that 
allows the developers the freedom to move quicker on developing newer 
features.  Many of those new features are targeting Tech divers and so 
supporting IrDA makes sense.


As for my own kit, I use a regulator from the 1980's and my dive 
computer is from 2006, so I've never been accused of using the latest 
gear.


...Hartley
No problem at all. IrDA is old-fashioned, but not obsolete. It is freely 
available on the market and until last year, was the technology of 
Uwatec's leading dive computer (the Sol). Technology, by its very 
nature, changes all the time and requires users to adapt all the time. I 
am probably pretty old-fashioned, but I am resistant to tecnology for 
new technology's sake. From what I have heard and seen, I am not 
convinced that BTLE provides any advantage above IrDA (both of these 
rather non-standardised and idiosyncratic) in terms of ease of use and 
efficiency. To see the bad side of IrDA, just go and look what Mares 
have gone and done with it. The fact that Apple decided to go BTLE 
should not be a market driving force - maybe Apple did not reach a good 
decision, or maybe they chose it as a mechanism to lock users into the 
Apple-specific implementation in order to buy more of Apple.

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

Re: Any brave dive computer download testers out there?

[Hartley Horwitz]

I plead ignorance.  I didn't realize that CCR use IrDA.
My point was that I'd be happy to forgo some of the new wiz-bang features
and just have a stable 'old' version of Subsurface if that allows the
developers the freedom to move quicker on developing newer features.  Many
of those new features are targeting Tech divers and so supporting IrDA
makes sense.

As for my own kit, I use a regulator from the 1980's and my dive computer
is from 2006, so I've never been accused of using the latest gear.

...Hartley

On Thu, Apr 19, 2018 at 3:48 AM, Sébastien Dugué <
sebastien.dugue.subsurf...@gmail.com> wrote:

> On Wed, Apr 18, 2018 at 10:15 PM, Willem Ferguson
>  wrote:
> > From phone. You guys in the developed world have resources for all the
> > latest kit. I my country iRda is commonly used. In addition the CCR
> > community worldwide often use iRda. It has a significant role to play at
> > least for the next 10 years. Therefore I strongly argue for the continued
> > support of iRda. Subsurface is not meant only for the divers with the
> latest
> > kit. Kind regards, willem
>
>   I second that, a lot of divers around me are using Uwatec irda DCs.
>
>   Sébastien.
>
___
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]

I'm sure that's feasible. For us using the Qt QSettings system is a major
convenience as it works on all of our target OSs. I haven't looked into
options to export the QSettings and being able to restore them.

One way to work around this is to start Subsurface with an option to run
it as a different user - as that will create a separate set of settings.

Start subsurface.exe with the --user=test flag (or some other user name)

/D

On Thu, Apr 19, 2018 at 04:58:44PM +0200, tormento wrote:
> That's a pity.
> 
> Subsurface already creates its own directories in Local and Roaming. Let's
> put settings there too...
> 
> Do you think it's feasable?
> 
> Alberto
> 
> 2018-04-19 14:31 GMT+02:00 Dirk Hohndel :
> 
> > In Windows the settings are all stored in the registry. So no easy way
> > (that I'm
> > aware of) of backing them up
> >
> > /D
> >
> > On Apr 19, 2018, at 1:26 PM, tormento  wrote:
> >
> > Windows 10 x64, sorry.
> >
> > Il giorno gio 19 apr 2018 alle 12:22 Dirk Hohndel  ha
> > scritto:
> >
> >> On Thu, Apr 19, 2018 at 09:25:19AM +0200, tormento wrote:
> >> > I will give a try to NG.
> >> >
> >> > Where does the stable Subsurface save the configuration file with cloud
> >> > password etc? I'd like to make a backup.
> >>
> >> Depends on your OS. We rely on Qt to do that for us.
> >> Look at http://doc.qt.io/qt-5/qsettings.html under Platform-Specific
> >> Notes
> >>
> >> /D
> >>
> > ___
> > 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

___
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?

[tormento]

That's a pity.

Subsurface already creates its own directories in Local and Roaming. Let's
put settings there too...

Do you think it's feasable?

Alberto

2018-04-19 14:31 GMT+02:00 Dirk Hohndel :

> In Windows the settings are all stored in the registry. So no easy way
> (that I'm
> aware of) of backing them up
>
> /D
>
> On Apr 19, 2018, at 1:26 PM, tormento  wrote:
>
> Windows 10 x64, sorry.
>
> Il giorno gio 19 apr 2018 alle 12:22 Dirk Hohndel  ha
> scritto:
>
>> On Thu, Apr 19, 2018 at 09:25:19AM +0200, tormento wrote:
>> > I will give a try to NG.
>> >
>> > Where does the stable Subsurface save the configuration file with cloud
>> > password etc? I'd like to make a backup.
>>
>> Depends on your OS. We rely on Qt to do that for us.
>> Look at http://doc.qt.io/qt-5/qsettings.html under Platform-Specific
>> Notes
>>
>> /D
>>
> ___
> 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: Any brave dive computer download testers out there?

[Dirk Hohndel]

> On Apr 19, 2018, at 3:31 PM, Robert Helling  wrote:
> 
> Dirk,
> 
>> On 19. Apr 2018, at 14:34, Dirk Hohndel > > wrote:
>> 
>> That's missing the listing of all the supported dive computers that we 
>> usually create at startup.
>> I'm confused. What else is new.
> 
> 
> isn’t this only logged in debug mode?

The way this is logged right now is broken. I just pushed a commit to the 
branch that hopefully fixes that.

/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]

In Windows the settings are all stored in the registry. So no easy way (that I'm
aware of) of backing them up

/D

> On Apr 19, 2018, at 1:26 PM, tormento  wrote:
> 
> Windows 10 x64, sorry.
> 
> Il giorno gio 19 apr 2018 alle 12:22 Dirk Hohndel  > ha scritto:
> On Thu, Apr 19, 2018 at 09:25:19AM +0200, tormento wrote:
> > I will give a try to NG.
> > 
> > Where does the stable Subsurface save the configuration file with cloud
> > password etc? I'd like to make a backup.
> 
> Depends on your OS. We rely on Qt to do that for us.
> Look at http://doc.qt.io/qt-5/qsettings.html 
>  under Platform-Specific Notes
> 
> /D
> ___
> 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: Any brave dive computer download testers out there?

[Dirk Hohndel]

> On Apr 19, 2018, at 1:42 PM, Chirana Gheorghita Eugeniu Theodor 
>  wrote:
> 
> Here is it.

That's missing the listing of all the supported dive computers that we usually 
create at startup.
I'm confused. What else is new.

Let me investigate why that's the case...

/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?

[tormento]

Windows 10 x64, sorry.

Il giorno gio 19 apr 2018 alle 12:22 Dirk Hohndel  ha
scritto:

> On Thu, Apr 19, 2018 at 09:25:19AM +0200, tormento wrote:
> > I will give a try to NG.
> >
> > Where does the stable Subsurface save the configuration file with cloud
> > password etc? I'd like to make a backup.
>
> Depends on your OS. We rely on Qt to do that for us.
> Look at http://doc.qt.io/qt-5/qsettings.html under Platform-Specific Notes
>
> /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 Thu, Apr 19, 2018 at 08:17:56AM +, Chirana Gheorghita Eugeniu Theodor 
wrote:
> I would test but it seems that my tusa zen iq-900 isnot present in this
> version of libdivecomputer (android)

That's odd. Which dive computers does it show as supported? Could you send
us the subsurface.log file (you can attach this to an email on your
Android device - it should be in the root of your storage device)

/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 Thu, Apr 19, 2018 at 09:25:19AM +0200, tormento wrote:
> I will give a try to NG.
> 
> Where does the stable Subsurface save the configuration file with cloud
> password etc? I'd like to make a backup.

Depends on your OS. We rely on Qt to do that for us.
Look at http://doc.qt.io/qt-5/qsettings.html under Platform-Specific Notes

/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?

[Sébastien Dugué]

Thanks Jef, this may indeed be a good starting point.

Sébastien.

On Thu, Apr 19, 2018 at 10:20 AM, Jef Driesen  wrote:
> On 2018-04-19 09:42, Sébastien Dugué wrote:
>>
>> On Thu, Apr 19, 2018 at 1:50 AM, Linus Torvalds
>>  wrote:
>>>
>>> On Wed, Apr 18, 2018 at 4:18 PM, Linus Torvalds
>>>  wrote:


 Hmm. Which IRDA chip is it that is in the Uwatec dongle?

 Is it perhaps the MosChip MCS7780? You'd know, because then it would
 be using USB ID 9710:7780. That seems to be the common case.
>>>
>>>
>>> Hmm. Googling around, I see that it might also be the Sigmatel
>>> Stir4200 (USB ID 066F:4210).
>>>
>>> That actually has better documentation, and shows exactly the framing
>>> for the normal MIR format (which it would be for the normal 9600
>>> baud). I suspect the MCS7780 needs that same format, it's just not
>>> documented as well.
>>>
>>> The packet wrapping looks like this:
>>>
>>> 0x55 0xaa 2-byte LE length, 0xC0*n  .. escaped data .. 2-byte LE CRC
>>> 0xc1
>>>
>>> and from what I can tell, the Stir4200 also resets to sane default
>>> values (9600 baud SIR).
>>>
>>> But you may have to do some USB control transfers to set the data
>>> direction. It *looks* like the MCS7780 is simpler and defaults to just
>>> "automatic data direction" (which presumably just means "send if there
>>> is TX data, receive otherwise").
>>
>>
>>   Yes, but to me talking to the chip is the easy part. I'm more concerned
>> about implementing enough of the irda protocol stack to be able to talk
>> to all those embedded stacks.
>
>
> I discovered this a while ago:
>
> https://github.com/Diveboard/DC-agent/tree/master/3d-party/irda_mac
>
> It seems to be based on some minimal IrDA stack for micro-controllers:
>
> http://web.archive.org/web/20061124205138/www.blaulogic.com/pico_irda.shtml
>
> This is probably a good starting point!
>
> Jef
___
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-19 09:42, Sébastien Dugué wrote:

On Thu, Apr 19, 2018 at 1:50 AM, Linus Torvalds
 wrote:

On Wed, Apr 18, 2018 at 4:18 PM, Linus Torvalds
 wrote:


Hmm. Which IRDA chip is it that is in the Uwatec dongle?

Is it perhaps the MosChip MCS7780? You'd know, because then it would
be using USB ID 9710:7780. That seems to be the common case.


Hmm. Googling around, I see that it might also be the Sigmatel
Stir4200 (USB ID 066F:4210).

That actually has better documentation, and shows exactly the framing
for the normal MIR format (which it would be for the normal 9600
baud). I suspect the MCS7780 needs that same format, it's just not
documented as well.

The packet wrapping looks like this:

0x55 0xaa 2-byte LE length, 0xC0*n  .. escaped data .. 2-byte LE 
CRC 0xc1


and from what I can tell, the Stir4200 also resets to sane default
values (9600 baud SIR).

But you may have to do some USB control transfers to set the data
direction. It *looks* like the MCS7780 is simpler and defaults to just
"automatic data direction" (which presumably just means "send if there
is TX data, receive otherwise").


  Yes, but to me talking to the chip is the easy part. I'm more 
concerned

about implementing enough of the irda protocol stack to be able to talk
to all those embedded stacks.


I discovered this a while ago:

https://github.com/Diveboard/DC-agent/tree/master/3d-party/irda_mac

It seems to be based on some minimal IrDA stack for micro-controllers:

http://web.archive.org/web/20061124205138/www.blaulogic.com/pico_irda.shtml

This is probably a good starting point!

Jef
___
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?

[Chirana Gheorghita Eugeniu Theodor]

I would test but it seems that my tusa zen iq-900 isnot present in this
version of libdivecomputer (android)

On Thu, Apr 19, 2018, 00:01 Dirk Hohndel  wrote:

>
> We now have binaries for Windows, Mac, and Linux (AppImage only) available
> in order for people to test this.
>
> https://github.com/Subsurface-divelog/subsurface/releases/tag/continuous-NG
>
> /D
> ___
> 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: Any brave dive computer download testers out there?

[Willem Ferguson]

On 18/04/2018 05:35, Linus Torvalds wrote:

  So libdivecomputer has a new custom IO model, which allows us to drop
our home-made one.

However, that new model is fairly different from our old model, and
there were other updates too, so the changes are "flag-day" changes
where we switch over both libdivecomputer and subsurface together.

I have *TEST* branches for both, in case people want to help test.
Note! I only do source code, so this really only works for people who
can build their own subsurface binary, but if you are one of those
hardy souls, it realy would be good to get more cases tested.

I have verified and downloaded:

  - Shearwater Perdix AI over BLE

  - Suunto EON Core over USB

  - Suunto Vyper Air over the Suunto USB serial line

so many of the transports have been tested. But I don't have any
rfcomm devices (ie old bluetooth) and I don't have any "direct USB"
devices (eg Atomics Aquatics Cobalt).

Also, I only tested on my Linux desktop, because that's how I roll.

Anyway, if you can build subsurface and libdivercomputer, and are
interested in testing, I have test branches for both:

  
It may break things. I'd be surprised if it doesn't. So keep that in

mind. This is very much for people who are happy playing around and
helping get some coverage for early work.

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


I tested on a Petrel 2. On the desktop, the following:

I tried all three options (auto, classical,BLE) in that order. For Auto 
and classical, upload worked. Only one comment, the initial handshaking 
appeared to take quite a bit longer than usual. In fact, a warning 
appeared in the red bar at the bottom of the Subsurface screen "Timeout 
connecting to device...". Yet, eventually, the transfer did take place 
and successfully. For BLE, the desktop could not connect to the Petrel. 
I am reasonably sure the newer Petrel 2 like mine are dual mode but I am 
not 100% sure of this. Not much info on the Shearwater web site that I 
could see.


My Galileo downloaded well through IrDA.

As far as mobile version is concerned, I did not get far because Android 
complains of a corrupt package. I suspect the problem lies with my 
Android, not with the package.


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

Re: Any brave dive computer download testers out there?

[Sébastien Dugué]

On Wed, Apr 18, 2018 at 10:15 PM, Willem Ferguson
 wrote:
> From phone. You guys in the developed world have resources for all the
> latest kit. I my country iRda is commonly used. In addition the CCR
> community worldwide often use iRda. It has a significant role to play at
> least for the next 10 years. Therefore I strongly argue for the continued
> support of iRda. Subsurface is not meant only for the divers with the latest
> kit. Kind regards, willem

  I second that, a lot of divers around me are using Uwatec irda DCs.

  Sébastien.
___
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?

[Sébastien Dugué]

On Thu, Apr 19, 2018 at 1:50 AM, Linus Torvalds
 wrote:
> On Wed, Apr 18, 2018 at 4:18 PM, Linus Torvalds
>  wrote:
>>
>> Hmm. Which IRDA chip is it that is in the Uwatec dongle?
>>
>> Is it perhaps the MosChip MCS7780? You'd know, because then it would
>> be using USB ID 9710:7780. That seems to be the common case.
>
> Hmm. Googling around, I see that it might also be the Sigmatel
> Stir4200 (USB ID 066F:4210).
>
> That actually has better documentation, and shows exactly the framing
> for the normal MIR format (which it would be for the normal 9600
> baud). I suspect the MCS7780 needs that same format, it's just not
> documented as well.
>
> The packet wrapping looks like this:
>
> 0x55 0xaa 2-byte LE length, 0xC0*n  .. escaped data .. 2-byte LE CRC 0xc1
>
> and from what I can tell, the Stir4200 also resets to sane default
> values (9600 baud SIR).
>
> But you may have to do some USB control transfers to set the data
> direction. It *looks* like the MCS7780 is simpler and defaults to just
> "automatic data direction" (which presumably just means "send if there
> is TX data, receive otherwise").

  Yes, but to me talking to the chip is the easy part. I'm more concerned
about implementing enough of the irda protocol stack to be able to talk
to all those embedded stacks.

  Sébastien.
___
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?

[Sébastien Dugué]

On Thu, Apr 19, 2018 at 1:18 AM, Linus Torvalds
 wrote:
>
> Hmm. Which IRDA chip is it that is in the Uwatec dongle?
>
> Is it perhaps the MosChip MCS7780? You'd know, because then it would
> be using USB ID 9710:7780. That seems to be the common case.

  Yep, as Willem pointed out, this is the one used in the overpriced Uwated
adapter.

  I personally use a STIR4200 and it looks pretty straightforward too.

>
> You can find datasheets for it by just googling for
>
> MCS7780 Datasheet type:pdf
>
> and from a quick look, the setup looks pretty simple. It has various
> configuration bits, but it looks like the control register defaults to
> al the normal bits, so you may not even need to touch it.
>
> For example, it seems to default to 9600 baud, all automatic defaults
> for SIR. Maybe I missed some bit, but it basically seems to default to
> "ready to simply be used".
>
> So you might be able to just set up plain USB bulk transfers to send
> and receive the data. *Maybe* you need some setup, but it's not clear
> that you do.

  Yes, we propably need to add framing (at least the stir4200 needs it),
plus talking the right irda protocol and add discovery and it should be OK.

>
> So accessing this thing with libusb looks fairly straightforward, if
> you already have packet traces and know what the wrapping is (I think
> the MCS7780 just wants to add a 2-byte little-endian packet length to
> the data, but then whatever the IRDA address encapsulation etc is I
> have no idea).

  That's the hard part, faking and irda stack that is able to talk to the stacks
implemented in all those irda DCs.

  Sadly, I could not get my hands back on those traces. I'll have to
search some more...

  Sébastien.
___
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?

[tormento]

I will give a try to NG.

Where does the stable Subsurface save the configuration file with cloud
password etc? I'd like to make a backup.

2018-04-19 8:39 GMT+02:00 Robert Helling :

> Hi,
>
> On 19. Apr 2018, at 08:01, Robert Helling  wrote:
>
> I double checked: In 4.7.8, I can connect with BT classic, in your branch
> I cannot. Also, in the release version I can change the settings in BLE
> while in your branch I get an „Unsupported operation“ error (BTW, we should
> show that error on the configure dive computer window not on the main
> window which is in the background…).
>
> All this on Mac with OSTC Sport.
>
>
> I finally managed to find a replacement battery for my Suunto Vyper, so I
> could try this as well (this is serial over USB). Turns out, doesn’t work:
> Download seems to start, LED on cable flashes but then stops with generic
> error message immediately. Dive computer config doesn’t even start.
>
> Both works with 478 release.
>
> Best
> Robert
>
> ___
> 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: Any brave dive computer download testers out there?

[Robert Helling]

Hi,

> On 19. Apr 2018, at 08:01, Robert Helling  wrote:
> 
> I double checked: In 4.7.8, I can connect with BT classic, in your branch I 
> cannot. Also, in the release version I can change the settings in BLE while 
> in your branch I get an „Unsupported operation“ error (BTW, we should show 
> that error on the configure dive computer window not on the main window which 
> is in the background…).
> 
> All this on Mac with OSTC Sport.

I finally managed to find a replacement battery for my Suunto Vyper, so I could 
try this as well (this is serial over USB). Turns out, doesn’t work: Download 
seems to start, LED on cable flashes but then stops with generic error message 
immediately. Dive computer config doesn’t even start.

Both works with 478 release.

Best
Robert


signature.asc
Description: Message signed with OpenPGP
___
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?

[Robert Helling]

LInus,

> On 19. Apr 2018, at 00:54, Linus Torvalds  
> wrote:
> 
> Did this work with the previous release (4.7.8 or whatever)?
> 
> I had been hoping that I got the config thing right, but I've never
> used it or tested it (I'm not sure I even have any of the dive
> computers that are supported), so that was purely a "it builds".


I double checked: In 4.7.8, I can connect with BT classic, in your branch I 
cannot. Also, in the release version I can change the settings in BLE while in 
your branch I get an „Unsupported operation“ error (BTW, we should show that 
error on the configure dive computer window not on the main window which is in 
the background…).

All this on Mac with OSTC Sport.

Best
Robert


signature.asc
Description: Message signed with OpenPGP
___
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 19, 2018, at 12:54 AM, Linus Torvalds  
> wrote:
> 
> On Wed, Apr 18, 2018 at 3:37 PM, Robert Helling  wrote:
>> 
>> Couldn’t get the dive computer configuration to work either with BLE or 
>> classic.
> 
> Did this work with the previous release (4.7.8 or whatever)?
> 
> I had been hoping that I got the config thing right, but I've never
> used it or tested it (I'm not sure I even have any of the dive
> computers that are supported), so that was purely a "it builds".

Didn't the config code support the Suunto Vyper Air?

Ideally we'd get Anton to make sure that this part of the code still works.

/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?

[Linus Torvalds]

On Wed, Apr 18, 2018 at 4:18 PM, Linus Torvalds
 wrote:
>
> Hmm. Which IRDA chip is it that is in the Uwatec dongle?
>
> Is it perhaps the MosChip MCS7780? You'd know, because then it would
> be using USB ID 9710:7780. That seems to be the common case.

Hmm. Googling around, I see that it might also be the Sigmatel
Stir4200 (USB ID 066F:4210).

That actually has better documentation, and shows exactly the framing
for the normal MIR format (which it would be for the normal 9600
baud). I suspect the MCS7780 needs that same format, it's just not
documented as well.

The packet wrapping looks like this:

0x55 0xaa 2-byte LE length, 0xC0*n  .. escaped data .. 2-byte LE CRC 0xc1

and from what I can tell, the Stir4200 also resets to sane default
values (9600 baud SIR).

But you may have to do some USB control transfers to set the data
direction. It *looks* like the MCS7780 is simpler and defaults to just
"automatic data direction" (which presumably just means "send if there
is TX data, receive otherwise").

Linus
___
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?

[Linus Torvalds]

On Wed, Apr 18, 2018 at 12:27 PM, Sébastien Dugué
 wrote:
>
>   I looked into this when writing a simulator of my 2G and as far as I
> remember, there's not much of the stack involved when talking to an irda
> DC. All special cases. I may still have the traffic captures laying around

Hmm. Which IRDA chip is it that is in the Uwatec dongle?

Is it perhaps the MosChip MCS7780? You'd know, because then it would
be using USB ID 9710:7780. That seems to be the common case.

You can find datasheets for it by just googling for

MCS7780 Datasheet type:pdf

and from a quick look, the setup looks pretty simple. It has various
configuration bits, but it looks like the control register defaults to
al the normal bits, so you may not even need to touch it.

For example, it seems to default to 9600 baud, all automatic defaults
for SIR. Maybe I missed some bit, but it basically seems to default to
"ready to simply be used".

So you might be able to just set up plain USB bulk transfers to send
and receive the data. *Maybe* you need some setup, but it's not clear
that you do.

So accessing this thing with libusb looks fairly straightforward, if
you already have packet traces and know what the wrapping is (I think
the MCS7780 just wants to add a 2-byte little-endian packet length to
the data, but then whatever the IRDA address encapsulation etc is I
have no idea).

  Linus
___
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?

[Linus Torvalds]

On Wed, Apr 18, 2018 at 3:37 PM, Robert Helling  wrote:
>
> Couldn’t get the dive computer configuration to work either with BLE or 
> classic.

Did this work with the previous release (4.7.8 or whatever)?

I had been hoping that I got the config thing right, but I've never
used it or tested it (I'm not sure I even have any of the dive
computers that are supported), so that was purely a "it builds".

 Linus
___
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?

[Robert Helling]

Hi,

> On 18. Apr 2018, at 23:01, Dirk Hohndel  wrote:
> 
> We now have binaries for Windows, Mac, and Linux (AppImage only) available in 
> order for people to test this.
> 
> https://github.com/Subsurface-divelog/subsurface/releases/tag/continuous-NG 
> 

tested on Mac with OSTC Sport. BLE download worked, BL classic didn’t (but it’s 
always unreliable, so that does not mean much, but there is the error message 
about not being able to open the device). Couldn’t get the dive computer 
configuration to work either with BLE or classic.

Best
Robert


signature.asc
Description: Message signed with OpenPGP
___
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?

[Salvador Cuñat]

Good night,

On Wed, Apr 18, 2018 at 11:01:28PM +0200, Dirk Hohndel wrote:
> 
> We now have binaries for Windows, Mac, and Linux (AppImage only) available in 
> order for people to test this.
>
AppImage works fine for USB download (on debian with an OSTC 2N device).

Best regards.

Salva.
___
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]

We now have binaries for Windows, Mac, and Linux (AppImage only) available in 
order for people to test this.

https://github.com/Subsurface-divelog/subsurface/releases/tag/continuous-NG 


/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 18, 2018, at 10:13 PM, Robert Helling  wrote:
> 
> Dirk,
> 
>> On 18. Apr 2018, at 21:28, Dirk Hohndel > > wrote:
>> 
>> I'm trying to get Travis to do that for us.
>> Which OSs can you test? Travis creates an AppImage, Windows and an unsigned 
>> Mac .app - assuming the builds don't fail :-)
> 
> please excuse my ignorance. It seems that the Mac build on Travis went thru. 
> Where can I find the resulting binary?

https://github.com/Subsurface-divelog/subsurface/releases/download/continuous-NG/Subsurface-4.7.8-67-g9d57d23c72f2.app.zip
 


this is unsigned, so may require some prodding to run on a Mac.

/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?

[Willem Ferguson]

>From phone. You guys in the developed world have resources for all the
latest kit. I my country iRda is commonly used. In addition the CCR
community worldwide often use iRda. It has a significant role to play at
least for the next 10 years. Therefore I strongly argue for the continued
support of iRda. Subsurface is not meant only for the divers with the
latest kit. Kind regards, willem

On Wed, 18 Apr 2018, 21:54 Hartley Horwitz, <hhr...@gmail.com> wrote:

>
>>
>> -- Forwarded message --
>> From: Linus Torvalds <torva...@linux-foundation.org>
>> To: "Sébastien Dugué" <sebastien.dugue.subsurf...@gmail.com>
>> Cc: Subsurface Mailing List <subsurface@subsurface-divelog.org>
>> Bcc:
>> Date: Wed, 18 Apr 2018 12:20:35 -0700
>> Subject: Re: Any brave dive computer download testers out there?
>> On Wed, Apr 18, 2018 at 12:14 PM, Sébastien Dugué
>> <sebastien.dugue.subsurf...@gmail.com> wrote:
>> >
>> >   Right, only bring back those pieces that are of interest. I'll take a
>> look
>> > at this, but I'm not really into bloated communication stacks... I'm
>> merely
>> > a low-level driver coder.
>>
>> ...
>>
>> It never worked very well even back then, but at least it made sense
>> to have IRDA as a networking stack.
>>
>> Today, the _only_ user I'm aware of is old dive computers. It doesn't
>> make sense as a networking stack any more.
>>
>>  Linus
>>
>
> Is this a case where many hours of developer effort will be dumped into
> supporting an old obsolete group of dive computers?  Maybe the current
> version of Subsurface can remain available for users of the IRDA computers
> and new versions will drop this feature?
>
> I'm just not sure how many users have IRDA computers and it seems like
> developer time is better spent on supporting the up-and-coming computers
> which will be BT or BLE.
>
> ...Hartley
>
> ___
> 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: Any brave dive computer download testers out there?

[Robert Helling]

Dirk,

> On 18. Apr 2018, at 21:28, Dirk Hohndel  wrote:
> 
> I'm trying to get Travis to do that for us.
> Which OSs can you test? Travis creates an AppImage, Windows and an unsigned 
> Mac .app - assuming the builds don't fail :-)

please excuse my ignorance. It seems that the Mac build on Travis went thru. 
Where can I find the resulting binary?

Best
Robert


signature.asc
Description: Message signed with OpenPGP
___
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?

[Linus Torvalds]

On Wed, Apr 18, 2018 at 12:27 PM, Sébastien Dugué
 wrote:
>
>   I looked into this when writing a simulator of my 2G and as far as I
> remember, there's not much of the stack involved when talking to an irda
> DC. All special cases. I may still have the traffic captures laying around

Yeah, it should be trivial. There's some small headers for addresses,
and there's a discovery protocol, but it's not complicated.

What made IRDA complex wasn't actually so much the individual
messages, but the documentation and the layering and the abstraction.

It was a classic case of somebody thinking that "hey, we should follow
the OSI model with seven layers of communication" (which was really a
very common mindset in the 80's and 90's) and the end result is not
just a ton of code, but code that is pretty hard to understand and
follow too.

So there's the IRDA physical layer, then the link access layer, then
the link management layer, and then the communication layer.

It's all completely overdesigned BS. Comms people _loved_ doing things
like that.

  Linus
___
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?

[Matt Thompson]

I can test all three platforms.  I have a Macbook and a dual boot PC and a
pile of computers with fresh dives from this weekend! :)

On Wed, Apr 18, 2018 at 2:28 PM, Dirk Hohndel  wrote:

>
> > On Apr 18, 2018, at 9:17 PM, Matt Thompson  wrote:
> >
> > I don't have time to set up a build environment but if I can get a test
> build for any of the supported OS's I can test with a Cobalt, Suunto D4i,
> and Aqualung i750tc.
>
> I'm trying to get Travis to do that for us.
> Which OSs can you test? Travis creates an AppImage, Windows and an
> unsigned Mac .app - assuming the builds don't fail :-)
>
> /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?

[Sébastien Dugué]

On Wed, Apr 18, 2018 at 9:20 PM, Linus Torvalds
 wrote:
> If you're more comfortable just sending packets to the device, doing
> it in user space would be much better.

 Right, I like writing drivers, but this has to be a userspace thing.

>
> It would also make it possible to work on OS X, because there's no
> IRDA stack at all there.

  I wasn't even aware of that, so that'd be a nice added bonus.

>
> So a user space stack would likely be simpler, easier to test, and
> actually technically superior.
>
> The "do IRDA in kernel space" made sense back in the bad old days when
> IRDA was a real protocol used for transferring files and stuff, and
> was supposed to be generic.
>
> It never worked very well even back then, but at least it made sense
> to have IRDA as a networking stack.
>
> Today, the _only_ user I'm aware of is old dive computers. It doesn't
> make sense as a networking stack any more.

  Well, they may be old but they're still selling. And I don't have the money
for those fancy OLED thingies.

  Sébastien.
___
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 18, 2018, at 9:17 PM, Matt Thompson  wrote:
> 
> I don't have time to set up a build environment but if I can get a test build 
> for any of the supported OS's I can test with a Cobalt, Suunto D4i, and 
> Aqualung i750tc.

I'm trying to get Travis to do that for us.
Which OSs can you test? Travis creates an AppImage, Windows and an unsigned Mac 
.app - assuming the builds don't fail :-)

/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?

[Sébastien Dugué]

On Wed, Apr 18, 2018 at 9:17 PM, Linus Torvalds
 wrote:
> On Wed, Apr 18, 2018 at 12:10 PM, Sébastien Dugué
>  wrote:
>>
>>   Looks like a bit daunting for me. However maybe a userspace approach
>> might be doable. Dunno. Will have to think a bit more about it.
>
> Indeed. That has been my long-term thinking about IRDA - most of the
> IRDA dongles are just USB or serial devices, and the protocol
> could/should be done in user space.

  Yes, I totally agree on this.

>
> That's particularly true for something like a divecomputer, which
> really only talks to one single device.
>
> IRDA in _general_ is really damn complicated. And nobody actually does
> the general case.

  I looked into this when writing a simulator of my 2G and as far as I
remember, there's not much of the stack involved when talking to an irda
DC. All special cases. I may still have the traffic captures laying around

>
> So the sane thing to do would be to basically do a special custom IRDA
> thing that just talks directly to the dongle (using libusb, or just
> using a serial port, depending on what the uwatec dongle actually
> does?)

  Yes, that would be my approach because in the end it's just a serial stream
of commands and responses.

  Sébastien.
___
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?

[Linus Torvalds]

On Wed, Apr 18, 2018 at 12:14 PM, Sébastien Dugué
 wrote:
>
>   Right, only bring back those pieces that are of interest. I'll take a look
> at this, but I'm not really into bloated communication stacks... I'm merely
> a low-level driver coder.

If you're more comfortable just sending packets to the device, doing
it in user space would be much better.

It would also make it possible to work on OS X, because there's no
IRDA stack at all there.

So a user space stack would likely be simpler, easier to test, and
actually technically superior.

The "do IRDA in kernel space" made sense back in the bad old days when
IRDA was a real protocol used for transferring files and stuff, and
was supposed to be generic.

It never worked very well even back then, but at least it made sense
to have IRDA as a networking stack.

Today, the _only_ user I'm aware of is old dive computers. It doesn't
make sense as a networking stack any more.

 Linus
___
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?

[Matt Thompson]

I don't have time to set up a build environment but if I can get a test
build for any of the supported OS's I can test with a Cobalt, Suunto D4i,
and Aqualung i750tc.

On Wed, Apr 18, 2018 at 2:04 PM, Dirk Hohndel  wrote:

>
> > On Apr 18, 2018, at 8:56 PM, Linus Torvalds <
> torva...@linux-foundation.org> wrote:
> >
> > On Wed, Apr 18, 2018 at 11:48 AM, Dirk Hohndel  wrote:
> >>
> >> I think that's backwards. If the dive computer and the Subsurface
> version
> >> both support BT, we should prefer that over BLE by default.
> >
> > Well, since it seems to be broken, I'm not sure that's a good idea.
>
> I think if it's broken we need to fix it :-)
>
> (he says, while traveling without a dive computer to test with)
>
> > I also definitely don't want to default to somethihng I can't even test.
>
> That I agree with. You can pick up a BT dive computer at my house - just
> talk to Karen when she's around.
>
> /D
> ___
> 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: Any brave dive computer download testers out there?

[Linus Torvalds]

On Wed, Apr 18, 2018 at 12:10 PM, Sébastien Dugué
 wrote:
>
>   Looks like a bit daunting for me. However maybe a userspace approach
> might be doable. Dunno. Will have to think a bit more about it.

Indeed. That has been my long-term thinking about IRDA - most of the
IRDA dongles are just USB or serial devices, and the protocol
could/should be done in user space.

That's particularly true for something like a divecomputer, which
really only talks to one single device.

IRDA in _general_ is really damn complicated. And nobody actually does
the general case.

So the sane thing to do would be to basically do a special custom IRDA
thing that just talks directly to the dongle (using libusb, or just
using a serial port, depending on what the uwatec dongle actually
does?)

  Linus
___
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?

[Sébastien Dugué]

On Wed, Apr 18, 2018 at 9:07 PM, Linus Torvalds
 wrote:
>> I'd love to bring it back, but it would need a maintainer.. Hint hint.
>
> And by "it", I don't actually mean all of irda. irda is dead, dead,
> dead. But maybe the actual individual driver that somebody is willing
> to maintain, and a small subset of the stack.
>
> The irda code deletion is commit d64c2a76123f ("staging: irda: remove
> the irda network stack and drivers"), and it's a rather impressibe
> number of garbage lines:
>
>  137 files changed, 69241 deletions(-)

  Ouch!

>
> so I'm afraid that a potential maintainer would have to prune it down
> to the minimal that he/she actually uses and can test.

  Right, only bring back those pieces that are of interest. I'll take a look
at this, but I'm not really into bloated communication stacks... I'm merely
a low-level driver coder.

  Sébastien.
___
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?

[Linus Torvalds]

On Wed, Apr 18, 2018 at 12:06 PM, Sébastien Dugué
 wrote:
>
>   OK, it's good to go. The download is in progress (it's painfully
> slow), but that
> means divecomputer_device_open() did succeed!

Thanks. Committed and pushed out to the libdivecomputer-NG branch.

 Linus
___
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?

[Miika Turkia]

On Wed, Apr 18, 2018 at 9:47 PM, Linus Torvalds <
torva...@linux-foundation.org> wrote:

> On Wed, Apr 18, 2018 at 11:31 AM, Miika Turkia 
> wrote:
> >
> > I failed with BT download (OSTC Sport). But my download fails also with
> the
> > release version of Subsurface. Unpairing-pairing works but no download
> with
> > subsurface on Linux desktop for me :(
>
> Is the OSTC sport a rfcomm (legacy BT) device?
>
> I don't have any of those, so I couldn't test it.
>

Yep, good old fashioned fast bluetooth (when it works). I just tested with
some appimages that are laying around on my machine and it works with

Subsurface v4.7.4-3-g6addfe16605b,
built with libdivecomputer v0.6.0-devel-Subsurface-branch
(7de3a549ee588fef4702ee9d894e390aca43950d)

The latest appimage and normal binary are both not working. So the stuff
broke down some time between the 4.7.4 and 4.7.8, but I have currently no
idea when. I might have a change to look into this tomorrow, but after that
it'll be at least a week when I have no change of doing anything related.

miika
___
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?

[Sébastien Dugué]

On Wed, Apr 18, 2018 at 9:00 PM, Linus Torvalds
 wrote:
> On Wed, Apr 18, 2018 at 11:57 AM, Sébastien Dugué
>  wrote:
>>>
>>> Note that IRDA support is going away in the kernel, though - we had
>>> too many bugs and it was impossible to maintain. So you'll have to use
>>> an older kernel.
>>
>>   Arghhh! You mean the whole stack? Darn! will have to keep some old
>> kernel just for loading my dives... :-(
>
> Yeah, all of irda is going away in 4.17.

  OK, I'll revert back to a 2.4 kernel ;-)

>
> Nobody was using it, and nobody was maintaining it.

  I feel so lonely now!!!

>
> I'd love to bring it back, but it would need a maintainer.. Hint hint.

  Looks like a bit daunting for me. However maybe a userspace approach
might be doable. Dunno. Will have to think a bit more about it.

  Sébastien.
___
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?

[Linus Torvalds]

On Wed, Apr 18, 2018 at 12:00 PM, Linus Torvalds
 wrote:
>
> I'd love to bring it back, but it would need a maintainer.. Hint hint.

And by "it", I don't actually mean all of irda. irda is dead, dead,
dead. But maybe the actual individual driver that somebody is willing
to maintain, and a small subset of the stack.

The irda code deletion is commit d64c2a76123f ("staging: irda: remove
the irda network stack and drivers"), and it's a rather impressibe
number of garbage lines:

 137 files changed, 69241 deletions(-)

so I'm afraid that a potential maintainer would have to prune it down
to the minimal that he/she actually uses and can test.

Linus
___
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?

[Sébastien Dugué]

On Wed, Apr 18, 2018 at 8:58 PM, Linus Torvalds
 wrote:
> On Wed, Apr 18, 2018 at 11:48 AM, Linus Torvalds
>  wrote:
>> On Wed, Apr 18, 2018 at 12:55 AM, Sébastien Dugué
>>  wrote:
>>>
>>>   That's really cool! I'll try that out tonight (CET) with my Uwatec DCs 
>>> just to
>>> check IRDA is still functional.
>>
>> I'm pretty sure I broke IRDA. It should be easy to fix.
>
> This attached patch to subsurface may get IRDA working again..
>
> Sébastien, if you can test this, and I'll commit it to my branch. I
> can only test that it builds for me.

  OK, it's good to go. The download is in progress (it's painfully
slow), but that
means divecomputer_device_open() did succeed!

  Thanks Linus.

  Sébastien.
___
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 18, 2018, at 8:56 PM, Linus Torvalds  
> wrote:
> 
> On Wed, Apr 18, 2018 at 11:48 AM, Dirk Hohndel  wrote:
>> 
>> I think that's backwards. If the dive computer and the Subsurface version
>> both support BT, we should prefer that over BLE by default.
> 
> Well, since it seems to be broken, I'm not sure that's a good idea.

I think if it's broken we need to fix it :-)

(he says, while traveling without a dive computer to test with)

> I also definitely don't want to default to somethihng I can't even test.

That I agree with. You can pick up a BT dive computer at my house - just
talk to Karen when she's around.

/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?

[Linus Torvalds]

On Wed, Apr 18, 2018 at 11:57 AM, Sébastien Dugué
 wrote:
>>
>> Note that IRDA support is going away in the kernel, though - we had
>> too many bugs and it was impossible to maintain. So you'll have to use
>> an older kernel.
>
>   Arghhh! You mean the whole stack? Darn! will have to keep some old
> kernel just for loading my dives... :-(

Yeah, all of irda is going away in 4.17.

Nobody was using it, and nobody was maintaining it.

I'd love to bring it back, but it would need a maintainer.. Hint hint.

   Linus
___
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?

[Linus Torvalds]

On Wed, Apr 18, 2018 at 11:48 AM, Linus Torvalds
 wrote:
> On Wed, Apr 18, 2018 at 12:55 AM, Sébastien Dugué
>  wrote:
>>
>>   That's really cool! I'll try that out tonight (CET) with my Uwatec DCs 
>> just to
>> check IRDA is still functional.
>
> I'm pretty sure I broke IRDA. It should be easy to fix.

This attached patch to subsurface may get IRDA working again..

Sébastien, if you can test this, and I'll commit it to my branch. I
can only test that it builds for me.

Linus
 core/libdivecomputer.c | 23 +++
 1 file changed, 23 insertions(+)

diff --git a/core/libdivecomputer.c b/core/libdivecomputer.c
index 247051dad..c547a85b2 100644
--- a/core/libdivecomputer.c
+++ b/core/libdivecomputer.c
@@ -17,6 +17,8 @@
 #include 
 #include 
 #include 
+#include 
+
 #include "libdivecomputer.h"
 #include "core/version.h"
 
@@ -1122,6 +1124,27 @@ dc_status_t divecomputer_device_open(device_data_t *data)
 #endif
 	}
 
+	if (transports & DC_TRANSPORT_IRDA) {
+		unsigned int address = 0;
+
+		dc_iterator_t *iterator = NULL;
+		dc_irda_device_t *device = NULL;
+		dc_irda_iterator_new (, context, descriptor);
+		while (dc_iterator_next (iterator, ) == DC_STATUS_SUCCESS) {
+			address = dc_irda_device_get_address (device);
+			dc_irda_device_free (device);
+			break;
+		}
+		dc_iterator_free (iterator);
+
+		if (!address)
+			address = strtoul(data->devname, NULL, 0);
+
+		rc = dc_irda_open(>iostream, context, address, 1);
+		if (rc == DC_STATUS_SUCCESS)
+			return rc;
+	}
+
 	return DC_STATUS_UNSUPPORTED;
 }
 
___
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?

[Sébastien Dugué]

On Wed, Apr 18, 2018 at 8:48 PM, Linus Torvalds
 wrote:
> On Wed, Apr 18, 2018 at 12:55 AM, Sébastien Dugué
>  wrote:
>>
>>   That's really cool! I'll try that out tonight (CET) with my Uwatec DCs 
>> just to
>> check IRDA is still functional.
>
> I'm pretty sure I broke IRDA. It should be easy to fix.

  OK, will test any changes.

>
> Note that IRDA support is going away in the kernel, though - we had
> too many bugs and it was impossible to maintain. So you'll have to use
> an older kernel.

  Arghhh! You mean the whole stack? Darn! will have to keep some old
kernel just for loading my dives... :-(

  Sébastien.

>
>   Linus
___
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?

[Linus Torvalds]

On Wed, Apr 18, 2018 at 11:48 AM, Dirk Hohndel  wrote:
>
> I think that's backwards. If the dive computer and the Subsurface version
> both support BT, we should prefer that over BLE by default.

Well, since it seems to be broken, I'm not sure that's a good idea.

I also definitely don't want to default to somethihng I can't even test.

   Linus
___
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 18, 2018, at 8:47 PM, Linus Torvalds  
> wrote:
> 
> On Wed, Apr 18, 2018 at 11:31 AM, Miika Turkia  wrote:
>> 
>> I failed with BT download (OSTC Sport). But my download fails also with the
>> release version of Subsurface. Unpairing-pairing works but no download with
>> subsurface on Linux desktop for me :(
> 
> Is the OSTC sport a rfcomm (legacy BT) device?
> 
> I don't have any of those, so I couldn't test it.
> 
> I don't think Dirk tests it either, which may explain the "fails with
> release version too". It may be that all his older ones are broken.

Yes - I have not a single working OSTC left. Which is kind of a shame because I
really like them.

> Ugh. The rfcomm case _looks_ trivial, but since I have never used it,
> I can only go by the "changes since mainline".
> 
> And if mainline was broken too, then the fact that those changes look
> sane obviously isn't meaningful.
> 
> Dirk is traveling, and I don't have an rfcomm dive computer, so it
> would be great if somebody who likes debugging would look at this..

I do have a BT only Shearwater at home. But there are quite a few people
on this list who have other dive computers they could test with.

Should we create test binaries with the branches that you have?

/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?

[Linus Torvalds]

On Wed, Apr 18, 2018 at 12:55 AM, Sébastien Dugué
 wrote:
>
>   That's really cool! I'll try that out tonight (CET) with my Uwatec DCs just 
> to
> check IRDA is still functional.

I'm pretty sure I broke IRDA. It should be easy to fix.

Note that IRDA support is going away in the kernel, though - we had
too many bugs and it was impossible to maintain. So you'll have to use
an older kernel.

  Linus
___
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 18, 2018, at 8:40 PM, Linus Torvalds  
> wrote:
> 
>> - Successful download over BLE
>> - Cannot download over classic BT (it always goes to BLE, even in case
>> "force classic" in the UI is chosen). But unsure this is related to the
>> transport refactoring.
> 
> Yeah, right now the logic is "if we support BLE, and the dive computer
> supports BLE, then we'll use BLE".
> 
> We'll fall back to rfcomm only when libdivecomputer says that the
> divecomputer only does legacy BT.

I think that's backwards. If the dive computer and the Subsurface version
both support BT, we should prefer that over BLE by default.

> I realize that we have that "force BT/BLE" thing, but it sadly doesn't
> actually set the "bluetooth_mode". That's a boolean, and is true for
> both BT and BLE.
> 
> I think it does change the "devname", and I guess I could test that.

Yes, it uses the LE: prefix. And it might still make sense to keep this
but we really should prefer BT over BLE simply for speed reasons

/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?

[Sébastien Dugué]

On Wed, Apr 18, 2018 at 9:55 AM, Sébastien Dugué
 wrote:
> Hello Linus,
>
> On Wed, Apr 18, 2018 at 5:35 AM, Linus Torvalds
>  wrote:
>>  So libdivecomputer has a new custom IO model, which allows us to drop
>> our home-made one.
>>
>> However, that new model is fairly different from our old model, and
>> there were other updates too, so the changes are "flag-day" changes
>> where we switch over both libdivecomputer and subsurface together.
>>
>> I have *TEST* branches for both, in case people want to help test.
>> Note! I only do source code, so this really only works for people who
>> can build their own subsurface binary, but if you are one of those
>> hardy souls, it realy would be good to get more cases tested.
>
>   That's really cool! I'll try that out tonight (CET) with my Uwatec DCs just 
> to
> check IRDA is still functional.

  OK, after much pain trying to build without BLE (old QT5), I managed
to have a functional
subsurface.

  However, when trying to download from my Galileo, even though the
'device or mount point' entry
is greyed out, it insists on trying to open /dev/ttyS4 which makes no
sense for irda...

  Just for the record, I managed to dump the dc with dctool so it
looks like this issue is related
to subsurface proper.

  Cheers,
  Sébastien.
___
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?

[Linus Torvalds]

On Wed, Apr 18, 2018 at 11:31 AM, Miika Turkia  wrote:
>
> I failed with BT download (OSTC Sport). But my download fails also with the
> release version of Subsurface. Unpairing-pairing works but no download with
> subsurface on Linux desktop for me :(

Is the OSTC sport a rfcomm (legacy BT) device?

I don't have any of those, so I couldn't test it.

I don't think Dirk tests it either, which may explain the "fails with
release version too". It may be that all his older ones are broken.

Ugh. The rfcomm case _looks_ trivial, but since I have never used it,
I can only go by the "changes since mainline".

And if mainline was broken too, then the fact that those changes look
sane obviously isn't meaningful.

Dirk is traveling, and I don't have an rfcomm dive computer, so it
would be great if somebody who likes debugging would look at this..

Linus
___
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?

[Linus Torvalds]

On Wed, Apr 18, 2018 at 2:29 AM, Jan Mulder  wrote:
>
> Tested on Arch Linux with an OSTC3 (desktop only, so no mobile-on-desktop,
> or Android).

Thanks.

> - Successful download over BLE
> - Cannot download over classic BT (it always goes to BLE, even in case
> "force classic" in the UI is chosen). But unsure this is related to the
> transport refactoring.

Yeah, right now the logic is "if we support BLE, and the dive computer
supports BLE, then we'll use BLE".

We'll fall back to rfcomm only when libdivecomputer says that the
divecomputer only does legacy BT.

I realize that we have that "force BT/BLE" thing, but it sadly doesn't
actually set the "bluetooth_mode". That's a boolean, and is true for
both BT and BLE.

I think it does change the "devname", and I guess I could test that.

 Linus
___
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?

[Miika Turkia]

On Wed, Apr 18, 2018 at 12:29 PM, Jan Mulder  wrote:

> On 18-04-18 05:35, Linus Torvalds wrote:
>
>>
>> I have *TEST* branches for both, in case people want to help test.
>> Note! I only do source code, so this really only works for people who
>> can build their own subsurface binary, but if you are one of those
>> hardy souls, it realy would be good to get more cases tested.
>>
>> I have verified and downloaded:
>>
>>   - Shearwater Perdix AI over BLE
>>
>>   - Suunto EON Core over USB
>>
>>   - Suunto Vyper Air over the Suunto USB serial line
>>
>> so many of the transports have been tested. But I don't have any
>> rfcomm devices (ie old bluetooth) and I don't have any "direct USB"
>> devices (eg Atomics Aquatics Cobalt).
>>
>>
> Tested on Arch Linux with an OSTC3 (desktop only, so no mobile-on-desktop,
> or Android).
>
> - Successful download over BLE
> - Cannot download over classic BT (it always goes to BLE, even in case
> "force classic" in the UI is chosen). But unsure this is related to the
> transport refactoring.


I failed with BT download (OSTC Sport). But my download fails also with the
release version of Subsurface. Unpairing-pairing works but no download with
subsurface on Linux desktop for me :(

miika
___
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?

[Jan Mulder]

On 18-04-18 05:35, Linus Torvalds wrote:


I have *TEST* branches for both, in case people want to help test.
Note! I only do source code, so this really only works for people who
can build their own subsurface binary, but if you are one of those
hardy souls, it realy would be good to get more cases tested.

I have verified and downloaded:

  - Shearwater Perdix AI over BLE

  - Suunto EON Core over USB

  - Suunto Vyper Air over the Suunto USB serial line

so many of the transports have been tested. But I don't have any
rfcomm devices (ie old bluetooth) and I don't have any "direct USB"
devices (eg Atomics Aquatics Cobalt).



Tested on Arch Linux with an OSTC3 (desktop only, so no 
mobile-on-desktop, or Android).


- Successful download over BLE
- Cannot download over classic BT (it always goes to BLE, even in case 
"force classic" in the UI is chosen). But unsure this is related to the 
transport refactoring.


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