Oceans S1 Support

[Seth Garrison]

I recently bought the new Oceans S1 dive computer for it Buddy Ping feature. https://www.oceans.io/s1

Was curious what would be needed to get it supported by Subsurface. It is designed to connect via Bluetooth to their App currently, and i'm not sure yet if I can get raw data files off of it. Trying to look into that soon.

Anyone have thoughts or suggestions?

[Linus Torvalds]

On Thu, May 28, 2020 at 1:29 PM Seth Garrison <klo...@gmail.com> wrote:
>
> I recently bought the new Oceans S1 dive computer for it Buddy Ping
> feature. https://www.oceans.io/s1

Hmm. Looks otherwise interesting, but I'd miss air integration ;(

I like the look, the screen looks to be good, and I like that they use
standard Bühlmann. And BLE and Qi is definitely the way to go in a
modern setup.

So yeah, it is meant for relaxed recreational divers (looks like only
one gas, and 21-40% nitrox), but that's fine. It's the bulk of the
market by far.

But even recreational divers would enjoy things like gas time and not
having to look at both the dive computer and the SPG to see everything
important. And be able to see their SAC rates after-the fact etc.

> Was curious what would be needed to get it supported by Subsurface. It
> is designed to connect via Bluetooth to their App currently, and i'm
> not sure yet if I can get raw data files off of it. Trying to look
> into that soon.

Honestly, it's hard to say what that dive computer is based on, if
anything. It might be some entirely new design and have a comm
protocol unlike anything we already support.

Which can be a good thing: new designs often have more modern and
clearer protocols, because they aren't carrying around some horrid
legacy from when they used to communicate over a 1200 baud serial
line, and have gone through ten generations of adding random bits to
odd places to indicate new features.

But it's usually also a very bad thing in that it really requires
either support from the manufacturer (which is sadly very rare) or
extensive reverse-engineering of the communication protocol using a
bluetooth packet capture, wireshark, and often a lot of painstaking
attention to detail.

I've done a few of those packet capture sessions, and while it can be
interesting, it is seldom what I'd call "fun". And it requires some
work just to get the packet capture itself (usually using the Android
debug interfaces - not necessarily _hard_, but it's a somewhat
involved process to get all that set up).

And there's no guarantee reverse engineering will succeed. We support
the Garmin Descent Mk1 - but only over its USB interface, not over
bluetooth, because that Garmin protocol is just some very complex
thing that supports everything else garmin does too, and seems to be
more of a "upload this random data to garmin.com and then garmin will
parse it all server-side" thing that a "dive log download".

Now, most pure dive computers don't _intentionally_ make things harder
to parse, and complexities tend to be for historical reasons etc, but
it's certainly possible to make things inconvenient enough that
reverse-engineering just isn't going to happen. Worst case the
communication is encrypted, and even bad encryption (I'm looking at
you, Cochran) can make trying to figure out a file format or
communication protocol really painful.

