Error importing from Perdix AI

[Shallow Reef]

Using Subsurface 4.9.3, on Windows 10

Issue: download dives from Shearwater Perdix AI

I am able to download dives using Shearwater Desktop application.

On Subsurface I go to Import > Download from dive computer, select Shearwater as vendor, Perdix AI as Dive computer, check "Choose Bluetooth download mode", open Remote Bluetooth device selection, see my dive computer listed under "Discovered devices".

On my dive computer I start the countdown at Bluetooth, see the "wait PC" message.

On Subsurface I click on "download" and get an error message "dive data import error".

Any suggestions?

Thanks!

[Alvaro Aguilera]

My Perdix (non AI) is also driving me crazy.

Great dive computer, but the Bluetooth stack is a nightmare.

For me, the Android version of Subsurface is what works best, but I
still have to pair/unpair, close and restart, turn off and on several
times until it works. It's like conjuring a demon, when the stars are
right, the dives are downloaded.

Do you guys receive some support from Shearwater or are reverse
engineering everything? It would be great if Shearwater would abandon
the development of their software and give you the money instead.

Regards
AA

> --
> 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
> <mailto:subsurface-dive...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/subsurface-divelog/4249759d-f3a5-44c3-95fc-94ae496a881e%40googlegroups.com
> <https://groups.google.com/d/msgid/subsurface-divelog/4249759d-f3a5-44c3-95fc-94ae496a881e%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Vincent Tassy]

Yep, same pattern here ...

Never quite sure what exact sequence of actions make the connection eventually work ...

It is a pain really :(

Before, unpairing/re-pairing and downloading did the trick but since recently, it's completly random to get the setup right ... Eventually it will work after 15' of messing around, truning things including the DC on and off ...

Weird ...

At least I'm not the only one suffering from this :D

Vince.

[Dirk Hohndel]

On Android this seems to work reliably for me on two different phones:

For the first connection in a while (i.e., if the Shearwater completely turned off recently), or for a new device:

Before starting Subsurface, make sure the Shearwater is in BT mode already, use nRFconnect to both "connect" AND "bond".

Now start Subsurface-mobile, pick your DC, start the download. You'll get a pairing dialog (actually, on most of my Android devices I get TWO pairing prompts).

Most of the time this already works

Occasionally this fails.

Quit Subsurface-mobile (keep hitting back button)

Check in nRFconnect that you are still connected/bonded

Start Subsurface-mobile again, same process.

I have no recollection in recent history of several dozen attempts that this didn't work by the second time.

If you then come back a few hours / a day later (dive trip), you don't need to go through this. The phone remembers things apparently and I can simply tap on the remembered DC button and start the download that way.

As always, we support more than 5000 different Android devices and while this seems to work on the handful I have access to (and has been frequently tested this week on a Pixel 3XL and a OnePlus 6), there's always the chance that there are others where this still fails.

I'd love to hear about those cases!

/D

[Vincent Tassy]

Hey Dirk,

I think we were mainly concerned with the Desktop version.

On my side, the Android version works quite well. It is the Linux desktop version I'm using (on Fedora) that's cahotic these days with log downloads.

I will however try to shutdown other BT devices around as you suggest next time I try to download from the Perdix.

This being said, enjoy your dive trip for now ! Software can wait :)

Vince.

[Dirk Hohndel]

Overall our experience has been that mobile devices are much more reliable and their driver stacks much better tested than desktops / laptops.
Windows is the worst, Linux is typically the best, Mac in between. Specifically to Linux/Fedora, our BLE code was mostly written by Linus and he uses it on Fedora all the time. So that SHOULD be well supported.
If you run into trouble there, please post the steps that you took, I'm hopeful that he'll have suggestions how to make this work reliably for you as well.

And for the dive trip, today is off-gassing day, we fly out tonight. So lots of time for software.

/D

[Linus Torvalds]

On Sun, Oct 27, 2019 at 4:20 AM Vincent Tassy <tim...@gmail.com> wrote:
>
> On my side, the Android version works quite well. It is the Linux desktop version I'm using (on Fedora) that's cahotic these days with log downloads.

So I use almost exclusively the Linux desktop version, and while I
have upgraded from the Perdix AI to the Teric, they should be fairly
similar.

What I have learnt (and by "learnt" I mean "this _seems_ to be true") is

(a) doing a "bonding" pair seems to help some people, but it
shouldn't be necessary, and it causes its own set of issues.

In particular, what happens is that "bonding" creates a long-term key
for the pairing, and from all that I can figure out, the Shearwater
will forget that key (and thus stop responding to a bonded connection
attempt) if it is turned off.

Now, "turned off" is the key here. If you have been diving recently,
and the shearwater is still tracking any deco at all (which will take
days), then it won't actually shut off unless you take the batteries
out for a while.

But if you haven't been diving, and are just using your shearwater for
testing (or you do the download after you get home, several days after
the last dive), then any "screen off" will be a power off event.

End result: you don't _have_ to always re-pair with the Shearwater
dive computers, but re-pairing should fix the "desktop thinks it's
bonded, but the shearwater isn't, and they won't communicate until you
unpair and re-pair".

