Subsurface mobile with Suunto Vyper (old): no download possible?

[arnaud...@googlemail.com]

Hi there, 

As my girlfriend is starting again to dive, she would like to use Subsurface mobile to log her dives from her Suunto Vyper, using usb smart interface.

I know I could do it years ago (4-5 years ago), but now, no chances anymore…

I tried with her Samsung S7, her Iphone, my Ipad and my Huawei mate 20 lite.

Everytime I have the same behaviour:one can see on the smart interface that a communication is initiated (blinking led), then nothing anymore, and subsurface seems to be in an infinite loop…

Did I miss something?

Thanks,

Arnaud

[arnaud...@googlemail.com]

Nb: 2 additional remarks:

*when I say I tried on Iphone/Ipad, it means I figured out that only bluetooth computers are supported

*I made a test dowload using divemate free version, and it worked perfectly.

[arnaud...@googlemail.com]

Update:as a matter of fact, even by trying to force all the dives to be downloaded, after a while the computer cuts the connection (about 10 minutes), and then, it seems the 1st dive could downloaded, none of the others….

Any ideas?

[Jason Bramwell]

It sounds like this did work for you eventually but only 1 divers was downloaded, is that right?

I’m a little surprised it worked at all on mobile, I was expecting you to have to use the fully featured desktop version of Subsurface.

With Suunto computers even though their history shows a good number of dives they actually only store profile information for a smaller number like 30-50 and any dives prior to that are overwritten.

Jason

Sent from my iPhone

On 17 Mar 2024, at 22:59, 'arnaud...@googlemail.com' via Subsurface Divelog <subsurfac...@googlegroups.com> wrote:

Update:as a matter of fact, even by trying to force all the dives to be downloaded, after a while the computer cuts the connection (about 10 minutes), and then, it seems the 1st dive could downloaded, none of the others….

--
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-dive...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/subsurface-divelog/2c47b20d-adcf-43dc-8196-32ae9e109edbn%40googlegroups.com.

[Dirk Hohndel]

On an Android device, with a Suunto cable, I would expect you to be able to connect to the Android device and download the last "couple of dozen" or so dives.

If you can download only one that indicates that there's an issue with the serial communication.