So I'm willing to help look at packet traces remotely and see if I can
make sense if it all, but it would require a fair amount of effort on
your side: learning how to do packet captures from android (maybe it's
possible from iOS too, but I've never heard of that), then doing
multiple downloads, possibly having to uninstall and re-install the
app to start from scratch, etc etc.

(Judging by past performance, doing remote protocol debugiing and
reverse-engineering is really really painful, though - but if it
starts to look promising, I guess I could buy yet another dive
computer.. It's not like I don't have a lot of them already)

If you or anybody else have _any_ connections to the Oceans team, and
they'd help with this, that would be a big leg up. Looking at the
web-site, it seems they are based in Sweden, which might be a good
sign. But I don't know what the business model is: do they want to
just sell dive computers, and having support from a dive log like
subsurface is a good thing, or do they want to create a "oceans.io
experience" and they want to keep a walled garden?

I'm cc'ing their team contact directly here just in case. And Jef in
case he has maybe already seen something about the Oceans S1..

Oceans Team people, see

https://subsurface-divelog.org/

for our divelog project (and most of our downloaders come from us
working with https://www.libdivecomputer.org/).

Hej Oceans, hur öppna till att hjälpa ett projekt som subsurface
skulle ni vara? Dokumentation? Dykdatorer? Dokumentation är det
viktigare: vi har köpt våra egna dykdatorer när det behövs, men utan
någon information så är det antagligen inte värt det för mig..

Linus

[Seth Garrison]

Hi Linus,

Thanks for all the information. I don't have any direct connection to the team at Oceans unfortunately, but i did back their project on Kickstarter, which might be worth something. I'll try reaching out as well to see what we can get from them.

They did indicate at one point in the past that they might support subsurface (I asked during the Kickstarter Campaign), and that Air integration would be supported in the future.

As for remote debugging, i'm happy to help out any way I can. My current device is a Pixel 4XL, and i have an older Pixel 2XL that i'm happy to turn into a dedicated debug tool if needed. It's been a while since I've gotten deep into Android, but i'm happy to help any way i can.

Thanks!

Seth 

[Seth Garrison]

Hi Linus,

Not sure if this is helpful, but I was able to do a packet capture while downloading my test dive from yesterday. It may not be of any use without context, but I still thought that I should upload it.

Thanks again!

Seth 

[Linus Torvalds]

On Mon, Jun 1, 2020 at 5:36 PM Seth Garrison <klo...@gmail.com> wrote:
>
> Not sure if this is helpful, but I was able to do a packet capture while downloading my test dive from yesterday. It may not be of any use without context, but I still thought that I should upload it.

Ok, thanks.

It's actually somewhat informative already in this form.

In particular, it tells us that it uses that same Nordic Semi UART BLE
service that we've seen before

And the protocol actually looks line a fairly sane ASCII line-based
one. Which is actually not entirely surprising, because the way that
Nordic Semi UART service works, it buffers up the UART data until it
sees a newline, or a full BLE packet, so using a line-based interface
ends up being very natural with that UART.

So I see your Pixel start communication by sending the line "utc", and
the dive computer responds with "utc>ok 1591005510".

Which I suspect is the current time in utc, expressed as the usual
"seconds since Unix epoch".

That number is "Mon 01 Jun 2020 09:58:30 AM UTC" and the packet log
says the timestamp of that packet is "Jun 1, 2020 09:58:28.930795000
PDT"

So that's all _very_ sane. In fact, even the whole "UTC" part is sane
- most dive computers skip the whole timezone thing, and just do "utc
as local time". In fact, it's so common that it's exactly what
subsurface does too.

Then the next sequences are

"battery" -> "battery> ok 73%".
"version" -> "version>ok 1.1 42a7e564"
"utc 1591005510" -> "utc>ok"
"units 1" -> "units>ok"
"dllist" -> "dllist>xmr"

and at that point it seems to do some possible annoying
re-configuration (perhaps to turn off the line-based mode, I'm not
100% sure what the Nordic UART setup rules are), but then we get

"C" -> "divelog v1,10s/sample
dive 1,0,21,1590910099
error missing end event
enddive
dive 2,0,21,1590910514
enddive 785,34
dive 3,0,21,1590911392
enddive 1564,1266
dive 4,0,21,1590933443
continue 212,59
enddive 216,703
endlog"

which all looks eminently parseable too: the dive line looks like a
dive number, followed by a zero (Helium), followed by Oxygen
percentage, followed by start time of the cive.

And the "enddive" (and "continue") two values are presumably the time
relative to beginning and some other value (max depth? Who knows, but
those are things that matching up with your dive can tell).

Another couple of odd handshake packets (maybe "go back to single line
mode") and then it repeats that sequence for dllist. I'm guessing this
is just the dive downloader doing it twice - first for the list of
dives, then for the actual download.

Because then it asks for the dives themselves:

"dlget 3 4" -> "dlget/xmr"

"C" -> "divelog v 1,10s/sample dive 3, �divelog v1,10s/sample
dive 3,0,21,1590911392
414,23,1
572,23,51456
583,23,18688
604,23,60160
641,23,49408
671,23,16640
723,23,18688
758,23,26880
779,23,51968
851,22,51968
933,22,51968
959,22,60160
977,22,51712
1020,22,51968
1072,21,49408
1171,21,26880
1249,21,18688
1304,21,18432
1355,20,26880
1369,19,51456
1438,19,51456
1484,19,18688
1544,18,18688
1546,18,26880
1514,17,51456
1474,18,57600
1428,18,51456
1347,18,18688
1286,17,51200
1185,17,26624
1102,17,18432
1067,17,18432
1067,18,26624
1090,18,18432
1096,18,18432
1039,18,26624
1131,18,18432
1151,18,18688
1099,18,18688
1113,17,26880
1082,18,16648
1085,18,19712
1070,18,27904
1079,18,19720
1091,18,26880
....

It all looks fairly sane. I don't know what the values are, but the
first one is probably "depth in cm" or whatever. The third value looks
like its some 16-bit flags value (the numbers look more regular when
re-encoded as hex, and the low bits are all zeroes)

The important thing is that this actually looks quite parseable.

Gaah.

If that thing was available on Amazon, I'd have pressed the "Buy it"
button already. My wallet thanks Oceans for making it inconvenient to
buy ;)

Linus

[Paul Buxton]

Hmm, just wondering if the middle value is perhaps temperature in degrees C (if so I am jealous!)

Do we have the human readable version of that dive log?

As unless Oceans is willing to share their data format, I assume there is no way to decode the flags other by manually comparing it to a decoded log to determine what the flags mean.

If they really are going to update it to support air integration I might be tempted as that's something my very basic computer doesn't have. 

Paul

--
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/CAHk-%3DwishJGwhmQ38A3wZRe_rh0Tpq2Wdj4WFnmviQVdfcmezA%40mail.gmail.com.

[Seth Garrison]

Hi Paul,

I think you might be right on that. Here is a link to a screenshot of the data in their App. As of now i don't have any other way to parse the data into a readable form.

https://photos.app.goo.gl/D2ygYZ9VKiPYZWmw8

You can see in the photo that it does seem to be recording temp across the dive, and the numbers look like they match up, assuming the top part of the data is the most recent.

I could potentially share a lastpass link to my password with a few people, but there doesn't appear to be any way to dig into individual points on the graph of the dive profile.

One other thing of note - when you look at the graph of the dive, I believe that the blue dot's are "Pings" that I sent out.

If it is useful, I can pull all of this same data from my wife's computer, who was diving with me.

Seth 

To unsubscribe from this group and stop receiving emails from it, send an email to subsurface-divelog+unsub...@googlegroups.com.

[Paul Buxton]

I definitely don't want a password!

The data on the graph doesn't look very detailed which would make it quite tricky to try and correlate events in the log.

The buddy ping functionality is interesting, do incoming pings show up on your log?

I notice they have some form of cloud hosting, do they have a web-site you can visit and view your logs? 

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/CAHk-%3DwishJGwhmQ38A3wZRe_rh0Tpq2Wdj4WFnmviQVdfcmezA%40mail.gmail.com.

--

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/951f5048-6411-4265-9843-f059b4234679o%40googlegroups.com.

[Seth Garrison]

Hi Paul,

They don't currently have a website - just the app at the moment, but everything is hosted in the cloud, as logging in from another phone lets me see all the same data.

Incoming pings do show as well, i had just made a mistake in synchronizing with my wife's computer, so i wasn't receiving them.

I would agree that the graph is not too detailed, and it would be nice to have more. I made that suggestion to their development team when i saw it.

Thanks again for the help! looking forward to seeing this working with Subsurface soon!

Seth

To unsubscribe from this group and stop receiving emails from it, send an email to subsurface-divelog+unsub...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/subsurface-divelog/CAHk-%3DwishJGwhmQ38A3wZRe_rh0Tpq2Wdj4WFnmviQVdfcmezA%40mail.gmail.com.

--
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.

[Linus Torvalds]

Thanks to Dhaval Giani who sent me his S1 for testing, and thanks to
your BLE packet dump, I've got a downloader that mostly works.

It's not perfect, but the rough details are there.

See

https://github.com/subsurface/libdc/pull/20

for the code, and also some commentary.

For example, right now it downloads the dives in the order that the
Oceans S1 presents them in the dive list, which is "oldest dive
first". And that's the wrong order to download things in, because
after one successful download, the next time subsurface will see the
dive you already downloaded, and say "ok, stop here, we've already
seen this dive".

So then you need to do the "force download all dives", and manually
ignore the old ones etc, which is just crazy.

So the code is not final, but it's in good enough shape that if
somebody wants to play with it and see whether it works for them too,
that would probably be a good idea.

Right now I don't know how the dive modes work, so apnea diving etc
isn't recognized etc.

And I have no idea what the flags values are, so no warnings or other
events are imported yet.

So not all details are there, but dive profiles and temperatures do show.

Linus

[Linus Torvalds]

So I just pushed out my current libdivecomputer tree to the
'Subsurface-DS9' branch, which contains both the McLean Extreme
support and the new Oceans S1 support.

The McLean Extreme was supported in a separate branch until now, but
ended up merging Jef's version into our tree since he had done some
further cleanups on it.

Merging with Jef's upstream also got us a couple of OSTC fixes.

I have *not* made a pull request for subsurface yet: I have a trivial
patch to also recognize the Oceans S1 as a dive computer based on its
name, otherwise you currently have to check the "show all devices" in
the bluetooth scanning window to even see it.

I'll make an actual pull request for subsurface in a moment with the
libdivecomputer update.

Linus

[Seth Garrison]

Thanks Linus!

I'm out of town at the moment, but will try it out next week.

Please let me know if there is anything else I can do to be of help.

Seth

[klo...@gmail.com]

Linus and Paul,

I wanted to say thanks for your support getting this working. I've been able to use it a couple times now, and it works great.

Is there a place where i can support the Subsurface project? I haven't seen a donation link or anything in the past, but i'm wondering if i missed it.

If not, i'm open to other ways that i could support, but don't really know what is needed.

Thanks again!

Seth