Subsurface mobile unable to download from ScubaPro G2

[Adric Norris]

I had an issue over the weekend, where I was unable to download a recently
completed dive via BLE using Subsurface mobile [phone]) for Android.
No errors were reported, and the G2 did indicate that a device was
connected during the download attempt, but Subsurface kept reporting that
no new dives were found. Restarting the phone didn't make any difference.

Unlike the desktop version, I didn't see any option to force download of
all dives or create a libdivecomputer logfile (although the documentation
indicates the latter should be present in Settings). So I'm not sure if the
app wasn't seeing the new dive, or for some reason wasn't considering it to
be a valid item and consequently skipping it. The only difference I can
think of from previous dives, which were downloaded successfully, is that
this one was had the G2 set to Sidemount mode.

This morning I tried again, via USB from a Windows 10 VM this time, and the
dive was recognized and processed without issue. So if it is related to
Sidemount mode (and that's *pure* speculation), the issue appears to be
specific to the mobile app.

The phone in question is a Google Pixel XL running Android 9, which has
been used a number of times to successfully download dives from my G2. The
G2 is running the current 1.4 firmware.

Any suggestions on how I should go about diagnosing this issue? I'll be
happy to provide libdivecomputer dump/log files, if someone can let me know
how to generate them from the Android mobile app.

Thanx!

[Dirk Hohndel]

I had an issue over the weekend, where I was unable to download a recently completed dive via BLE using Subsurface mobile [phone]) for Android. No errors were reported, and the G2 did indicate that a device was connected during the download attempt, but Subsurface kept reporting that no new dives were found. Restarting the phone didn't make any difference.
Unlike the desktop version, I didn't see any option to force download of all dives or create a libdivecomputer logfile (although the documentation indicates the latter should be present in Settings). So I'm not sure if the app wasn't seeing the new dive, or for some reason wasn't considering it to be a valid item and consequently skipping it. The only difference I can think of from previous dives, which were downloaded successfully, is that this one was had the G2 set to Sidemount mode.

Subsurface-mobile always creates a log file and libdivecomputer log file. After an unsuccessful attempt, simply go to the About page, click the button and then paste the log files into an email message.