(b) The shearwater bluetooth stack isn't a real bluetooth stack, and
it resets some state at every "start bluetooth", and it won't accept
more than one pairing or connection attempt per such a session.

So if you have problems downloading, you need to *exit* the shearwater
bluetooth mode, and start again, because otherwise if the shearwater
thinks somebody has connected to it (from a previous failed download),
it won't accept a new connection. Same for pairing.

(b) the shearwater BT stack is _slow_. The new "Petrel Native Format"
makes things worse, because it's much chattier (and yes, I suspect
libdivecomputer probably downloads too much, making the problem even
worse).

Anyway, with those three caveats, the Linux desktop download does work
quite reliably for me. But what I usually do is

- avoid bonded pairing

- turn on the teric bluetooth mode and immediately do a "scan" in subsurface

- re-pair (using right-click in the subsurface scan list). Unpair if required.

- download

and these extra steps - that *should* be entirely unnecessary - tend
to give a reliable end result. But that is only true if I haven't used
another device (like my android phone) to connect to it recently,
because then the silly dive computer seems to sometimes really want to
connect to just that previous device.

And yes, it's somewhat annoying. Part of the annoyance is that
subsurface requires that pairing to work - because apparently that's
the only way to make things work at all on iOS. Neither the Shearwater
dive computers nor the Linux desktop require it, and just connecting
to the dive computer without pairing works fine and actually avoids
some issues. But we do what we do due to cross-platform issues, which
is a common source of small annoyances.

And yes, it's horrendously slow. And part of that is probably us, but
part of that is most definitely shearwater. I really like my Teric
(and I really liked the Perdix AI), but I like them when _diving_. Not
when downloading things.

Linus

[Vincent Tassy]

Thanks for the comprehensive answer Linus,

I follow the exact same procedure you describe (Turn on BT on Perdix, Scan In SubSurface, Unpair, Pair, Save, Download) and it used to do the trick. It used to
work every single time.

But for a few weeks (I think), here's what happens. I just attempted a download right before writing this reply.

For the context, I dived yesterday, surface time on Perdix is 33h15. I already downloaded the dive yesterday (26h ago). No other equipment (Android phone) has
been used to download logs recently and their BT is turned off just in case.

I follow the above-mentioned procedure all the way to launching the download (no issue with pairing so far).

Model, Firmware, Serial # appear on the SubSurface download screen and after a few seconds, less than a minute, I get a popup in Subsurface reporting a "Dive
data import error" (which seems to originate, unsurprisingly, from core/libdivecomputer.c)

See attached the Log Error that also appears on the Perdix ! It didn't use to do that before ...

What I read in the libdivecomputer log is:

ERROR: Failed to receive the packet. [in shearwater_common.c:239 (shearwater_common_slip_read)]
ERROR: Failed to receive the response packet. [in shearwater_common.c:379 (shearwater_common_transfer)]
ERROR: Failed to download the dive. [in shearwater_petrel.c:380 (shearwater_petrel_device_foreach)]

Doesn't help much ... Note That the error appears first in SubSurface and only a few seconds later on the Perdix. I guess it's "timeouting"

This is when the chaos I was mentioning kicks in...

Since the pairing was originally OK and the download started, you would think that I could just hit the Retry Download button, but that systematically fails. So
I try to unpair and re-pair but it doesn't come easy and getting it right seems to be really only based on luck from there on...

Every attempt to pair results in "Local device error: Pairing Error. If the remote device requires a custom PIN code, please try to pair the devices using your
operating system"

