Aqualung I750TC with Subsurface Mobile iOS via Bluetooth

[korky]

Hi there,

I am having trouble connecting my i750TC with the ios-app. It just can not be selected amongst the Aqualung models (it has the i770R and i550C though - but neither work with this one).

The devices list shows the i750TC as supported with both, bluetooth and serial connection.

I found some old threads about connection issues but I think they are outdated.

Does anybody know how to fix this? Or has anybody recently successfully downloaded dives from the i750TC to Subsurface?

Thanks a lot

korky

[korky]

PS: i did successfully connect it with the official diverlog-app on my ios device

[Dirk Hohndel]

iOS hands BLE devices exclusively to one app. So unless the diverlog-app releases the device (which I doubt),  once you talk to it, Subsurface-mobile won't see it.

A reboot helps - but make sure not to start diverlog before starting Subsurface

Occasionally we miss the right BLE names and by default don't find a dive computer. There is a non-permanent setting in the advanced settings to show all possible BLE device.

Select that and try again. If that works, please send us a log.

/D  

--
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/40a5a4d9-dfa5-4462-9840-dae78078a02dn%40googlegroups.com.

[korky]

Thank you for the quick reply.

A reboot did not help in my case. In fact, I had tried the subsurface connection before I even installed the other app.

After turning on the "show all BT devices" my i750 shows but there is no dive list and nothing is imported. Maybe because, I can not even select the right model? I tried i770R and i450TC.

Also, there is no log - it says "nicht persistent".

Thanks again for helping

[Dirk Hohndel]

> On Jan 23, 2021, at 09:04, 'korky' via Subsurface Divelog <subsurfac...@googlegroups.com> wrote:
> A reboot did not help in my case. In fact, I had tried the subsurface connection before I even installed the other app.

It’s just something I always point out to people as that behavior is quite confusing - and frankly I don’t understand how (and why) it happens.

> After turning on the "show all BT devices" my i750 shows but there is no dive list and nothing is imported. Maybe because, I can not even select the right model? I tried i770R and i450TC.

What would be useful for the developers is the folloing:
- select the ‘show all BT devices’ option
- go to the download page, select the i450TC and the correct BLE device for your i750TC and attempt to download
- even if nothing was downloaded, now go to the main menu -> Help -> About (Hilfe -> Ueber) and tap on the button there to copy all the log files.
- paste these logs into an email - either here to the group or directly to me if you are worried about privacy concerns

Hopefully this will help me figure out a bit more of what is happening.

> Also, there is no log - it says "nicht persistent".

That just means that the next time you start this option (to show all Bluetooth devices) will be reset to off.

/D

[Dirk Hohndel]

On Jan 23, 2021, at 9:19 AM, Dirk Hohndel <di...@hohndel.org> wrote:

After turning on the "show all BT devices" my i750 shows but there is no dive list and nothing is imported. Maybe because, I can not even select the right model? I tried i770R and i450TC.

What would be useful for the developers is the folloing:
- select the ‘show all BT devices’ option
- go to the download page, select the i450TC and the correct BLE device for your i750TC and attempt to download
- even if nothing was downloaded, now go to the main menu -> Help -> About (Hilfe -> Ueber) and tap on the button there to copy all the log files.
- paste these logs into an email - either here to the group or directly to me if you are worried about privacy concerns

Hopefully this will help me figure out a bit more of what is happening.

So Amin sent me a log, here are the key parts with all of the noise (and all of the potentially personal info) deleted:

"0.001: Starting Subsurface-mobile:3.1.2(4.9.10.139):iOS 14.3:arm64:de-DE"

"0.001: built with libdivecomputer v0.7.0-devel-Subsurface-NG (e58a5866bbd6d12fba7b3482c11d0ae2bed2e1c4)"

"0.001: built with Qt Version 5.15.2, runtime from Qt Version 5.15.2"

"0.001: built with libgit2 1.0.1"

"0.001: Running on iOS 14.3"

So we are on an i-Device

Discovered new device: "EZ001945" "LE:{cb0ff33a-40d3-63eb-2764-11e63896534f}"

Not recognized as dive computer