Can you try again and after it fails create a support request from within the app (right after it fails, don't quit the app). This way I'll see the log files which might tell me what went wrong with the serial communication.

But yeah, to be honest, support for dive computers using serial connections on Android is not tested much...

/D

[arnaud...@googlemail.com]

Hi Dirk,

Thanks for the answer.

Well, I cannot really send anything after it fails, because it does not formally.

What (it seems) is happening is the following:

The computer (in Pc-track mode, for downloading) is connected tu subsurface via the usb interface.

In Subsurface, a download action is initiated.

A short communication takes place, but is then interrupted. The computer does not send anymore (and I guess is not asked anymore to send) and Subsurface still scans if there is anything.

After 10 minutes of "inactivity", the computer goes in standby, but subsurface is still scanning, in a kind of infinite loop.

After a certain time (20 minutes), I simply disconnect the smartphone and the Usb interface. Then Subsurface tells me that one dive is there… but no failure.

I will try with a newer smartphone when I have the opportunity, but I am afraid that your note on serial computer tells it all.

It does indeed work with the desktop version.

I just wanted to check if I had not made a mistake somewhere, but it does not seem to be the case.

Thanks anyway.

[Dirk Hohndel]

Yes, after Subsurface tells you that it has one new dive - that's when you should be able to send a support request that will include the logs.

But it sounds like this may really just be a timeout, i.e. a communication issue. And those are really hard to fix given the way that Android does the serial communication.

/D

[arnaud...@googlemail.com]

OK, done.

Thanks for the support.

A.

[Dirk Hohndel]

This is odd. We fail when trying to set RTS. That's a bug that I haven't seen before. Jef, does this ring any bells?

Subsurface: vv5.0.9-35-gb4d82482c5a4, built with libdivecomputer v0.8.0-devel-Subsurface-NG (a17e466bd1d2e675666e20862182d618cf6d7190)

[0.000001] INFO: Open: transport=1

[0.001055] INFO: Configure: baudrate=2400, databits=8, parity=1, stopbits=0, flowcontrol=0

[0.002514] INFO: Timeout: value=1000

[0.002731] INFO: DTR: value=1

[0.002963] INFO: Sleep: value=100

[0.104157] INFO: Purge: direction=3

[0.106366] INFO: Sleep: value=500

[0.606545] INFO: RTS: value=1

[0.609668] INFO: Write: size=5, data=0500161407

[0.609683] INFO: Sleep: value=200

[0.809832] INFO: Purge: direction=1

[0.810689] INFO: RTS: value=0

[1.258302] INFO: Read: size=25, data=050016140001A81C0000000055884DB201D80A21000A41634A

Event: model=10 (0x0000000a), firmware=33 (0x00000021), serial=106599 (0x0001a067)

[1.262999] INFO: Sleep: value=500

[1.763322] INFO: RTS: value=1

[1.764555] INFO: Write: size=3, data=08A5AD

[1.764569] INFO: Sleep: value=200

[1.964719] INFO: Purge: direction=1

[1.965764] INFO: RTS: value=0

[2.300999] INFO: Read: size=2, data=0820

[2.444924] INFO: Read: size=33, data=00001A1A807D7A00000000000000000000000000000000000000000000000000AF

[2.460592] INFO: Read: size=2, data=0820

[2.620009] INFO: Read: size=33, data=000000000000000000000000000000000000000000000000000000000000000028

[2.636144] INFO: Read: size=2, data=0819

[2.747701] INFO: Read: size=26, data=000000000000000000000B2A09130C1713001500001401000022

[358.364738] INFO: Read: size=0, data=

[358.367359] INFO: Sleep: value=500

[358.867542] INFO: RTS: value=1

[358.868729] ERROR: Failed to set RTS. [in /android/subsurface/libdivecomputer/src/suunto_vyper.c:155 (suunto_vyper_send)]

[358.868743] ERROR: Failed to send the command. [in /android/subsurface/libdivecomputer/src/suunto_vyper.c:326 (suunto_vyper_read_dive)]

-- 
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-dive...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/subsurface-divelog/fa35da0d-d326-4fa7-9ed4-a7d4c0888502n%40googlegroups.com.

[Linus Torvalds]

On Wed, 20 Mar 2024 at 10:19, 'Dirk Hohndel' via Subsurface Divelog
<subsurfac...@googlegroups.com> wrote:
>
> This is odd. We fail when trying to set RTS. That's a bug that I haven't seen before. Jef, does this ring any bells?

The RTS thing is a red herring. The old Suunto serial setup is a
two-wire half-duplex thing and physically doesn't even _have_ RTS/CTS
pins.

So I think the error comes from the device having been unplugged.

The real issue is this:

[2.747701] INFO: Read: size=26,
data=000000000000000000000B2A09130C1713001500001401000022
[358.364738] INFO: Read: size=0, data=

IOW we have that almost six *minute* delay in between the 26-byte read
and the "no more data" read.

I think the "Failed to set RTS" is more likely to be due to Arnaud
having unplugged the cable or similar.

So while the RTS error shouldn't matter, I doubt any future IO would
have worked anyway.

No, I think the real error happened much much earlier. That sequence
starts out with us sending the "read first dive" command:

[1.764555] INFO: Write: size=3, data=08A5AD

where 08 is just "first dive" (09 means "next dive"), A5 is the "read
dive" command, and "AD" is just the checksum (xor of 08 and A5).

And then we get back

INFO: RTS: value=0
INFO: Read: size=2, data=0820
INFO: Read: size=33,
data=00001A1A807D7A00000000000000000000000000000000000000000000000000AF
INFO: Read: size=2, data=0820
INFO: Read: size=33,
data=000000000000000000000000000000000000000000000000000000000000000028
INFO: Read: size=2, data=0819
INFO: Read: size=26,
data=000000000000000000000B2A09130C1713001500001401000022

where we read a two-byte header that is "08" (for reply to our 08),
and the second is the length of the reply (so hex 20 is 32 bytes).
Then that 33-byte data that comes next is the reply and the XOR of the
data.

So that last packet is 08 19, so it says "25 bytes of data", and yes,
we get 26 bytes (because the XOR checksum).

And then we don't do anything at all. We've gotten all the data, but
nothing happens.

We actually have that code, but it's #if'ed out:

// If a package is smaller than $SZ_PACKET bytes,
// we assume it's the last packet and the transmission can be
// finished early. However, this approach does not work if the
// last packet is exactly $SZ_PACKET bytes long!
#if 0
if (len != SZ_PACKET)
break;
#endif

but that code has been if'ed out for a long long long time, since 2008
(commit ce2f9359cba5: "Removed the interface detection code since it
is no longer required").

So now the code actually replies on the timeout, but the timeout
should have been one *second*, not 356 seconds. So we get that timeout
much *MUCH* too late:

INFO: Read: size=0, data=

and at that point we go "ok, the first dive is done". But it took six
minutes to make that decision, and I'm pretty sure the Vyper has long
since gone to sleep.

I suspect that removing the #if 0 would make it work (until we hit a
dive that is an exact multiple of 32 bytes long), but the real issue
is that the timeout never happened.

Linus

[Linus Torvalds]

On Wed, 20 Mar 2024 at 11:43, Linus Torvalds
<torv...@linuxfoundation.org> wrote:
>
> So now the code actually replies on the timeout, but the timeout
> should have been one *second*, not 356 seconds.

So I'm looking at that code, and I can't see how it happens.

Now, I do note that our timeout handling is (a) overly complicated and
(b) somewhat broken.

The "overly complicated" part is because it tries very hard to use a
some random platform-specific high-resolution timer, but then it ends
up using that timer for "select()" anyway. It doesn't look exactly
_wrong_, but it doesn't look exactly right either.

The "somewhat broken" is because the code tries very hard to take the
timeout into account from the start of the read(). But this is all
called from the dc_iostream_read() wrapper, and that wrapper will just
loop anyway until it has gotten the requested bytes, so that's all
pretty bogus.

Now, the "somewhat" in the above is there because at least the Vyper
backend has the "return partial results" logic set, so for the case of
the vyper backend, the looping in dc_iostream_read() never happens and
this should all work.

Of course, the Vyper still depends on the low-level read continuing
until the timeout. Because the vyper code isn't _really_ willing to
deal with partial packets.

But all this slightly broken code should still work enough for the Vyper code.

But the keyword here is "should". It clearly doesn't. The logs unambiguously say

[2.747701] INFO: Read: size=26, data=00...

[358.364738] INFO: Read: size=0, data=

so the one-second timeout clearly didn't work (libdivecomputer
internally does it in ms, which is why we had that earlier

[0.002514] INFO: Timeout: value=1000

in the logs).

