No synch'ing with Suunto Vyper Air and Vyper Novo on MacOS X 10.13.5

[Eelco Essenberg]

I have the same issue on 2 different Mac's:

1. Macbook Pro 15" early-2011, OSX 10.13.5

2. Macbook Pro 15" retina mid-2015, OSX 10.13.5

Since Subsurface 4.7.8, neither of these sync with my Vyper's anymore - not the Vyper Air, not the Vyper Novo (and yes, I select the appropriate model in the Import dialog when attempting to sync). 

My last known working import was on the MBP15 early-2011, using Subsurface 4.7.8, both for the Vyper Air and for the Novo.

I have tried both the native Apple FTDI drivers, as well as the VPC v2.4.2 driver from FTDI's site.

When I plug the cables into any USB ports Apple's "System Report" shows that the cable is recognized by listing something like this:

Suunto Sports Instrument:

  Product ID: 0xf680

  Vendor ID: 0x0403  (Future Technology Devices International Limited)

  Version: 6.00

  Serial Number: ST03R8OQ

  Speed: Up to 12 Mb/sec

  Manufacturer: Suunto

  Location ID: 0x14200000 / 14

  Current Available (mA): 500

  Current Required (mA): 300

  Extra Operating Current (mA): 0

(This is the Novo serial cable, on the MBP15-retina, with the native Apple driver)

However, there is no corresponding entry in /dev:

$ ls -l /dev/tty.*

crw-rw-rw-  1 root  wheel   21,   0 Jul  1 14:26 /dev/tty.Bluetooth-Incoming-Port

$

(The FTDI driver seems a bit better at this, )

On the MBP15-2011, with the FTDI driver, Subsurface "sees" the USB port, but on the first attempt to import I get: "Error: Unable to open /dev/tty.usbserial-ST03LXOO" after a few seconds.

The DC display says "Data transfer"

(Vyper Air, "old" Suunto serial cable)

Log file:

--- begin --

Subsurface: v4.8.0, built with libdivecomputer v0.7.0-devel-Subsurface-NG (e97a47cca55973199715df0f818b4955e60d3a31)
INFO: Open: name=/dev/tty.usbserial-ST03LXOO
INFO: Configure: baudrate=9600, databits=8, parity=0, stopbits=0, flowcontrol=0
INFO: Timeout: value=3000
INFO: DTR: value=1
INFO: Sleep: value=100
INFO: Purge: direction=3
INFO: Sleep: value=600
INFO: RTS: value=1
INFO: Write: size=4, data=0F00000F
INFO: RTS: value=0
INFO: Read: size=1, data=FE
ERROR: Failed to receive the answer. [in ../../src/suunto_vyper2.c:244 (suunto_vyper2_device_packet)]
INFO: Sleep: value=600
INFO: RTS: value=1
INFO: Write: size=4, data=0F00000F
INFO: RTS: value=0
INFO: Read: size=0, data=
ERROR: Failed to receive the answer. [in ../../src/suunto_vyper2.c:244 (suunto_vyper2_device_packet)]
INFO: Sleep: value=600
INFO: RTS: value=1
INFO: Write: size=4, data=0F00000F
INFO: RTS: value=0
INFO: Read: size=1, data=FE
ERROR: Failed to receive the answer. [in ../../src/suunto_vyper2.c:244 (suunto_vyper2_device_packet)]
ERROR: Failed to read the version info. [in ../../src/suunto_vyper2.c:140 (suunto_vyper2_device_open)]

--- end ---

On the 2nd attempt, w/o disconnecting the DC and/or the cable, I get "Error: Unable to open /dev/tty.usbserial-ST03LXOO" immediately, plus a red error bar at the bottom of Subsurface's main window, with "Unsupported operation".

No logfile is created.

A bit lost for what else to try, any suggestions welcome...

Thanks!

[Rick Balsano]

I had a similar issue with dive downloads from my Mares Quad Air using my Macbook. Jef fixed the issue in libdivecomputer.

--
You received this message because you are subscribed to the Google Groups "Subsurface Divelog" group.
To unsubscribe from this group and stop receiving emails from it, send an email to subsurface-divelog+unsub...@googlegroups.com.
To post to this group, send email to subsurface-divelog@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/subsurface-divelog/bd2330a4-1d95-458e-943c-22ef934a7e32%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Jef Driesen]

On 02-07-18 21:59, Eelco Essenberg wrote:
> Since Subsurface 4.7.8, neither of these sync with my Vyper's anymore - not the
> Vyper Air, not the Vyper Novo (and yes, I select the appropriate model in the
> Import dialog when attempting to sync).