Oh look, it finds a BLE device (since iDevices don't do BT) which matches the pattern for an Aqualung/Pelagic dive computer with model code 0x455A (hex for 'EZ')

That's super interesting, since libdivecomputer says:

{"Aqualung", "i750TC",              DC_FAMILY_OCEANIC_ATOM2, 0x455A, DC_TRANSPORT_SERIAL | DC_TRANSPORT_BLUETOOTH, NULL},

so this is assumed to be a BT only dive computer without BLE support.

"235.974: DCDownloadThread started for Aqualung i470TC on LE:{cb0ff33a-40d3-63eb-2764-11e63896534f} downloading only new dives"

Starting download from  "BLE"

downloading only new dives

"235.978: Connecting to BLE device LE:{cb0ff33a-40d3-63eb-2764-11e63896534f}"

---> stopping the discovery agent

BT/BLE finished discovery

"" "00:00:00:00:00:00"

qt_ble_open( {cb0ff33a-40d3-63eb-2764-11e63896534f} )

trying to connect

"241.366: AppState changed to inactive with no unsaved changes"

"241.954: AppState changed to suspended with no unsaved changes"

failed to connect to the controller  {cb0ff33a-40d3-63eb-2764-11e63896534f} with error "Remote device cannot be found"

"242.420: Failed to connect to {cb0ff33a-40d3-63eb-2764-11e63896534f}: 'Remote device cannot be found'"

"242.421: Unsupported operation"

Finishing download thread: "Fehler beim Öffnen von LE:{cb0ff33a-40d3-63eb-2764-11e63896534f} Aqualung (i470TC)"

"242.433: no new dives downloaded"

"242.433: DCDownloadThread finished"

So from the looks of this we completely fail to talk to the dive computer at all.

"Remote device cannot be found".

I'm not familiar with the Aqualung dive computer -- do you have to switch it into some Bluetooth transfer mode (most BLE dive computers require that)?

Because from what I can see here it didn't talk to us at all - and it should at least respond to our attempt to open a connection.

Jef, are you familiar with an i750TC BLE version? I would have hoped that trying to use the i470TC as communication model might be close enough to get us 'something' here, but it seems that we got nowhere...

/D

[Jef Driesen]

On 23/01/2021 19:41, Dirk Hohndel wrote:
> So Amin sent me a log, here are the key parts with all of the noise (and all of
> the potentially personal info) deleted:
>
> "0.001: Starting Subsurface-mobile:3.1.2(4.9.10.139):iOS 14.3:arm64:de-DE"
> "0.001: built with libdivecomputer v0.7.0-devel-Subsurface-NG
> (e58a5866bbd6d12fba7b3482c11d0ae2bed2e1c4)"
> "0.001: built with Qt Version 5.15.2, runtime from Qt Version 5.15.2"
> "0.001: built with libgit2 1.0.1"
> "0.001: Running on iOS 14.3"
>
> So we are on an i-Device
>
> Discovered new device: "EZ001945" "LE:{cb0ff33a-40d3-63eb-2764-11e63896534f}"
> Not recognized as dive computer
>
>
> Oh look, it finds a BLE device (since iDevices don't do BT) which matches the
> pattern for an Aqualung/Pelagic dive computer with model code 0x455A (hex for 'EZ')
> That's super interesting, since libdivecomputer says:
> {"Aqualung", "i750TC",              DC_FAMILY_OCEANIC_ATOM2, 0x455A,
> DC_TRANSPORT_SERIAL | DC_TRANSPORT_BLUETOOTH, NULL},
>
> so this is assumed to be a BT only dive computer without BLE support.

This is a modification in the subsurface fork. In my version the i750TC is not
marked as bluetooth enabled. I don't know if that's supported or not. I checked
my email archive, and the user back than did use the usb-serial cable, so that's
what I enabled. It's certainly possible it does support rfcomm and/or BLE, but I
can't confirm that.

I have no direct experience with the i750TC, or it's bluetooth support. Normally
trying as another model should work fine. There are a few exceptions for the BLE
name based handshake, but according to the above log setting up the bluetooth
connection already fails, so we don't even get to that point.

Sorry, I have no idea why it fails.

Jef

[Linus Torvalds]

On Sat, Jan 23, 2021 at 10:41 AM Dirk Hohndel <di...@hohndel.org> wrote:
>
> Oh look, it finds a BLE device (since iDevices don't do BT) which matches the pattern for an Aqualung/Pelagic dive computer with model code 0x455A (hex for 'EZ')
> That's super interesting, since libdivecomputer says:
> {"Aqualung", "i750TC", DC_FAMILY_OCEANIC_ATOM2, 0x455A, DC_TRANSPORT_SERIAL | DC_TRANSPORT_BLUETOOTH, NULL},

Ok, will add BLE to that.

It should also get "dc_filter_oceanic" as the filter, although
subsurface doesn't use the filter functions.

It would be nice to be able to use the libdivecomputer filtering
functions, but the problem is that they are the "wrong way around":
they work once you already know which dive computer you have, and
subsurface wants to show the list of dive computers in order for the
user to then choose which one.

So right now the libdivecomputer filter functions look like a good
thing, but not usable as-is, I think.

That said:

> qt_ble_open( {cb0ff33a-40d3-63eb-2764-11e63896534f} )
> trying to connect
> "241.366: AppState changed to inactive with no unsaved changes"
> "241.954: AppState changed to suspended with no unsaved changes"
> failed to connect to the controller {cb0ff33a-40d3-63eb-2764-11e63896534f} with error "Remote device cannot be found"

The connect seems to have failed, so adding the BLE thing to
libdivecomputer won't really help. But clearly it *does* have some BLE
functionality, so we should do it if only in the hopes that somebody
successfully connects and it either works or we can at least dump it.

Linus

[Dirk Hohndel]

> On Jan 23, 2021, at 11:07 AM, Jef Driesen <j...@libdivecomputer.org> wrote:
>
> On 23/01/2021 19:41, Dirk Hohndel wrote:
>> So Amin sent me a log, here are the key parts with all of the noise (and all of the potentially personal info) deleted:
>> "0.001: Starting Subsurface-mobile:3.1.2(4.9.10.139):iOS 14.3:arm64:de-DE"
>> "0.001: built with libdivecomputer v0.7.0-devel-Subsurface-NG
>> (e58a5866bbd6d12fba7b3482c11d0ae2bed2e1c4)"
>> "0.001: built with Qt Version 5.15.2, runtime from Qt Version 5.15.2"
>> "0.001: built with libgit2 1.0.1"
>> "0.001: Running on iOS 14.3"
>> So we are on an i-Device
>> Discovered new device: "EZ001945" "LE:{cb0ff33a-40d3-63eb-2764-11e63896534f}"
>> Not recognized as dive computer
>> Oh look, it finds a BLE device (since iDevices don't do BT) which matches the pattern for an Aqualung/Pelagic dive computer with model code 0x455A (hex for 'EZ')
>> That's super interesting, since libdivecomputer says:
>> {"Aqualung", "i750TC", DC_FAMILY_OCEANIC_ATOM2, 0x455A, DC_TRANSPORT_SERIAL | DC_TRANSPORT_BLUETOOTH, NULL},
>> so this is assumed to be a BT only dive computer without BLE support.
>
> This is a modification in the subsurface fork. In my version the i750TC is not marked as bluetooth enabled. I don't know if that's supported or not. I checked my email archive, and the user back than did use the usb-serial cable, so that's what I enabled. It's certainly possible it does support rfcomm and/or BLE, but I can't confirm that.

Ahh, I should have checked that.
Indeed, going through my email archives we had a user that reported successful downloads from an i750TC on Android as a BT device. And I added that to our sources.
But in the case here for Amin it's clearly a BLE device as other wise his iOS device wouldn't see the dive computer at all.
I guess I need to mark it to support both.

> I have no direct experience with the i750TC, or it's bluetooth support. Normally trying as another model should work fine. There are a few exceptions for the BLE name based handshake, but according to the above log setting up the bluetooth connection already fails, so we don't even get to that point.
>
> Sorry, I have no idea why it fails.

Thanks - I appreciate the quick response.
I'll add this as a BLE device with correct detection based on name and then we can work with Amin to try and figure out why this might still be failing.

/D

[Linus Torvalds]

On Sat, Jan 23, 2021 at 11:16 AM Dirk Hohndel <di...@hohndel.org> wrote:
>
> I'll add this as a BLE device with correct detection based on name and then we can work with Amin to try and figure out why this might still be failing.

I did the libdivecomputer side. I was doing the merge of Jef's other
recentish changes anyway.

I've pushed it out, but am obviously not able to actually test..

Linus

[Dirk Hohndel]

> On Jan 23, 2021, at 11:11 AM, Linus Torvalds <torv...@linux-foundation.org> wrote:
>
> On Sat, Jan 23, 2021 at 10:41 AM Dirk Hohndel <di...@hohndel.org> wrote:
>>
>> Oh look, it finds a BLE device (since iDevices don't do BT) which matches the pattern for an Aqualung/Pelagic dive computer with model code 0x455A (hex for 'EZ')
>> That's super interesting, since libdivecomputer says:
>> {"Aqualung", "i750TC", DC_FAMILY_OCEANIC_ATOM2, 0x455A, DC_TRANSPORT_SERIAL | DC_TRANSPORT_BLUETOOTH, NULL},
>
> Ok, will add BLE to that.

Excellent. I also noticed that Jef has made a few changes since our last sync.

>
>> qt_ble_open( {cb0ff33a-40d3-63eb-2764-11e63896534f} )
>> trying to connect
>> "241.366: AppState changed to inactive with no unsaved changes"
>> "241.954: AppState changed to suspended with no unsaved changes"
>> failed to connect to the controller {cb0ff33a-40d3-63eb-2764-11e63896534f} with error "Remote device cannot be found"
>
> The connect seems to have failed, so adding the BLE thing to
> libdivecomputer won't really help. But clearly it *does* have some BLE
> functionality, so we should do it if only in the hopes that somebody
> successfully connects and it either works or we can at least dump it.

That's what I'm hoping.
We also need detection in core/btdiscovery.cpp -- are you going to add that as well or should I do this?

Thanks

/D

[Linus Torvalds]

On Sat, Jan 23, 2021 at 11:18 AM Dirk Hohndel <di...@hohndel.org> wrote:
>
> We also need detection in core/btdiscovery.cpp -- are you going to add that as well or should I do this?

I think you should.

Ugh, looking at that, I really dislike it all. We should have some
kind of array of known regular expressions or something.

Or, better yet, some better way to get at the libdivecomputer data.
libdivecomputer already effectively maintains many of these patterns
in its "filter" functions, but as mentioned, the way they work is that
you have to already have picked the device.

Maybe we could iterate over all libdivecomputer devices, and call the
filter function for every one of them. But that sounds wrong too.

Linus

[Jef Driesen]

Maybe introduce some variant of the dc_descriptor_iterator function where you
pass the transport type, along with the userdata parameter. That way, the
iterator can filter out descriptors that don't match. I think something like
that should work for your use case.

Jef

[Linus Torvalds]

On Sat, Jan 23, 2021 at 12:04 PM Jef Driesen <j...@libdivecomputer.org> wrote:
>
> Maybe introduce some variant of the dc_descriptor_iterator function where you
> pass the transport type, along with the userdata parameter.

Yeah, something like that would probably be good. And then we'd see
the dive computer name from the descriptor that matches.

Of course, right now the way the filter functions tend to work is that
they just return 1 by default, so if they don't have a BLE rule at
all, they'll unconditionally match.

So it would have to be careful that if the dive computer descriptor
claims to support BLE, and it has a filter, then that filter really
does need to check the name.

Maybe they all already do, but from a quick look it looked potentially
a bit sketchy and ripe for subtle bugs.

I guess subsurface could double-check by (a) looping over all devices
even if one claims to match and (b) when it gets a filter match it
would double-check with a bogus BLE name, just to verify that the
filter doesn't just always return true..

Linus

[Dirk Hohndel]

The design of the filter function right now confuses me a little.
I'm actually not sure how it is supposed to be used. I looked at its use in the libdivecomputer code and am maybe even more confused.
Which typically means that I am missing something.

Currently you have different source files for the various transport types, so bluetooth.c, usbhid.c, etc.
And in those files you implement an iterator that uses the filter to determine if a descriptor is viable.
And a return value of 1 from the filter implies that 'yes, this matches'.
But at the same time, a number of the filters always return 1. For example dc_filter_atomic(), when presented with a BT transport, will always, unconditionally, return 1.

Can you help me understand why that makes sense? I would have expected that filter function to always return 0, except when the transport is DC_TRANSPORT_USB and then VID/PID match.

As I said, I'm clearly missing something. Because I have no idea how I would be able to use these filters to tell me which dive computer might be represented by a specific BLE name.

/D

[Dirk Hohndel]

I tried to come up with a design that used the filter function, but because

of those "I return 1 unconditionally" cases I had a really hard time coming

up with something even remotely sane.

Maybe I wasn't thinking out of the box enough?

Instead I created a modified version of our own detection. But I'm honestly

not sure how much of an improvement it is. I mean, yeah, it's now two

tables that likely are much easier to maintain... but it doesn't really reduce

the amount of code by any meaningful amount.

Linus, I'm curious what you think about the code I came up with...

https://github.com/subsurface/subsurface/pull/3183

/D

[Jef Driesen]

In the descriptors, a NULL pointer for the filter means no filter at all. In
that case nothing is ever filtered out. This is mainly used for serial
communication, where we can't detect anything based on just the name of the
serial port. So every serial port will match, to prevent showing an empty list
to the user.

Now, we only have one filter function, even for descriptors that support
multiple transports. Hence for transports for which the filter function doesn't
implement any filtering, it behaves the same as a NULL pointer by returning 1
(nothing filtered out).

So basically the filter logic works in reverse by filtering *out* entries. By
default we return everything (NULL or returning 1), and only if we are sure an
entry doesn't match it gets filtered out (by returning 0). Does that help to
understand how it works?

Jef

[Dirk Hohndel]

> On Jan 23, 2021, at 3:17 PM, Jef Driesen <j...@libdivecomputer.org> wrote:
>
> In the descriptors, a NULL pointer for the filter means no filter at all. In that case nothing is ever filtered out. This is mainly used for serial communication, where we can't detect anything based on just the name of the serial port. So every serial port will match, to prevent showing an empty list to the user.
>
> Now, we only have one filter function, even for descriptors that support multiple transports. Hence for transports for which the filter function doesn't implement any filtering, it behaves the same as a NULL pointer by returning 1 (nothing filtered out).
>
> So basically the filter logic works in reverse by filtering *out* entries. By default we return everything (NULL or returning 1), and only if we are sure an entry doesn't match it gets filtered out (by returning 0). Does that help to understand how it works?

Thanks for confirming what I thought I understood.

I'd state that this is not really all that useful, but that's of course always in the eye of the beholder.

But if I think about detection logic like this, I always think about it as a tri-state thing. yes, maybe, no.
In that sense, if I know that something cannot be the right dive computer (e.g., it doesn't support the transport that is being passed in, or it requires a certain name and the name doesn't match), we return NO
If we know this is the correct dive computer (e.g., it does have the unique VID/PID that only this dive computer uses, or it matches the BLE naming pattern), we return YES
In all other cases (and that includes not having a filter), we return MAYBE

Since this would simply change an internal implementation detail of your library and the consumers in your code could be trivially adjusted to such a change - would you be willing to entertain a pull request that implemented that?

This way we could build our own filter function that does positive filtering and reuse the code that is already there in libdivecomputer and wouldn't have to essentially maintain more or less identical code in two places.

Thanks

/D

[korky]

Thanks for all of your efforts.

Frankly though, you lost me somewhere aroung the filters and transports.

Is there something I can do to make my DC communicate with subsurface? Or is there something I can test or send to you to help tackle this issue?

Best wishes

[Dirk Hohndel]

On Jan 24, 2021, at 11:50 AM, 'korky' via Subsurface Divelog <subsurfac...@googlegroups.com> wrote:

Thanks for all of your efforts.

Frankly though, you lost me somewhere aroung the filters and transports.

Is there something I can do to make my DC communicate with subsurface? Or is there something I can test or send to you to help tackle this issue?

Later today I will make a new test build for iOS available on TestFlight - you can join the test program here: https://testflight.apple.com/join/k2OGhIS5

Similarly, there will be a new Android build as well.

Both of them should at least recognize the i750TC out of the box.

The next step then is to figure out how to talk to it (and why in the previous attempt it didn't respond at all).

I had asked about any "bluetooth communication" setting in the dive computer, but I don't think you responded to that...

/D

[korky]

Great, I'll try the test program.

There is no real transfer mode with the i750TC but just an option to disable or enable bluetooth. The enabling is all that was needed to transfer the files to the aqualung-app. The manual states: "When Bluetooth is turned on it will operate in sniffing mode (searching for compatible devices) while on the surface. Communication with your i750TC must be initiated with your traditional computer or mobile device using Diverlog software."

Best wishes

[Dirk Hohndel]

On Jan 24, 2021, at 12:30 PM, 'korky' via Subsurface Divelog <subsurfac...@googlegroups.com> wrote:

Great, I'll try the test program.

There is no real transfer mode with the i750TC but just an option to disable or enable bluetooth. The enabling is all that was needed to transfer the files to the aqualung-app. The manual states: "When Bluetooth is turned on it will operate in sniffing mode (searching for compatible devices) while on the surface. Communication with your i750TC must be initiated with your traditional computer or mobile device using Diverlog software."

There is a small risk that the dive computer tries to be clever and remembers the last connection - but then there is usually a way to reset this on device (e.g., the Suunto EON Steel does that).

Please let us know how the next attempt goes.

/D

[korky]

Hi Dirk,

Testflight on iOS does not show me any updated version since your post. Latest is 4.9.10.416 dated 23. Jan.

No changes in this version as to my issues: I enable the "show all devices" option, select the i450TC, my device is found but no dives are displayed or downloaded.
The log states: "Discovered new device: [my DC]: not recognized as dive computer". Would the complete log help?

[Dirk Hohndel]

Strange - it looks like 417 never got pushed out, but 421 (which I just pushed) has already been approved, so you should see that.

/D

[korky]

Alright, that one arrived.

Some changes: It now shows i750TC as an option (which you probably implemented) and also recognizes my TC as a i750TC - before it just displayed some bluetooth ID with the device's serial number.

When I select it and tap download, the DC briefly reacts. The first time it read "pairing" for a very short time, now the bluetooth icon on the display starts to blink. So, there appears to be a connection now. Subsurface communicates with the DC, however still no dives are displayed or downloaded. I'll send you the log via mail if that helps.

Thanks again!

[korky]

The relevant part of my log is probably this:

"185.101: Connecting to BLE device LE:{cb0ff3 XXX 896534f}"

---> stopping the discovery agent
BT/BLE finished discovery
"" "00:00:00:00:00:00"

qt_ble_open( {cb0ff3 XXX 896534f } )
trying to connect
failed to connect to the controller  {cb0ff3 XXX 896534f} with error "Remote device cannot be found"
"189.017: Failed to connect to {cb0ff3 XXX 896534f}: 'Remote device cannot be found'"
"189.018: Unsupported operation"
Finishing download thread: "Fehler beim Öffnen von LE:{cb0ff3 XXX 896534f} Aqualung (i750TC)"
"189.044: no new dives downloaded"
"189.044: DCDownloadThread finished"

[Dirk Hohndel]

Yes, please do such a download attempt and after that either do Hilfe->Support fragen -- or go to Hilfe->Über and tap the buttons to copy the logs into an email (because with gmail as mail app the first option doesn't always work correctly)

Thanks

/D

--
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/be26d9d0-01ec-4fdb-8304-b6ae2c8d75a3n%40googlegroups.com.

[Dirk Hohndel]

Sorry - my email server was down all day and I hadn't seen your email with the log file.

We are still simply getting a timeout talking to the dive computer and nothing else...

I'm starting to lose hope

/D

To view this discussion on the web visit https://groups.google.com/d/msgid/subsurface-divelog/5FF83E40-1417-40EF-9306-3883E88C015F%40hohndel.org.