I don't see *how* it could really fail that way, unless the underlying
"read()" function is just broken.

Arnaud, just exactly how is the Vyper connected to your Android phone?
Is it the official Suunto cable and some USB C -> A dongle, or what?

Jef - the timeout code really is broken. I suspect the serial code
would be *much* better off just using the VMIN / VTIME fields.

Or just simplify it to always wait for "timeout" in between successful
reads, without the broken "update timeout depending on how long we've
waited".

Linus

[Linus Torvalds]

On Wed, 20 Mar 2024 at 15:19, Linus Torvalds
<torv...@linuxfoundation.org> wrote:
>
> Or just simplify it to always wait for "timeout" in between successful
> reads, without the broken "update timeout depending on how long we've
> waited".

This will still busy-loop in dc_iostream_read() if the timeout is set
to zero, but hey, it already does that.

And the code is a *lot* simpler, because it just re-uses the existing
dc_serial_poll() for the "wait between reads" case.

This is untested, but looks much saner to me. Not that I understand
why the timeout didn't work for Arnaud, but the old timeout code
really *was* overly complex.

This is at least simpler. Possibly not any better. I no longer have
any working serial devices to test with.

Linus

[Jef Driesen]

On 20/03/2024 18:19, Dirk Hohndel wrote:
> [0.000001] INFO: Open: transport=1

This indicates the use of a custom I/O. I guess it's one of these two:

https://github.com/subsurface/subsurface/blob/master/core/serial_usb_android.cpp
https://github.com/subsurface/subsurface/blob/master/core/serial_ftdi.c

Thus, the timeout problem is likely also located there and not in the
libdivecomputer serial code, because that code isn't used at all here.

I don't have time to investigate this code further right now. It's time to get
some sleep here. But this info may already help to point the investigation into
the right direction.

Jef