This morning I tried again, via USB from a Windows 10 VM this time, and the dive was recognized and processed without issue. So if it is related to Sidemount mode (and that's pure speculation), the issue appears to be specific to the mobile app.

No, I doubt it's sidemount related. More likely a BLE issue.

The phone in question is a Google Pixel XL running Android 9, which has been used a number of times to successfully download dives from my G2. The G2 is running the current 1.4 firmware.
Any suggestions on how I should go about diagnosing this issue? I'll be happy to provide libdivecomputer dump/log files, if someone can let me know how to generate them from the Android mobile app.

See above. Please try a BLE download on the phone and then send the log files

/D

[Linus Torvalds]

Post by Dirk Hohndel
No, I doubt it's sidemount related. More likely a BLE issue.

Hmm. I just verified that my G2 connects and sends/receives over BLE
just fine. So none of the recent BLE cleanups and fixes have broken
that part.

I downloaded all the 78 dives I had on that thing, so it was

That said, the Uwatec Smart back-end (which is what does the G2) is
one of the backends that doesn't even try to do any retries. And in
fact, the Uwatec Smart protocol makes it basically impossible to do
retries: it just asks for "give me all data", rather than have some
"give me the next bit" that you could retry.

So *any* packet loss will cause the download to fail, but generally
BLE is perfectly reliable (checksums and retries at the BLE level) so
just make sure the connection is good.

But yes, having a log-file of the failure would be good. Particularly
with one of the recent versions that have the whole packet log and
timing for BLE communication. Just in case something stands out.

Linus

[Adric Norris]

I should have added that I wiped data for the Subsurface mobile app before
retrying the download, and generating the *subsurface.log* and
*libdivecomputer.log* files. This was meant to ensure that it attempted to
download all dives, rather than just the one from this weekend. The result
was still "Info: No new dives downloaded from dive computer".

Ah, it looks like I had somehow disabled Storage permission for the app.
No wonder I couldn't find the diagnostic files.
I've attached a zipfile containing *subsurface.log* and
*libdivecomputer.log*.

Post by Adric Norris
I had an issue over the weekend, where I was unable to download a
recently completed dive via BLE using Subsurface mobile [phone]) for
Android. No errors were reported, and the G2 did indicate that a device was
connected during the download attempt, but Subsurface kept reporting that
no new dives were found. Restarting the phone didn't make any difference.
Unlike the desktop version, I didn't see any option to force download of
all dives or create a libdivecomputer logfile (although the documentation
indicates the latter should be present in Settings). So I'm not sure if the
app wasn't seeing the new dive, or for some reason wasn't considering it to
be a valid item and consequently skipping it. The only difference I can
think of from previous dives, which were downloaded successfully, is that
this one was had the G2 set to Sidemount mode.
Subsurface-mobile always creates a log file and libdivecomputer log file.
After an unsuccessful attempt, simply go to the About page, click the
button and then paste the log files into an email message.
This morning I tried again, via USB from a Windows 10 VM this time, and
the dive was recognized and processed without issue. So if it is related to
Sidemount mode (and that's *pure* speculation), the issue appears to be
specific to the mobile app.
No, I doubt it's sidemount related. More likely a BLE issue.
The phone in question is a Google Pixel XL running Android 9, which has
been used a number of times to successfully download dives from my G2. The
G2 is running the current 1.4 firmware.
Any suggestions on how I should go about diagnosing this issue? I'll be
happy to provide libdivecomputer dump/log files, if someone can let me know
how to generate them from the Android mobile app.
See above. Please try a BLE download on the phone and then send the log files
/D

--
"In the beginning the Universe was created. This has made a lot of people
very angry and been widely regarded as a bad move." -Douglas Adams

[Adric Norris]

Stupid question... does version 2.1.5 (4.8.3.307) include the
libdivecomputer fix for the G2 download issue with firmware version 1.4? I
received the app update 2 days ago, and it's failing to download in what
appears (at least superficially) to be the same manner.

Please be aware that I recently replaced my original phone with a Google
Pixel 3 XL, so I can't rule out a phone issue at this point.

I've attached subsurface.log and libdivecomputer.log, just in case they're
needed.

Thanx!

Not that it matters much at this point, but I'm pretty sure the change
would have started with the 1.4 firmware. I remember learning there was an
update the night before my Tec 40 class, and decided to defer it since I
didn't want to risk breaking anything at the time.
On Mon, Oct 8, 2018 at 2:29 PM Linus Torvalds <

On Mon, Oct 8, 2018 at 12:09 PM Linus Torvalds

But I can just ignore the odd byte - and then my G2 download succeeds.

https://github.com/Subsurface-divelog/libdc/commit/f0fe141373dd3f1ff5b7b6d2c0f13b47da894096
Jef - the comment in there says it all. The G2 BLE behavior is very
odd as of fw 1.4, but it seems intentional.
Maybe it started earlier, I never tested the 1.3 firmware.
I suspect Uwatec uses the new first byte to figure out lost packets or
something - and it may be related to the fact that now their desktop
app seems to support bluetooth on Windows too (at least I don't
_think_ it used to, but who knows).
In the meantime, I changed it to still treat the first byte as a
length byte - unless it's larger than the possible packet size. The
USB HID side definitely still treats it as a length byte, even for the
"long stream" case. And I suspect the odd pattern has been chosen
explicitly so that the new byte has that "bigger than a packet"
behavior, because the first byte is never smaller than 20 (except for
the small packet case where it still is the length).
Dive computer manufacturers are odd, odd, odd.
Linus

--
"In the beginning the Universe was created. This has made a lot of people
very angry and been widely regarded as a bad move." -Douglas Adams