And which model do you have? Because despite the similar name, the Vyper, Vyper
Air and Vyper Novo are three completely devices with a different communication
protocols. So they are not compatible and selecting the correct model is important.

> However, there is no corresponding entry in /dev:
>
> $ ls -l /dev/tty.*
>
> crw-rw-rw-  1 root  wheel   21,   0 Jul  1 14:26 /dev/tty.Bluetooth-Incoming-Port

That means the driver isn't installed, and thus you won't be able to communicate
with the dive computer. Unless you are trying to use subsurface's ftdi userspace
driver.

> (The FTDI driver seems a bit better at this, )
>
> On the MBP15-2011, with the FTDI driver, Subsurface "sees" the USB port, but on
> the first attempt to import I get: "Error: Unable to open
> /dev/tty.usbserial-ST03LXOO" after a few seconds.
> The DC display says "Data transfer"
> (Vyper Air, "old" Suunto serial cable)

This is already better. The driver is installed and creates the device node.

Okay, this is the vyper2 backend for the Vyper Air, and you're getting no data
at all, or an unexpected 0xFE byte.

One possible explanation is a low battery. If the battery is getting low, then
there might not be enough power for the PC interface, even if there is still
enough left for diving.

Another possibility is a long standing bug, which I've never been able to find
the root cause. But if that's indeed the problem, then retrying immediately
should work. Except that you get this:

> On the 2nd attempt, w/o disconnecting the DC and/or the cable, I get "Error:
> Unable to open /dev/tty.usbserial-ST03LXOO" immediately, plus a red error bar at
> the bottom of Subsurface's main window, with "Unsupported operation".
> No logfile is created.
>
> A bit lost for what else to try, any suggestions welcome...

Hmm, you shouldn't get unsupported operation.

Can you try the libdivecomputer command line application? Download here:

http://www.libdivecomputer.org/builds/stable/macosx/dctool

And execute as follows:

chmod +x dctool
./dctool -v -l vyper2.log -f vyper2 -m 0x13 dump -o vyper2.bin
/dev/tty.usbserial-ST03LXOO

(that second command is all on one line)

Jef

[Jef Driesen]

On 02-07-18 22:23, Rick Balsano wrote:
> I had a similar issue with dive downloads from my Mares Quad Air using my
> Macbook. Jef fixed the issue in libdivecomputer

> <https://github.com/libdivecomputer/libdivecomputer/commit/29856165329597e47d0a45d03c76974a8543139b>.

The build that Eelco used:

> Subsurface: v4.8.0, built with libdivecomputer v0.7.0-devel-Subsurface-NG
(e97a47cca55973199715df0f818b4955e60d3a31)

does not include the fix for the Mac OS X timer bug. But I don't think that's
the problem here because he's not getting any response at all. With the timer
bug he should get at least the first few bytes. And the 0xFE byte he does get
sometimes is not a valid start of a packet. So I think there is something else
wrong here.

Jef

[Eelco Essenberg]

Hi Jeff,

On Monday, 2 July 2018 23:54:23 UTC+2, Jef Driesen wrote:

On 02-07-18 21:59, Eelco Essenberg wrote:
> Since Subsurface 4.7.8, neither of these sync with my Vyper's anymore - not the
> Vyper Air, not the Vyper Novo (and yes, I select the appropriate model in the
> Import dialog when attempting to sync).

And which model do you have? Because despite the similar name, the Vyper, Vyper
Air and Vyper Novo are three completely devices with a different communication
protocols. So they are not compatible and selecting the correct model is important.

I have both, and neither works.

When attempting to sync the Vyper Air, I select that model in the Import dialog.

When attempting to sync the Novo, I select that in the dialog.

 

> However, there is no corresponding entry in /dev:
>
> $ ls -l /dev/tty.*
>
> crw-rw-rw-  1 root  wheel   21,   0 Jul  1 14:26 /dev/tty.Bluetooth-Incoming-Port

That means the driver isn't installed, and thus you won't be able to communicate
with the dive computer. Unless you are trying to use subsurface's ftdi userspace
driver.

That's on the MBP15-retina mid-2015, with only the Apple native driver installed. When I install the FTDI driver (VCP v2.4.2), I get the same results as on the other Mac.

 

> On the MBP15-2011, with the FTDI driver, Subsurface "sees" the USB port, but on
> the first attempt to import I get: "Error: Unable to open
> /dev/tty.usbserial-ST03LXOO" after a few seconds.
> The DC display says "Data transfer"
> (Vyper Air, "old" Suunto serial cable)