Turning off the Perdix BT stack, or the entire Perdix, Turning off the BT stack on the Desktop from SubSurface or from KDE systray, relaunching SubSurface
(doubtful regarding this one but when you're desperate ...) , I have not yet figured out the proper course of events that resets the stage but it takes quite a
number of tries  ...

When I eventually manage to re-pair the Perdix, then the log download will work right away. I never get this Import Error twice...

I'm running 4.9.3 built from the source RPM over a month ago on my Fedora 29 and I'm using KDE Plasma.

Maybe I should try the AppImage in case one of the Fedora libs is causing the trouble ...

Safe travels if you're flying home !

Vince.

P.s. A friend lent me a Teric last week I used as a backup for a couple of Trimix dives, that is really a beauty !!

[Linus Torvalds]

On Sun, Oct 27, 2019 at 3:42 PM Vincent Tassy <tim...@gmail.com> wrote:
>
> I follow the above-mentioned procedure all the way to launching the download (no issue with pairing so far).
>
> Model, Firmware, Serial # appear on the SubSurface download screen

Ok, that means it connected fine, and the data transfer started. So
things are working.

It's usually getting to that stage that has been problematic, but
that's not your issue, clearly.

> and after a few seconds, less than a minute, I get a popup in Subsurface reporting a "Dive
> data import error" (which seems to originate, unsurprisingly, from core/libdivecomputer.c)

So you seem to have an actual "packets lost" issue.

That generally shouldn't happen, but I've seen machines with flaky BLE
before. My laptop tends to have much more solid bluetooth than my
desktop machine does, for example.

> See attached the Log Error that also appears on the Perdix ! It didn't use to do that before ...

That's just "transfer started, but then timed out". Matches the
libdivecomputer log you quote

> What I read in the libdivecomputer log is:
>
> ERROR: Failed to receive the packet. [in shearwater_common.c:239 (shearwater_common_slip_read)]
> ERROR: Failed to receive the response packet. [in shearwater_common.c:379 (shearwater_common_transfer)]
> ERROR: Failed to download the dive. [in shearwater_petrel.c:380 (shearwater_petrel_device_foreach)]

where libdivecomputer just gives up when there's lost data.

Some of the libdivecomputer backends do retries, but the shearwater
one doesn't. It may not even be possible, I'm not sure.

> This is when the chaos I was mentioning kicks in...
>
> Since the pairing was originally OK and the download started, you would think that I could just hit the Retry Download button, but that systematically fails.

Yeah, no. That's where the shearwater bad BT implementation comes in.

It *might* work if you restart the shearwater bluetooth thing, but
it's also possible that there's just pending data. It also looks like:

> Every attempt to pair results in "Local device error: Pairing Error. If the remote device requires a custom PIN code, please try to pair the devices using your
> operating system"

this probably means that there's some BT confusion on the desktop
computer side too.

> I'm running 4.9.3 built from the source RPM over a month ago on my Fedora 29 and I'm using KDE Plasma.
>
> Maybe I should try the AppImage in case one of the Fedora libs is causing the trouble ...

It might be worth upgrading to F30, which is what I'm on. The Qt
bluetooth integration with bluez has been problematic, but it seems to
have been sorted out - but it's possible that F29 is still on
sluightly flaky ground.

But it might also be a dodgy bluetooth driver and/or controller. As
mentioned, that happens. Bluetooth in laptops _tends_ to be fairly
good (because people actually use it), but a lot of bluetooth is just
legacy and mainly mouse, keyboard and audio. So not all drivers and
not all chipsets have equally good support.

But a Qt issue is traditionally the biggest reason. It *used* to be
that Qt did all of its BLE communication directly, bypassing bluez
entirely. That worked quite well most of the time, but made scanning
really really slow (because there was no system caching of device
information), and it could result in odd problems when the system
bluetooth stack (bluez) did something at the same time as the Qt app.
And it required very specific versions of Qt to work at all - we used
to build our own version of Qt with various fixes for a long while to
get working BLE.

Then Qt moved over to using the proper bluez interfaces, but that
transition wasn't entirely smooth. I know F30 works fine (well, it
does for _me_), but I don't recall if there were issues on F29.

But as mentioned, it might also be a dodgy driver. Do you happen to
know what bluetooth hardware you have? I have successfully used btusb
devices (most of the BLE USB sticks, and a lot of the integrated
laptop ones), and the Intel bluetooth module from their wireless
mobile chipsets.

Linus

[Vincent Tassy]

OK, all clear.

On 27/10/2019 21:08, Linus Torvalds wrote:
> It might be worth upgrading to F30, which is what I'm on. The Qt
> bluetooth integration with bluez has been problematic, but it seems to
> have been sorted out - but it's possible that F29 is still on
> sluightly flaky ground.

I've been meaning to upgrade anyway, we'll see if that makes a difference.

> But as mentioned, it might also be a dodgy driver. Do you happen to
> know what bluetooth hardware you have? I have successfully used btusb
> devices (most of the BLE USB sticks, and a lot of the integrated
> laptop ones), and the Intel bluetooth module from their wireless
> mobile chipsets.

I'm using the USB dongle that came with the Shearwater.

It's reported as: ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode)

It's using the btusb driver

Note that I've had the Perdix for a couple of years and been downloading dives just fine in Subsurface all this time with that exact same hardware. The only
changes have been the upgrades/updates of Fedora and version of SubSurface and the problems are recent ... Therefore the F29 might indeed be the culprit, we'll see.

Vincent.

[Linus Torvalds]

On Mon, Oct 28, 2019, 07:31 Vincent Tassy <tim...@gmail.com> wrote:

I'm using the USB dongle that came with the Shearwater.

It's reported as: ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode)

It's using the btusb driver

That should be fine. I've used that one myself, and my current laptop has an integrated version of it.

Note that I've had the Perdix for a couple of years and been downloading dives just fine in Subsurface all this time with that exact same hardware. The only
changes have been the upgrades/updates of Fedora and version of SubSurface and the problems are recent ... Therefore the F29 might indeed be the culprit, we'll see.

Knock wood, but yes, it does sound like it might just be Qt library versions.

      Linus

[Vincent Tassy]

Well, I upgraded to Fedora 30 and rebuilt SubSurface but unfortunately the issue is still present.

I'll try to use older versions of SubSurface as AppImage to see if it makes a difference although I doubt it.

Vincent.

[Lubomir I. Ivanov]

Downloading from Perdix AI works for me on the latest Windows 10.
the trick is to unpair and pair before each Download in Subsurface.

watch the Control Panel list of BT devices where Perdix should turn
from Paired to Connected on a good run.

lubomir
--