[Linus Torvalds]

On Wed, 20 Mar 2024 at 16:09, Jef Driesen <j...@libdivecomputer.org> wrote:
>
> On 20/03/2024 18:19, Dirk Hohndel wrote:
> > [0.000001] INFO: Open: transport=1
>
> This indicates the use of a custom I/O.

Ahh. Good catch. No wonder I couldn't find anything suspicious in the
regular POSIX serial part. I was just testing this on my desktop - I
have the suunto serial cable, just no longer any working dive
computers for it.

And on the desktop it uses the standard serial_posix.c driver.

But apparently not on Android.

Linus

[Linus Torvalds]

On Wed, 20 Mar 2024 at 16:09, Jef Driesen <j...@libdivecomputer.org> wrote:
>

> https://github.com/subsurface/subsurface/blob/master/core/serial_usb_android.cpp
> https://github.com/subsurface/subsurface/blob/master/core/serial_ftdi.c

The ftdi one comes close, but never sets ftdi->usb_read_timeout, so as
far as I can tell it actually uses mostly blocking reads.

That said, the libftdi default timeout seems to be 5s:

ftdi->usb_read_timeout = 5000;

(libusb also does timeouts in milliseconds), so it *should* work out ok.

The serial_usb_android.cpp thing is some jni object, and I have no
idea how the timeouts work there. It does have

... ->callMethod<jint>("set_timeout", "(I)I", timeout));

but I have no idea whether that actually affects the

... ->callMethod<jint>("read", "([B)I", array);

method.

Linus

[Chris Kuethe]

On Sun, Mar 17, 2024, 20:11 'Dirk Hohndel' via Subsurface Divelog <subsurfac...@googlegroups.com> wrote:

... 

But yeah, to be honest, support for dive computers using serial connections on Android is not tested much...

You'd have heard a lot more whining from me over the years if subsurface on Android didn't work so well with my Cressi computers connected to Google Pixel (P6, P8) and Samsung Galaxy (S8, S9) series phones.

Picking the right serial driver (FTDI) and making sure the computer is properly seated in the dock and shielded from light interference has been important to me. Maybe there's a lot of luck involved, but android/ftdi/subsurface aren't a totally unusable configuration.

[Linus Torvalds]

On Wed, 20 Mar 2024 at 16:36, Linus Torvalds
<torv...@linuxfoundation.org> wrote:
>
> The serial_usb_android.cpp thing is some jni object, and I have no
> idea how the timeouts work there. It does have
>
> ... ->callMethod<jint>("set_timeout", "(I)I", timeout));
>
> but I have no idea whether that actually affects the
>
> ... ->callMethod<jint>("read", "([B)I", array);
>
> method.

.. ahh. Our java side does have this comment:

// This behaves differently on different chipsets. CP210x blocks,
FTDI seems to return instantly.

at the actual "usbSerialPort.read(readFromHwData, 0)" call.

I'm not sure why that code does the "read in 64-byte blocks", or why
it seems to use a zero timeout. The write side just does

usbSerialPort.write(data, timeout);

inside a try-catch block, and I'm not sure why the read side doesn't
just do the same thing.

There are some comments about problems with read-timeouts (see commit
b15b9c6cd "usb-serial-for-android: Implement timeout-handling"), so
...

Linus

[Gmail im Auftrag von Martin Gröger]

he guys

I own a "old" vyper - and therefore I know this _could_ also be a vyper issue. the two contacts of the vyper just need a little dirt/salt or corrosion to cause such behavior. and the cable can loose contact if moved while downloading the dives.

maybe you should start here...

keep on howling

grey

--

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-dive...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/subsurface-divelog/5a250c23-46c5-4fe4-ad71-74e77204b6d5n%40googlegroups.com.

[arnaud...@googlemail.com]

Hy everyone,

OK, I will try to answer, but this is getting faaaaaar above my head right now.

Yet many, many, many thanks for the help :-) (side note: Although it would be nice to have, I can live with the answer:"does not work on Android with this configuration"):

*the "six minutes": indeed, this corresponds roughly to the time it took to the Vyper to go to sleep before I unplugged it.

*The USB interface: Unless I am wrong, this is a third party interface, not an official Suunto brand. It is connected then with an USB-C OTG cable. The interface cable looks a lot like this one