This is already better. The driver is installed and creates the device node.

> ERROR: Failed to receive the answer. [in ../../src/suunto_vyper2.c:244 (suunto_vyper2_device_packet)]
> ERROR: Failed to read the version info. [in ../../src/suunto_vyper2.c:140 (suunto_vyper2_device_open)]

Okay, this is the vyper2 backend for the Vyper Air, and you're getting no data
at all, or an unexpected 0xFE byte.

Yup, that's with the Air. 

One possible explanation is a low battery. If the battery is getting low, then
there might not be enough power for the PC interface, even if there is still
enough left for diving.

This Vyper Air has had a fresh battery installed recently, and 1 or 2 dives since.

 

Another possibility is a long standing bug, which I've never been able to find
the root cause. But if that's indeed the problem, then retrying immediately
should work. Except that you get this:

> On the 2nd attempt, w/o disconnecting the DC and/or the cable, I get "Error:
> Unable to open /dev/tty.usbserial-ST03LXOO" immediately, plus a red error bar at
> the bottom of Subsurface's main window, with "Unsupported operation".
> No logfile is created.

Hmm, you shouldn't get unsupported operation.

Can you try the libdivecomputer command line application? Download here:

http://www.libdivecomputer.org/builds/stable/macosx/dctool

And execute as follows:

chmod +x dctool
./dctool -v -l vyper2.log -f vyper2 -m 0x13 dump -o vyper2.bin
/dev/tty.usbserial-ST03LXOO

(that second command is all on one line)

So that seems to work - it's downloading dives now, slowly. Logfile and binfile attached.

Regards,

Eelco

[Eelco Essenberg]

This is what I get with the Vyper Novo, on the same MBP15-2011:

$ls -l /dev/tty.*

crw-rw-rw-  1 root  wheel   21,   0 Jul  3 21:08 /dev/tty.Bluetooth-Incoming-Port

crw-rw-rw-  1 root  wheel   21,   4 Jul  3 21:45 /dev/tty.usbserial-ST03R8OQ

$

When trying to import into Subsurface, I get "Dive data import error" - logfile attached.

Running dctool:

 ./dctool -v -l vypernovo.log -f d9 -m 0x13 dump -o vypernovo.bin /dev/tty.usbserial-ST03R8OQ

Works, log- and binfile attached.

[Eelco Essenberg]

Sorry, you got the dctool log twice.

The import log from ssrf is attached now.

Eelco

[Linus Torvalds]

On Tue, Jul 3, 2018 at 12:55 PM Eelco Essenberg <ee...@essenberg.net> wrote:
>
> Sorry, you got the dctool log twice.
>
> The import log from ssrf is attached now.

This really still smells like the timeout problem.

This sequence:

INFO: RTS: value=0
INFO: Write: size=7, data=0500030024082A
INFO: Read: size=7, data=0500030024082A
INFO: RTS: value=1

Is the "send read command", and it expects 8 bytes back, I think.

But then it gets just one byte:

INFO: Read: size=1, data=05
ERROR: Failed to receive the answer. [in ../../src/suunto_d9.c:253
(suunto_d9_device_packet)]

and tries again:

INFO: RTS: value=0
INFO: Write: size=7, data=0500030024082A

but instead of the command echo, it gets the missing bytes from the
_previous_ command:

INFO: Read: size=7, data=000B002408464D

and is unhappy:

ERROR: Unexpected echo. [in ../../src/suunto_d9.c:239
(suunto_d9_device_packet)]

So I do think it's a problem in the read function again. It really
looks like it timed out the read early again.

And indeed, that log-file says it is using an older libdivecomputer
from before the MacOS fix:

Subsurface: v4.8.0, built with libdivecomputer
v0.7.0-devel-Subsurface-NG (e97a47cca55973199715df0f818b4955e60d3a31)

that e97a47cca55973199715df0f818b4955e60d3a31 commit predates commit
2985616 ("Fix the Mac OS X timer implementation").

So _this_ log at least indicates that the problem is that libdivecomputer bug.

It should be fixed in the current daily downloads.

Linus

[Eelco Essenberg]

Just tried 4.8.0-34-g735f7cd25a2 from the continuos builds, and that works with the Vyper Novo.

I'll try that with the Vyper Air later.

[Eelco Essenberg]

OK, just tried with the Vyper Air and the 4.8.0-34-g735f7cd25a2 build (same Macbook, no other changes).

That also seems to work. Just downloaded all dives from the Air.

Logfile attached.