Scubapro Galileo 2 (G2)

[CZS]

Not sure if you're aware, but Scubapro has just released a new dive computer, the Galileo 2 or G2. This computer features wireless bluetooth syncing through the LogTrak IOS/Android apps. Any idea how long it might take to get this computer syncing with Subsurface? I'd certainly offer any assistance I can in testing/troubleshooting, feel free to ask!

[Linus Torvalds]

On Jun 2, 2017 14:55, "CZS" <charles....@gmail.com> wrote:

Not sure if you're aware, but Scubapro has just released a new dive computer, the Galileo 2 or G2. This computer features wireless bluetooth syncing through the LogTrak IOS/Android apps. Any idea how long it might take to get this computer syncing with Subsurface? I'd certainly offer any assistance I can in testing/troubleshooting, feel free to ask!

I needed a new backup computer, and the G2 seemed to be a good choice. 

So I got one, as I have some diving coming up.

I only got it today, and have no dives on it yet, but can already verify that

 (a) libdivecomputer does not support it in any way or form

 (b) everything looks sane

but

 (c) no guarantees on how quickly this will be supported

It looks like it's a new sane version of the old Galileo, but it doesn't use irda (yay!) and instead shows up as a USB HID device. That's generally good, but it does mean that the existing libdivecomputer backend needs major work.

Also, the Bluetooth is BLE, which is again the right thing technically, but it means that our existing bluetooth infrastructure doesn't work at all, and it needs the low energy patches.

The good news on the BLE front is that unlike the Suunto EON Steel, it showed up on scanning on the first try, and it even enumerated all the BLE attributes correctly, so it seems to be a *normal* BLE device. That's going to help.

So we'll see. In a perfect world, I'll be able to play with this next week, and it uses the same protocol as the old Galileo's did, and it will just need some small updates for the HID protocol, and the USB side will 'just work'. Maybe. That's the good case, as you'd be able to download over a wire soon.

The BLE case it's likely further away, but there is *some* hope for that too.

Of course, things may not end up that simple, and maybe the protocol is really complicated and not at all the same as the old irda protocol was. So it might never be that perfect world, and it might be much worse, and I'll have to try to reverse-engineer the protocol. 

In that case, no promises.

      Linus

[CZS]

Linus,

Thanks for the reply, it's never a bad thing when the developer is diving the same computer ;)  Great to hear you're working towards a USB download first, as frankly I find the BLE support a mere luxury!

[Linus Torvalds]

On Wed, Jun 7, 2017 at 8:17 AM, CZS <charles....@gmail.com> wrote:
>
> Thanks for the reply, it's never a bad thing when the developer is diving
> the same computer ;) Great to hear you're working towards a USB download
> first, as frankly I find the BLE support a mere luxury!

So it turns out that the Scubapro G2 support looks really
straightforward, helped by the fact that the USB HID part of the thing
is very similar to what the Suunto EON Steel does (and I did the
reverse engineering for that one, and wrote the downloader), and the
actual commands and data parsing appears pretty much exactly the same
as the Galileo Sol.

So if you actually build your own, here's a patch to libdivecomputer
that should get things into testable territory.

I *have* actually tested it myself, but right now my only "dive" is me
dropping the dive computer into the neighbors pool for four minutes.
So my test data is very very limited.

I'll have more test data in a week, but for now this might be good
enough to do at least some initial trial downloads.

Linus

[CZS]

Linus,

This is fantastic news!  Thank you for the hard work.  

[Linus Torvalds]

On Fri, Jun 9, 2017 at 4:58 AM, William Perry <wmp...@gmail.com> wrote:
> Several folks from the shop are diving them in Cozumel this week. If you
> need tests run against a variety of dives (all recreational) I can borrow
> them and run whatever is necessary from mac or Linux.

The more testing, the merrier.

My pool dive only tested the very basics: it does have depth and
temperature data, but no events, no cylinder pressure, no heartrate
monitor etc.

That said, just the fact that all of that showed up on the very first
try (ok, blush, *second* try, because the first try I had entirely
missed filling in any model number at all) does imply that it very
much is the same protocol as the Galileo Sol, except just with a
different transport layer. So it probably gets most things right.

There might be real differences that show up much later - the Uwatec
Smart backend in libdivecomputer has a "GALILEO" vs "GALILEOTRIMIX"
model number and I might have expected the G2 to be the trimix version
because it supports it, but I'm not seeing any actual differences in
parsing between the two.

An maybe it has new events or warnings or whatever. And maybe I just
screwed up the downloading and it just happens to work for one dive
but will completely break immediately when there are more dives. But
on the whole I think that it should JustWork(tm).

But testing it is the only way.

I don't think that I'm going to actually push out my patch to the
official Subsurface libdivecomputer branch until it gets some more
testing than that one trivial pool-dive-on-a-string, so you do have to
build your own for now for testing.

After next week, I should have much more confidence whether it
actually *really* works, and I'll push it out and maybe we'll have
daily builds that just work with the Scubapro G2 out of the box. But
in the meantime it's a "please test if you can".

Linus

[Stuart Vernon]

You're probably already aware of this, but it is my understanding that there are 3 different kinds of SP AI transmitters and the G2 is backwards compatible with all of them. So, the data logged might vary depending on which transmitter type it's talking to.

Just FYI, just in case.

--
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 post to this group, send email to subsurfac...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/subsurface-divelog/CA%2B55aFzkVeqWNVG%3DBXUvAD%3Daka8c%3Domg%3D-TH_8F3xQgkiDjBWg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Linus Torvalds]

On Fri, Jun 9, 2017 at 9:43 AM, Stuart Vernon <stu...@force2.net> wrote:
> You're probably already aware of this, but it is my understanding that there are 3 different kinds of SP AI transmitters and the G2 is backwards compatible with all of them. So, the data logged might vary depending on which transmitter type it's talking to.

I wasn't aware of the different versions (I've never had an
Uwatec/Scubapro dive computer before, I've seen them around but didn't
like the screen very much), but I doubt the transmitter protocol will
show up as a difference for the download.

But who knows. I will be trying *one* transmitter next week, since I
got the package (which means that I'll try the heartrate monitor on at
least one dive too).

There definitely are differences between the new G2 and the old
Galileo Sol. If nothing else, there are more levels of conservatism in
the microbubble thing, but it also supports more pressure
transmitters, and it supports a sidemount mode where it tracks two gas
pressures at once.

So all of those things imply *some* download differences, I suspect.
It also has more memory etc, and hopefully things like battery level
read-outs etc.

In other words - even if the current patch works perfectly, there are
almost certainly things that could be improved. They are hopefully
corner cases that very few people will hit in practice (and that
obviously also means that they might take a long time to show up and
be fixed/implemented).

So far my initial impressions of the G2 are quite positive. I can
reboot the thing by putting a jpeg picture on it and trying to show
it, so I already found a bug (*), but it seems like quite the
reasonable dive computer.

Of course, maybe it turns out to not dive well. The Aeris/Oceanic
300CS (aka "shaving mirror") was a huge disappointment despite looking
reasonable on paper. I have higher hopes for the G2.

Linus

(*) Side note: if anybody has connections with Scubapro/Uwatec, let me
know. I tried to make a bug report on the scubapro support page, but I
doubt that one gets to any actual developers.

[CZS]

Regarding the jpeg bug, be aware there's already been a FW update released for the G2 (available here https://www.scubapro.com/media/714047/g2_fw_v11.zip).  Since there's no release notes, I have no idea if the issue you're experiencing is addressed, but it's worth a shot.

[Linus Torvalds]

Yup, I already applied the 1.1 FW update yesterday and retested. Didn't change the rebooting behavior.

And it totally corrupts the time etc too when it happens - probably some major memory overwrite bug that may depend on the details of the picture encoding of course (so might not happen with some pictures)

So *don't* try that thing while on a dive trip, it might reset your deco state etc too.

    Linus

[Stuart Vernon]

On an semi-related note: I'm just curious what factors caused you to buy a G2 over a Perdix AI.

Also, you probably already know this, too, but the G2 algorithm is different than the old G. The new one uses ZH-L16 ADT, versus the older model's ZH-L8 ADT. I don't think that would make a difference in the data download - other than it may change a metadata field in the downloaded data.

I am curious to learn how the G2 on conservatism L0 compares to other computers, like the Oceanic computers running DSAT and tech computers running ZHL-16B (or C) using Gradient Factors. The OG (LOL) has the reputation of being pretty middle of the road on NDLs compared to other recreational computers. I wonder if the G2 will be the same.

-----Original Message-----
From: linu...@gmail.com [mailto:linu...@gmail.com] On Behalf Of Linus Torvalds
Sent: Friday, June 09, 2017 1:17 PM
To: subsurfac...@googlegroups.com
Subject: Re: Scubapro Galileo 2 (G2)

--
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 post to this group, send email to subsurfac...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/subsurface-divelog/CA%2B55aFxB3XDyxnSa2bt%3D5q5PL7HhSAT6BmvfC8_uowrW-tFiXA%40mail.gmail.com.

[Linus Torvalds]

On Fri, Jun 9, 2017 at 11:13 AM, Stuart Vernon <stu...@force2.net> wrote:
> On an semi-related note: I'm just curious what factors caused you to buy a G2 over a Perdix AI.

So a few reasons.

First off, this is actually a backup computer for me. I'm very happy
with the Suunto EON Steel - I've had ~200 dives with it, and it has
never had any issues. So I just wanted a different computer for
back-up that I could also let my daughter use when she dives (very
seldom, but she's certified).

So I wanted something reasonably usable - for me that means color
screen and a three-button interface with menus.

The first and trivial advantage of the G2 was simply that we didn't
already have support for it, and people had already asked. So when my
local dive-shop sent an email about the new dive computer the day
after the Scubapro G2 was asked about, I was like "I need a backup
computer, I'll just go to the shop and look at it".

And I liked what I saw.

I like the Perdix Ai in many ways too. It does everything I want. But
it does have a few annoyances that for me make it less than ideal.

For example, I *detest* the nasty shearwater buttons. Yes, it has a
menu interface, but with only two buttons the difference in navigation
is quite noticeable. And I don't know why, but I have trouble with
those damn piezo-electric nasty things. It must be something I do
wrong, because I've seen Dirk work the buttons no problem, but to me
they are just unresponsive and annoying. I want a real button, dammit.

I also don't like changing batteries. I think it's stupid. I realize
that I'm in a minority, with a lot of people not liking the integrated
rechargable thing, but I destroyed my last backup computer (a Suunto
Vyper Air that I've used for years) by screwing up the battery change
and flooding it.

So I want a rechargeable dive computer that lasts for 10+ hours under
water. I've been very happy with the EON Steel, which is about 25+h
fully charged, which means that I *might* need to charge it once
during a dive trip, but it's basically a non-issue. I will have a
laptop with a USB port with me. I don't want to charge it every day,
but "once per trip"? Not a problem at all.

With batteries, either you have to have the right batteries, or you
end up using rechargeable batteries anyway, and honestly, if you tell
me that you haven't met people who have had issue with just the right
battery type, I suspect you just haven't seen enough of them. There
are whole discussion board threads about "which battery to use" to
make things reliable.

The Scubapro G2 claims 50h for a full battery. Even if they are off by
a huge amount (I tend to set my screen to a high brightness, for
example, so I'd expect to not get nearly the max amount), it sounds
plenty good enough. And the integrated battery compartment actually
looks like it is easily seviceable, so even if the battery ends up
going bad after a few years, it looks like a good design.

> Also, you probably already know this, too, but the G2 algorithm is different than the old G. The new one uses ZH-L16 ADT, versus the older model's ZH-L8 ADT. I don't think that would make a difference in the data download - other than it may change a metadata field in the downloaded data.

Right. I did notice that the old ones used a 8-tissue version. Which I
consider crazy bad these days, but the design really was old. IrDA?
What century are we living in again? So I was never all that impressed
with the previous generation of Galileo - it just fell flat in so many
different ways, including being clunky and big for what you got.

The G2 does regular Bühlmann, although you can do the microbubbles if
you want to. I expect I will be diving at L0, so that part doesn't
matter to me.

And yes, I'd like to download the deco data (although things like
battery levels and time setting are actually more important to me). I
don't think libdivecomputer does any of that, so the fact that the
deco data will inevitably have a different format won't matter to the
existing downloader.

> I am curious to learn how the G2 on conservatism L0 compares to other computers, like the Oceanic computers running DSAT and tech computers running ZHL-16B (or C) using Gradient Factors. The OG (LOL) has the reputation of being pretty middle of the road on NDLs compared to other recreational computers. I wonder if the G2 will be the same.

I will definitely be comparing NDL times etc.

I have my Suunto set at P-2, because Suunto tends to be so
conservative (on the Vyper Air, I used "RGBM50", which seemed to be
effectively the same, and the HelO2 - being for trimix and deco divers
- was also aggressive by default).

So that's what I'll compare against (together with whatever Dirk will
be diving - probably he'll have a Shearwater as a backup).

Linus

[Stuart Vernon]

Interesting take. I played with a G2 in the shop last Saturday. I thought the biggest plus (to me) for the G2 over the Perdix was also the buttons. The Perdix buttons are hard to find by feel. Especially with gloves on. And they are easy to press by accident (e.g. contact with a dry glove ring). I know 2 people IRL that have personally experienced an accidental, inadvertent gas switch on their Petrel/Perdix. I like a 3 or 4 button design. I like that the G2 buttons are on top (so, not easily pressed by accident) and they definitely felt "nice" to press.

I would not buy a G2 for myself, but that's because of 2 things: No trimix support (yet, anyway). And the proprietary algorithm. I have a Seabear H3 and it has been and still is awesome. I really wish ScubaPro had not killed the H3 after they bought it from SeaBear. An H3 with AI would be just about my ideal dive computer. Oh, well. As it is, I have the H3 and a Perdix AI and together they are pretty darn ideal.

-----Original Message-----
From: linu...@gmail.com [mailto:linu...@gmail.com] On Behalf Of Linus Torvalds
Sent: Friday, June 09, 2017 3:45 PM
To: subsurfac...@googlegroups.com
Subject: Re: Scubapro Galileo 2 (G2)

--
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 post to this group, send email to subsurfac...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/subsurface-divelog/CA%2B55aFwWcxxufRD7c53Ow7sA9%3Dn4QssOELQy7NdZ_iQCiVW%3DKQ%40mail.gmail.com.

[CZS]

Just an FYI, but the G2 definitely does Trimix.

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

[Linus Torvalds]

On Jun 9, 2017 12:56, "Stuart Vernon" <stu...@force2.net> wrote:

I would not buy a G2 for myself, but that's because of 2 things: No trimix support (yet, anyway).

I'm pretty sure it does trimix.

You just have to enable it on the settings before it shows up.  Same with CCR and some other modes.

So by default you only get what looks like nitrox to avoid confusing people who don't have the certs, but it can do more.

     Linus

[Stuart Vernon]

I went through the Settings menu and didn’t see a way to turn on Trimix or set the He part of a mix. But, I certainly could have missed it in the Settings. I was really only looking for a way to set FHe. I was not specifically looking for a setting to enable Trimix.

 

I said something about it to the dive shop owner who was letting me look at it (and who is a tech diver himself, I believe) and he said they will be releasing updated firmware with Trimix support later. But, he had barely looked at the G2 himself, yet, so his statement may have been based on believing it will support Trimix and my statement that it appeared not to.

 

If it does already support Trimix, then it would be only the lack of Gradient Factor support that would keep me away from it. Well, that and the price (being more expensive here than a Perdix AI).

--

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 post to this group, send email to subsurfac...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/subsurface-divelog/CA%2B55aFzjXYSfzNDtkr56%3D5UYmK221PkYr%2ByYNLwmCW9izBKd5A%40mail.gmail.com.

[Linus Torvalds]

On Jun 9, 2017 13:55, "Stuart Vernon" <stu...@force2.net> wrote:

I went through the Settings menu and didn’t see a way to turn on Trimix or set the He part of a mix. But, I certainly could have missed it in the Settings. I was really only looking for a way to set FHe. I was not specifically looking for a setting to enable Trimix

There is a separate "feature enable" screen in the somewhere (under "Other settings"), for enabling multiple cylinder support, trimix mount, rebreather and some other special modes.

But I think it's literally just "enable this feature" not some kind of "pay extra to get a feature pack file or magic support key that you can download/enter".

Note: I've obviously not actually used it, so I'm just going by what I've seen in the menus and manual.

To confuse things further, some of the things have odd names. I'm used to enabling "deep stops" on Suunto, for example. The Scubapro G2 calls that some of random four-letter thing. PMDS or something random like that. Same goes for the multi-cylinder support, it shows up in the menu as some random combination of letters.

     Linus

[A2]

>I'm used to enabling "deep stops" on Suunto, for example

Deep stops are probably a bad idea: https://www.youtube.com/watch?v=UY61E49lyos

AA.

[Stuart Vernon]

Yeah, PDIS (Profile Dependent Intermediate Stops) is your Deep Stops option (which I would totally avoid).

 

PMG (Predictive Multi Gas) or something like that, IIRC, is your multi-cylinder support.

 

It definitely seems like A Good Thing that they have it come out of the box with the options all set to make it simple and easy for normal recreational (i.e. single tank) divers.

 

Too bad I couldn’t figure out how to get from the Settings menu back to the Main menu in order to check out the other options. Apparently (I’m now told), a long-press on one of the buttons would have gotten me back. But, there was nothing obvious or intuitive about that and I did not figure it out when I was looking at it. I don’t know why they couldn’t just put a “Exit” choice as the last thing in the Settings menu.

 

From: linu...@gmail.com [mailto:linu...@gmail.com] On Behalf Of Linus Torvalds
Sent: Friday, June 09, 2017 5:18 PM
To: subsurfac...@googlegroups.com
Subject: RE: Scubapro Galileo 2 (G2)

 

 

 

On Jun 9, 2017 13:55, "Stuart Vernon" <stu...@force2.net> wrote:

--

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 post to this group, send email to subsurfac...@googlegroups.com.

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

[Linus Torvalds]

On Jun 9, 2017 14:29, "Stuart Vernon" <stu...@force2.net> wrote:

Too bad I couldn’t figure out how to get from the Settings menu back to the Main menu in order to check out the other options. Apparently (I’m now told), a long-press on one of the buttons would have gotten me back. But, there was nothing obvious or intuitive about that and I did not figure it out when I was looking at it. I don’t know why they couldn’t just put a “Exit” choice as the last thing in the Settings menu.

I guess I didn't react to that, because the EON Steel does the same: the "select" button enters a menu item, and long-pressing it exits.

You really want four buttons: up, down, enter, exit. And no, having a menu exit field generally doesn't help, because when you are actually entering data you still want that exit/cancel thing (when the three buttons are up/down/done). You could always have a "confirm/discard" phase, but that tends to irritate people too.

Three buttons with "long press for cancel" works reasonably well once you get used to it. So I'm personally ok with three buttons, I dislike the two or one-button interfaces intensely.

      Linus

[CZS]

Apologies if I'm getting too far off subject here, but I would point out that Scubapro implements it's PDIS/deep stops on both no stop dives, as well as decompression dives.  The latest research (including the video referenced) seems to indicate that while deep stops are generally counterproductive on a deco dive, they ARE somewhat beneficial on a no stop dive.  In my mind, that's why I leave the PDIS feature to "ON"... It's easy enough to observe a stop on a no stop dive, while ignoring it on a deco dive.  

[Dirk Hohndel]

Linus pushed out some initial patches to support the G2 and I made new test binaries available at

http://subsurface-divelog.org/downloads/test/

We'd love to hear how this works out for you.

Thanks

/D

[CZS]

Fantastic!  As soon as I have some dives on the G2, I'll give it a try.  Thanks!

[Martin Baumgartner]

Hi Dirk,

did a small test download of my first dive with my G2.

I could select the G2, but the download throws an error: "Fehler beim Importieren der Tauchgangsdaten".

Best regards,

Martin

[Linus Torvalds]

On Wed, Jun 14, 2017 at 3:21 AM, Martin Baumgartner
<baumga...@gmail.com> wrote:
>
> did a small test download of my first dive with my G2.
> I could select the G2, but the download throws an error: "Fehler beim
> Importieren der Tauchgangsdaten".

Ok, that's definitely an import error (the device has successfully opened etc).

I'll have a couple of dives myself in a few hours, so hopefully I can
figure it out. And if not, I'll at least add more debugging code to
get more data.

Thanks,
Linus

[Ryan January]

I can confirm this new build is working on the 1.0 firmware with the new style transponders (which include the green/yellow/red status indicators)

The only downside is that the particular dive I downloaded was a sidemount dive, and it only appears to be tracking one tank in the subsurface interface.  I'm not sure if that's an issue within my configuration or not.

[Linus Torvalds]

On Wed, Jun 14, 2017 at 6:47 AM, Ryan January <rjan...@gmail.com> wrote:
> I can confirm this new build is working on the 1.0 firmware with the new
> style transponders (which include the green/yellow/red status indicators)
>
> The only downside is that the particular dive I downloaded was a sidemount
> dive, and it only appears to be tracking one tank in the subsurface
> interface. I'm not sure if that's an issue within my configuration or not.

Oh, the sidemount feature is new to the G2, I think, and not something
we support. In fact, right now we don't even support showing that
information properly.

Does it show up as a second cylinder (ie do you see beginnning/ending
pressures at least, even if you don't see the pressure graph?)

It may be that all the data is there, it's just that subsurface
currently only thinks of cylinders as a "one at a time" thing.

I may ask you for more data later, just to see what the G2 does with
two pressure sensors, and how we'd work with it.

Linus

[Linus Torvalds]

On Jun 14, 2017 6:50 AM, "Linus Torvalds" <torv...@linux-foundation.org> wrote:

Oh, the sidemount feature is new to the G2, I think, and not something
we support. In fact, right now we don't even support showing that
information properly.

Oh, and I'm wondering why it doesn't work at all for Martin.

What operating system are you guys on, and do you have any other special issues? If anything, if have expected trouble with the sidemount case, but that is the one that works..

Martin, do you have anything special on your configuration?

     Linus

[Ryan January]

Thank you Linus.  This particular test was on MacOS 10.12.5.  I can confirm the sidemount feature is new to the G2 (which is one reason I purchased it).  This evening I also upgraded to G2 firmware version 1.1 and retested with similar results.

I mislead you earlier.  Subsurface appears to be ignoring the dives where sidemount was enabled in the dive settings menu.  No errors were indicated in the UI while polling the dive computer or while downloading dives. Screenshots are attached.  

All testing has been done with the sidemount feature enabled in the "Feature Upgrade" menu.  The missing test dives on the 27th are those where sidemount was enabled.

I did confirm the same dives were successfully downloaded in ScubaPro's LogTrak software and that start and end pressures exist for both tanks exist.  

I'm happy to provide whatever logs/data/dumps you may need.

[Linus Torvalds]

On Wed, Jun 14, 2017 at 12:48 PM, Ryan January <rjan...@gmail.com> wrote:
>
> I mislead you earlier. Subsurface appears to be ignoring the dives where
> sidemount was enabled in the dive settings menu. No errors were indicated
> in the UI while polling the dive computer or while downloading dives.
> Screenshots are attached.

Ok, fair enough. We clearly have a problem with silently just ignoring
dives that have some issue with them.

I just downloaded the three dives I had today, and sadly (or not) I
see no problems at all.They all downloaded with the right profiles and
for the last one I even had the heartbeat sensor on just to test, and
we even got that right (but subsurface doesn't show it, so you can't
tell it's there unless you look at the save file).

I'll have to add some debug option to figure out what is wrong. The
"doesn't work with sidemount" is obviously one pretty big wrong thing,
but I'll still need to add debug code for it, because I only have one
sensor, so I can't try to fake some sidemount thing with two
cylinders.

But I'll have to sleep on this first, because I'm too tired to write
code right now.

Linus

[Tomaz Canabrava]

On Wed, Jun 14, 2017 at 12:28 PM, Linus Torvalds <torv...@linux-foundation.org> wrote:

On Wed, Jun 14, 2017 at 12:48 PM, Ryan January <rjan...@gmail.com> wrote:
>
> I mislead you earlier.  Subsurface appears to be ignoring the dives where
> sidemount was enabled in the dive settings menu.  No errors were indicated
> in the UI while polling the dive computer or while downloading dives.
> Screenshots are attached.

Ok, fair enough. We clearly have a problem with silently just ignoring
dives that have some issue with them.

I just downloaded the three dives I had today, and sadly (or not) I
see no problems at all.They all downloaded with the right profiles and
for the last one I even had the heartbeat sensor on just to test, and
we even got that right (but subsurface doesn't show it, so you can't
tell it's there unless you look at the save file).

We should have a heartbeat graph actually.
 

I'll have to add some debug option to figure out what is wrong. The
"doesn't work with sidemount" is obviously one pretty big wrong thing,
but I'll still need to add debug code for it, because I only have one
sensor, so I can't try to fake some sidemount thing with two
cylinders.

But I'll have to sleep on this first, because I'm too tired to write
code right now.

                 Linus

--
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.
To post to this group, send email to subsurface-divelog@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/subsurface-divelog/CA%2B55aFy30n8zKtyB%3DtUhG7MJz0y0Uidh%3DaE-00RsnUVbJbw-Xw%40mail.gmail.com.

[Dirk Hohndel]

On Wed, Jun 14, 2017 at 07:28:53PM +0900, Linus Torvalds wrote:
> On Wed, Jun 14, 2017 at 12:48 PM, Ryan January <rjan...@gmail.com> wrote:
> >
> > I mislead you earlier. Subsurface appears to be ignoring the dives where
> > sidemount was enabled in the dive settings menu. No errors were indicated
> > in the UI while polling the dive computer or while downloading dives.
> > Screenshots are attached.
>
> Ok, fair enough. We clearly have a problem with silently just ignoring
> dives that have some issue with them.

True. The question is where do we error out? When downloading? When
parsing?

> I just downloaded the three dives I had today, and sadly (or not) I
> see no problems at all.They all downloaded with the right profiles and
> for the last one I even had the heartbeat sensor on just to test, and
> we even got that right (but subsurface doesn't show it, so you can't
> tell it's there unless you look at the save file).

You should just enable the heartbeat graph in the toolbar and it should be
displayed... unless there is another bug somewhere.

> I'll have to add some debug option to figure out what is wrong. The
> "doesn't work with sidemount" is obviously one pretty big wrong thing,
> but I'll still need to add debug code for it, because I only have one
> sensor, so I can't try to fake some sidemount thing with two
> cylinders.
>
> But I'll have to sleep on this first, because I'm too tired to write
> code right now.

Well, you COULD write code. You just might not like reading it tomorrow
:-)

/D

[Jef Driesen]

On 2017-06-09 07:28, Linus Torvalds wrote:
> diff --git a/examples/common.c b/examples/common.c
> index 3c4561b..5ebdd77 100644
> --- a/examples/common.c
> +++ b/examples/common.c
> @@ -54,6 +54,7 @@ static const backend_table_t g_backends[] = {
> {"smart", DC_FAMILY_UWATEC_SMART, 0x10},
> + {"g2", DC_FAMILY_UWATEC_SMART, 0x10},
> {"meridian", DC_FAMILY_UWATEC_MERIDIAN, 0x20},

I think you meant DC_FAMILY_SCUBAPRO_G2 here.

> diff --git a/include/libdivecomputer/common.h
> b/include/libdivecomputer/common.h
> index 67398d1..fdaaa1b 100644
> --- a/include/libdivecomputer/common.h
> +++ b/include/libdivecomputer/common.h
> @@ -59,6 +59,8 @@ typedef enum dc_family_t {
> DC_FAMILY_UWATEC_MEMOMOUSE,
> DC_FAMILY_UWATEC_SMART,
> DC_FAMILY_UWATEC_MERIDIAN,
> + /* We'll enumerate the Scubapro G2 under Uwatec */
> + DC_FAMILY_SCUBAPRO_G2,

For consistency with the other uwatec/scubapro backends, replace
DC_FAMILY_SCUBAPRO_G2 with DC_FAMILY_UWATEC_G2. Same remark for the
filenames. For end-users the fact that the internal name is uwatec
instead of scubapro doesn't really matter, because they will only see
the name "Scubapro G2".

BTW, we now have 3 backends (smart, meridian and g2) using the exact
same communication protocol, but with a different transport (irda,
usb-serial and usbhid). I wonder if we can merge this back into a single
backend some day? Because once the I/O refactoring lands, the difference
between the transports will disappear and those backends will even look
more similar.

The main difference is the transfer function. For the smart it's a plain
IrDA read/write, for the meridian there is some additional framing
added, and for the G2 there is the USB HID packet stuff.

> diff --git a/src/parser.c b/src/parser.c
> index ebbc6a6..fea1454 100644
> --- a/src/parser.c
> +++ b/src/parser.c
> @@ -96,6 +96,9 @@ dc_parser_new_internal (dc_parser_t **out,
> dc_context_t *context, dc_family_t fa
> case DC_FAMILY_UWATEC_MEMOMOUSE:
> rc = uwatec_memomouse_parser_create (&parser, context, devtime,
> systime);
> break;
> + case DC_FAMILY_SCUBAPRO_G2:
> + rc = uwatec_smart_parser_create (&parser, context, 0x11, devtime,
> systime);
> + break;
> case DC_FAMILY_UWATEC_SMART:
> case DC_FAMILY_UWATEC_MERIDIAN:
> rc = uwatec_smart_parser_create (&parser, context, model, devtime,
> systime);

Is there a reason why you have hardcoded the model number to 0x11? Does
the data contain a different model number? Because in that case we
should update the parser to support the new model number.

> +typedef struct scubapro_g2_device_t {
> + ...
> + unsigned int address;
> + ...
> +} scubapro_g2_device_t;

The address member is a left-over from the irda code and can be removed.

> +#define PACKET_SIZE 64
> +static int receive_data(scubapro_g2_device_t *g2, unsigned char
> *buffer, int size)
> +{
> + while (size) {
> + unsigned char buf[PACKET_SIZE];
> + size_t transferred = 0;
> + dc_status_t rc;
> + int len;
> +
> + rc = dc_usbhid_read(g2->usbhid, buf, PACKET_SIZE, &transferred);
> + if (rc != DC_STATUS_SUCCESS) {
> + ERROR(g2->base.context, "read interrupt transfer failed");
> + return -1;
> + }
> + if (transferred != PACKET_SIZE) {
> + ERROR(g2->base.context, "incomplete read interrupt transfer (got
> %zu, expected %d)", transferred, PACKET_SIZE);
> + return -1;
> + }
> + len = buf[0];
> + if (len >= PACKET_SIZE) {
> + ERROR(g2->base.context, "read interrupt transfer returns impossible
> packet size (%d)", len);
> + return -1;
> + }
> + HEXDUMP (g2->base.context, DC_LOGLEVEL_DEBUG, "rcv", buf+1, len);
> + if (len > size) {
> + ERROR(g2->base.context, "receive result buffer too small -
> truncating");
> + len = size;
> + }
> + memcpy(buffer, buf+1, len);
> + size -= len;
> + buffer += len;
> + }
> + return 0;
> +}

There are a two issues with this code:

The error code from dc_usbhid_read is dropped and replaced with a
generic -1, which is translated again to DC_STATUS_IO in the caller. It
would be much better to pass the actual error code. The difference
between for example TIMEOUT, IO and PROTOCOL errors is valuable info.
(Maybe not for the end-user, but certainly for the developer debugging
the problem.) Those other -1 should be translated into
DC_STATUS_PROTOCOL.

Truncating the data if the buffer is too small is a bad idea because
you'll return corrupt data. Just bail out with error DC_STATUS_PROTOCOL.
If this ever happens, then it's most likely caused by a bug in the code
or a change in the communication protocol. In both cases the code should
be fixed.

> +dc_status_t
> +scubapro_g2_device_open(dc_device_t **out, dc_context_t *context)
> +{
> + dc_status_t status = DC_STATUS_SUCCESS;
> + scubapro_g2_device_t *device = NULL;
> +
> + ...
> +
> + // Open the irda socket.
> + status = dc_usbhid_open(&device->usbhid, context, 0x2e6c, 0x3201);
> + if (status != DC_STATUS_SUCCESS) {
> + ERROR (context, "Failed to open USB device");
> + goto error_free;
> + }
> +
> + *out = (dc_device_t*) device;
> +
> + return DC_STATUS_SUCCESS;
> +
> +error_free:
> + dc_device_deallocate ((dc_device_t *) device);
> + return status;
> +}

Is the handshaking no longer necessary for the G2? I've always wondered
why it's there for the smart and meridian because it doesn't really
return any useful info. It's certainly possible that it can be omitted,
but I never really tried that. So I'm just curious why you left it out.

> +static dc_status_t
> +scubapro_g2_device_dump (dc_device_t *abstract, dc_buffer_t *buffer)
> +{
> + scubapro_g2_device_t *device = (scubapro_g2_device_t*) abstract;
> + dc_status_t rc = DC_STATUS_SUCCESS;
> +
> + ...
> +
> + if (receive_data(device, data, length)) {
> + ERROR (abstract->context, "Received an unexpected size.");
> + return DC_STATUS_IO;
> + }
> +
> + ...
> +
> + return DC_STATUS_SUCCESS;
> +}

This will need some improvements to report more fine-grained progress
events.

The rest looks good to me. Will you send an updated patch, or do I make
the changes myself?

Jef

[Jef Driesen]

On 2017-06-14 05:48, Ryan January wrote:
> I'm happy to provide whatever logs/data/dumps you may need.

Having more data is always good for testing!

To download a memory dump, just enable the libdivecomputer logfile and
dumpfile checkboxes in the subsurface download dialog.

Jef

[Ryan January]

I did just attempt to download a dump and log, however I'm not getting the expected output files.  Additionally, my dives are being downloaded and added to the dive list which is contrary to what subsurface says should occur.  I believe this is correct, however can you confirm these settings are what's required to download a dump file?

I'm very comfortable on the CLI if there's an additional way to bypass subsurface and reattempt through libdivecomputer.  My only issue with doing so is that I'm not seeing a device exposed in /dev that matches what subsurface shows (/dev/tty.SLAB_USBtoUART)  Is this due to it being considered a HID? 

Thanks for your assistance,

Ryan

[Linus Torvalds]

On Wed, Jun 14, 2017 at 7:32 PM, Tomaz Canabrava <tcana...@kde.org> wrote:
>
> We should have a heartbeat graph actually.

Can confirm, and it works.

I just expected the heartbeat number to show up in the "Information"
window, and without the graph enabled (which I didn't even think
about) it doesn't show up in there either.

Linus

[Ryan January]

I can additionally confirm the heart rate monitor works on the original Galileo Sol if anyone's curious.  I've been using it for the past year without incident.

[Linus Torvalds]

() (),

On Wed, Jun 14, 2017 at 8:14 PM, Jef Driesen <j...@libdivecomputer.org> wrote:
> On 2017-06-09 07:28, Linus Torvalds wrote:
>>
>> diff --git a/examples/common.c b/examples/common.c
>> index 3c4561b..5ebdd77 100644
>> --- a/examples/common.c
>> +++ b/examples/common.c
>> @@ -54,6 +54,7 @@ static const backend_table_t g_backends[] = {
>> {"smart", DC_FAMILY_UWATEC_SMART, 0x10},
>> + {"g2", DC_FAMILY_UWATEC_SMART, 0x10},
>> {"meridian", DC_FAMILY_UWATEC_MERIDIAN, 0x20},
>
>
> I think you meant DC_FAMILY_SCUBAPRO_G2 here.

I actually did that one on purpose, since it talked about "backends",
and I think this just does the second stage parsing thing, which is
all UWATEC smart, no?

But it shouldn't matter, and I guess if there does end up being any
differences, it's better to call it the SCUBAPRO_G2.

> For consistency with the other uwatec/scubapro backends, replace
> DC_FAMILY_SCUBAPRO_G2 with DC_FAMILY_UWATEC_G2. Same remark for the
> filenames.

Please, let's absolutely *not* do that.

This thing is known as the "Scubapro G2". As far as I know, it's not
sold anywhere as "Uwatec". Uwtec isn't mentioned in any place that I
can find, so it's purely an internal detail, and calling it a
UWATEC_G2 is actively misleading.

> For end-users the fact that the internal name is uwatec instead
> of scubapro doesn't really matter, because they will only see the name
> "Scubapro G2".

This isn't aboue end-users. This is about developers. And for any
*developers*, calling it "UWATEC_G2" is actively wrong.

There is no such thing afaik. I tried to google it in case it's
perhaps sold as something else in Europe, but that doesn't seem to be
the case.

There's just a Scubapro G2.

> BTW, we now have 3 backends (smart, meridian and g2) using the exact same
> communication protocol, but with a different transport (irda, usb-serial and
> usbhid). I wonder if we can merge this back into a single backend some day?
> Because once the I/O refactoring lands, the difference between the
> transports will disappear and those backends will even look more similar.

I really don't think the IO refactoring will work.

The packetization rules are dive-computer-specific. There is no
generic "USB HID" transport, for example: the actual HID packets have
different rules depending on the dive computer.

For example, the EON Steel always sends full 64-byte HID packets, so
the first byte (the packet payload size) is 0x3f (63). But then the
Suunto EON Steel does its *own* packetization within that, and the
second byte is the length of the actual payload data as far as the EON
Steel is concerned.

And the Scubapro G2 also uses USB HID, but it doesn't have that
two-level packet size thing, so for the G2, it just uses the HID size
directly for the payload.

So you really cannot do some generic transport, because the actual
rules of the transport will depend on the low-level dive computer
anyway. The best you can do is to just have generic helper routines
for one particular transport, the way libdc already does the USB HID
helpers. But each dive computer really *does* need to then look at the
USB HID packets independently.

> The main difference is the transfer function. For the smart it's a plain
> IrDA read/write, for the meridian there is some additional framing added,
> and for the G2 there is the USB HID packet stuff.

Yes, the transfer function is the only thing different, but they are
different in ways that are also different between different dive
computer vendors (see above).

So you can do a "transport layer for smart/meridian/G2" abstraction,
but you can *not* do a generic USBHID transport layer one.

At which point almost all of the point of the transport layer goes
away, since it just ends up being internal to a particular dive
computer family anyway, not truly generic.

>> + case DC_FAMILY_SCUBAPRO_G2:
>> + rc = uwatec_smart_parser_create (&parser, context, 0x11,
>> devtime, systime);
>

> Is there a reason why you have hardcoded the model number to 0x11? Does the
> data contain a different model number? Because in that case we should update
> the parser to support the new model number.

I wasn't sure which number if would be, so I just picked the one that
matched the galileo, but I thoyght t might change. And then it just
worked, and I left it as that.

Also, even the galileo *itself* doesn't use the GALILEO define in the
descriptor tables. See src/descriptor.c, it's all 0x11 there.In fact,
the whole define only exists within the uwatec_smart_parser.c file, so
I'm not sure what you really expect people to do.

>> +typedef struct scubapro_g2_device_t {
>> + ...
>> + unsigned int address;
>> + ...
>> +} scubapro_g2_device_t;
>
> The address member is a left-over from the irda code and can be removed.

Will do.

> There are a two issues with this code:

I'm going to ignore your nitpicking as long as you ignore my sane
string interfaecs.

Jef, the reason I no longer send you patches, and just push stuff
directly to the subsurface libdc repository is that I can't work with
you.

I'll take your input, but I'm done fighting your oddities. Integrate
*our* code that actually matters, and I can work with you. In the
meantime, I'm not interested in nitpicking details that don't matter
one whit.

> Is the handshaking no longer necessary for the G2?

It didn't seem to make any difference for me, so I removed it.

But since some people seem to have download issues, I'm actually
considering putting it back. My download trace from the Scubapro
LogTRAK does have

out: > 01 1b
in : < 01 01

out: > 05 1c10270000
in : < 01 01

as the first packet sequence (that is just a random cleaned-up packet
thing: the numbers are packet length followed by packet data). Ad that
matches the handshake sequence. So LogTRAK does do that handshake, but
the G2 didn't seem to care.

I suspect the handshake is more important over some random serial
protocol that doesn't have device ID's etc.

But as mentioned, because people clearly have some issues that I can't
reproduce, I'm thinking of just doing that handshake anyway, just
because it also doesn't seem to hurt.

> I've always wondered why
> it's there for the smart and meridian because it doesn't really return any
> useful info. It's certainly possible that it can be omitted, but I never
> really tried that. So I'm just curious why you left it out.

I really just tried to minimize the data sent/receviced, but I don't
have any other good reason for it.

> This will need some improvements to report more fine-grained progress
> events.

The thing is, it already reports *better* progress events for errors
thanks to the actual error handling in receive_data(), which gives
descriptive error STRINGS for what went wrong, and that subsurface can
actually show to users in sanen ways (in the error status at the
bottom).

In contrast, the random crazy libdivecomputer error codes are
completely useless.

This continues to be a contention point for me: your insistence on
those useless random integer codes, when giving useful human-readable
data with actual error descriptions and details on *what* went wrong
is so much superior.

So all libdivecomputer really needs to return is "an error happened".
The error *description* is done by the dc_context_log() interface that
is able to give real information.

This is also why we use - and *NEED* - that string interface for other
random dive computer data. There is absolutely no sane way to return
info like "transmitter battery level at end of dive" with random
codes. Or serial numbers, or deco algorithms. They are all *strings*.

So the scubapro G2 downloader returns error *strings* that can be
displayed. Of course, you have ended up using macros that often get
disabled, so if ENABLE_LOGGING isn't on, nothing gets logged. I'm
wondering if that's in fact part of the problem with the current lack
of any error output for people.

Linus

[Linus Torvalds]

On Thu, Jun 15, 2017 at 6:19 AM, Linus Torvalds
<torv...@linux-foundation.org> wrote:
> () (),

That isn't some kind of odd googly-eyed emoticon, that's just the web
editor in gmail being odd with mixed touchpad input and cursor keys,
and I missed that garbage before sending.

Just in case somebody wondered why there were two eyes with a tear
down one cheek or whatever odd thing that could have been ;)

Linus

[Dirk Hohndel]

Clutter reduction. :-)

/D

[Linus Torvalds]

This seems to be an independent regression.

I think the "download dump and log" buttons have been recently broken
by some cleanup commits (commit 09904ddff525: "Extract the
device_data_t into helper class" looks particularly suspicious).

The logic for the "libdc_dump" and "libdc_log" variables changed a
lot, and they don't actually seem to do anything any more. It does ask
for the filename, and I see the setSaveDump() call (in a different
place), but when I actually add debug output to the downloader, I get:

libdc_dump=0 libdc_log=0

whether I checked those boxes or not.

So right now we won't be getting any Scubapro G2 log files simply
because the logfile logic is buggered...

Tomaz?

Linus

[Linus Torvalds]

On Thu, Jun 15, 2017 at 6:58 AM, Linus Torvalds
<torv...@linux-foundation.org> wrote:
>
> So right now we won't be getting any Scubapro G2 log files simply
> because the logfile logic is buggered...

In the meantime, I did the cleanups Jef noted, and added the missing
command dumping to the Scubapro G2 downloader in libdivecomputer (it
already dumped the reply data, just not the commands).

So when that ligfile logic gets fixed, we'll hopefully get enough data
to try to figure out what goes wrong for people. But right now none of
the logging works, so there's no point in even trying with the current
binaries ;)

Linus

[Dirk Hohndel]

If Tomaz doesn't have patches by tonight (i.e., in about eleven hours),
I'll take a look. I'm reasonably familiar with that code as well. But
first, Linus and I will have to go and create more data to test with.

For Science.

/D

[Martin Baumgartner]

Hi Linus,

my G2 has Firmware v1.1 and I'm working with Win10 1607

Best regards, Martin

[Davide DB]

On 15 June 2017 at 00:25, Dirk Hohndel <di...@hohndel.org> wrote:
>
> But first, Linus and I will have to go and create more data to test with.
>
> For Science.

Any open position as "guinea pig"? :D

--
Davide
https://vimeo.com/bocio/videos

[Jef Driesen]

On 2017-06-14 23:19, Linus Torvalds wrote:
> On Wed, Jun 14, 2017 at 8:14 PM, Jef Driesen <j...@libdivecomputer.org>
> wrote:
>> On 2017-06-09 07:28, Linus Torvalds wrote:
>>>
>>> diff --git a/examples/common.c b/examples/common.c
>>> index 3c4561b..5ebdd77 100644
>>> --- a/examples/common.c
>>> +++ b/examples/common.c
>>> @@ -54,6 +54,7 @@ static const backend_table_t g_backends[] = {
>>> {"smart", DC_FAMILY_UWATEC_SMART, 0x10},
>>> + {"g2", DC_FAMILY_UWATEC_SMART, 0x10},
>>> {"meridian", DC_FAMILY_UWATEC_MERIDIAN, 0x20},
>>
>>
>> I think you meant DC_FAMILY_SCUBAPRO_G2 here.
>
> I actually did that one on purpose, since it talked about "backends",
> and I think this just does the second stage parsing thing, which is
> all UWATEC smart, no?
>
> But it shouldn't matter, and I guess if there does end up being any
> differences, it's better to call it the SCUBAPRO_G2.

That table is used for selecting the correct device descriptor when
using the dctool --family option. It's used for both downloading and
parsing. With the wrong type in the table, it will pick the IrDA smart
backend for downloading, which obviously won't work for the G2. Parsing
will still work because the G2 uses the same smart backend.

>> For consistency with the other uwatec/scubapro backends, replace
>> DC_FAMILY_SCUBAPRO_G2 with DC_FAMILY_UWATEC_G2. Same remark for the
>> filenames.
>
> Please, let's absolutely *not* do that.
>
> This thing is known as the "Scubapro G2". As far as I know, it's not
> sold anywhere as "Uwatec". Uwtec isn't mentioned in any place that I
> can find, so it's purely an internal detail, and calling it a
> UWATEC_G2 is actively misleading.
>
>> For end-users the fact that the internal name is uwatec instead
>> of scubapro doesn't really matter, because they will only see the name
>> "Scubapro G2".
>
> This isn't aboue end-users. This is about developers. And for any
> *developers*, calling it "UWATEC_G2" is actively wrong.
>
> There is no such thing afaik. I tried to google it in case it's
> perhaps sold as something else in Europe, but that doesn't seem to be
> the case.
>
> There's just a Scubapro G2.

The dive computer is indeed named Scubapro G2. But the underlying
protocol and data format is the Uwatec Smart protocol. That means that
for libdivecomputer, it's part of the existing Uwatec family. If it was
a completely different protocol, then a new family would make sense, but
that's not the case here.

I already used that naming scheme for the Scubapro Meridian, and for
consistency I would like to continue the existing practice.

BTW, the reason why the family type has two parts (vendor and product)
and not just the product part alone, is simply because I wanted to group
related stuff together. Having all the suunto, mares, uwatec, ... files
and functions sitting nicely next to each other (due to the common
prefix) is very handy. You may consider that a silly reason, but it does
work very well for me!

You are right that the USB HID packets are vendor specific, and we can't
incorporate that in the usbhid code. But that's not really what the I/O
refactoring is about. It only handles how those packets are being
send/received, not their content.

The I/O layer abstraction will let you send those USB HID packets over
something else then USB HID. In this particular cases, that does not
make much sense, but there are cases where it does. For example classic
bluetooth (rfcomm) and their emulated serial ports. That's basically
just a difference in the underlying I/O API that is being used.

Note: if we're lucky and the Bluetooth Low Energy (BLE) uses the same
type of packetization as their USB HID implementation, then we just need
to swap the I/O layer, and we're done.

>>> + case DC_FAMILY_SCUBAPRO_G2:
>>> + rc = uwatec_smart_parser_create (&parser, context,
>>> 0x11,
>>> devtime, systime);
>>
>> Is there a reason why you have hardcoded the model number to 0x11?
>> Does the
>> data contain a different model number? Because in that case we should
>> update
>> the parser to support the new model number.
>
> I wasn't sure which number if would be, so I just picked the one that
> matched the galileo, but I thoyght t might change. And then it just
> worked, and I left it as that.
>
> Also, even the galileo *itself* doesn't use the GALILEO define in the
> descriptor tables. See src/descriptor.c, it's all 0x11 there.In fact,
> the whole define only exists within the uwatec_smart_parser.c file, so
> I'm not sure what you really expect people to do.

The Uwatec communication protocol (like many others), exchanges the
exact model number during the download. In that case, we simply ignore
the model number from the descriptor and always use the detected model
number. That's more reliable because end-users sometimes select the
wrong device (especially for devices with very similar names). With the
autodetection everything will just work, as long as the end-users picks
a device from the right family. But of course that fails if you hardcode
the model number.

If the G2 model number is different from 0x11 (I haven't seen any G2
data yet, so I simply don't know), then the new model number should be
added to the parser.

Note that the hardcoded number will also cause trouble if some future
model is introduced with a different model number.

>> There are a two issues with this code:
>
> I'm going to ignore your nitpicking as long as you ignore my sane
> string interfaecs.
>
> Jef, the reason I no longer send you patches, and just push stuff
> directly to the subsurface libdc repository is that I can't work with
> you.
>
> I'll take your input, but I'm done fighting your oddities. Integrate
> *our* code that actually matters, and I can work with you. In the
> meantime, I'm not interested in nitpicking details that don't matter
> one whit.

I'm only trying to maintain a consistent style throughout the entire
codebase. If I let one backend do things completely different, then we
soon end up with an inconsistent mess that is difficult to maintain. You
may disagree with the current conventions, but that's another
discussion.

>> Is the handshaking no longer necessary for the G2?
>
> It didn't seem to make any difference for me, so I removed it.
>
> But since some people seem to have download issues, I'm actually
> considering putting it back. My download trace from the Scubapro
> LogTRAK does have
>
> out: > 01 1b
> in : < 01 01
>
> out: > 05 1c10270000
> in : < 01 01
>
> as the first packet sequence (that is just a random cleaned-up packet
> thing: the numbers are packet length followed by packet data). Ad that
> matches the handshake sequence. So LogTRAK does do that handshake, but
> the G2 didn't seem to care.
>
> I suspect the handshake is more important over some random serial
> protocol that doesn't have device ID's etc.
>
> But as mentioned, because people clearly have some issues that I can't
> reproduce, I'm thinking of just doing that handshake anyway, just
> because it also doesn't seem to hurt.

If LogTRAK does the handshaking, then I think it's indeed a good idea to
add it back. We don't really know its purpose, but it might be something
relevant after all.

>> This will need some improvements to report more fine-grained progress
>> events.
>
> The thing is, it already reports *better* progress events for errors
> thanks to the actual error handling in receive_data(), which gives
> descriptive error STRINGS for what went wrong, and that subsurface can
> actually show to users in sanen ways (in the error status at the
> bottom).

I wasn't referring to error reporting, but to the normal
DC_EVENT_PROGRESS events. Now you jump from 0% at the start of the
download to 100% at the end of the download, without any updates in
between. For just one or a few dives that may not be a big deal, but for
larger downloads that's not very nice. (I don't know how fast the
download is.)

> In contrast, the random crazy libdivecomputer error codes are
> completely useless.
>
> This continues to be a contention point for me: your insistence on
> those useless random integer codes, when giving useful human-readable
> data with actual error descriptions and details on *what* went wrong
> is so much superior.
>
> So all libdivecomputer really needs to return is "an error happened".
> The error *description* is done by the dc_context_log() interface that
> is able to give real information.

I never said you should remove the more detailed logging. On the
contrary, I'm perfectly fine with that! They are absolutely a great aid
during debugging and troubleshooting!

If you ask me, returning error codes is a common practice in many C
libraries. So I don't think they are useless.

> So the scubapro G2 downloader returns error *strings* that can be
> displayed. Of course, you have ended up using macros that often get
> disabled, so if ENABLE_LOGGING isn't on, nothing gets logged. I'm
> wondering if that's in fact part of the problem with the current lack
> of any error output for people.

The logging is enabled by default. Thus, unless you explicitly disable
it, libdivecomputer is *always* build with logging enabled.

Jef

[Linus Torvalds]

On Tue, Jun 20, 2017 at 11:59 PM, Jef Driesen <j...@libdivecomputer.org> wrote:
>
> You are right that the USB HID packets are vendor specific, and we can't
> incorporate that in the usbhid code. But that's not really what the I/O
> refactoring is about. It only handles how those packets are being
> send/received, not their content.

Ok. That will work. In fact, it's what I'm doing for the BLE support
to make USB HID and BLE be real choices.

But it almost certainly has to be integrated with the "custom serial"
kind of model that allows the *outside* to set the packet sending
details, rather than being something internal to libdivecomputer.

And that's because libdivecomputer almost certainly will never be able
to do BLE sanely. Sending packets over GATT a very complex and nasty
protocol, not anything like the fairly straightforward "serial line
over bluetooth" that rfcomm is.

We're using QtConnectivity in subsurface for BLE (well, in my
experimental patches), and while I'm making some progress, we've
actually found two major issues in QtConnectivity already exactly
because BLE is very complex. And that was after I found some issues in
Bluez earlier just to pair the Suunto EON Steel in the first place.

So I do have a set of three patches that does this, and turns the
"custom_serial" thing into a "custom_io" thing (that allows both a
serial _and_ a packet interface), and lets devices use that.

I then made a simpe helper to say "if no custom IO has been defined,
create a custom IO definition for this USB HID device", and converted
both the Suunto EON Steel and the Scubapro G2 profile over to that
helper.

That actually allows me to feed in a custom packet handling set of
routines, and I'm now experimenting with BLE, but am hitting
QtConnectivity issues.

You can see my libdvicecomputer work at

git://github.com/torvalds/libdc-for-dirk.git Subsurface-branch

where the top three commits do that packet interface (it needs a
subsurface patch to then work with subsurface, which is why those
three patches haven't been pushed out to the real repo yet - I'll need
to synchronize with Dirk).

NOTE! It should be *trivial* to do the same kind of thing for a serial
line as I did for USB HID, ie a dive computer backend that sends
"packets" over a serial line could do a very similar "open serial line
with these settings" and then create a packet-sending custom_io
handler for that. So long-term, I'd actually like to remove the
"serial" part of the custom_io struct entirely. But I left it alone
for now, just to minimize the churn, and because I really just want to
work on the BLE side.

> Note: if we're lucky and the Bluetooth Low Energy (BLE) uses the same type
> of packetization as their USB HID implementation, then we just need to swap
> the I/O layer, and we're done.

From what I've seen, they are very similar at least for both the EON
Steel and the Scubapro G2.

But there is one big difference: the packet sizes are different for
BLE than from USB HID.

USB HID uses 64-byte packets, while BLE uses 32-byte packets but has
various other BLE headers.

In fact, I think there's only really 20 bytes of payload per packet in
GATT, and that the packetization is entirely different - it looks like
BLE over GATT acts more like a "stream" than the very obvious HID
packetization that at least the Suunto EON Steel is very obviously
very aware of.

So at a minimum, the divecomputer-specific download code needs to know
the packetization boundaries, in order to handle that correctly. Which
is why my custom_io definition has five fields: one field for the
packet size, and four fields for open/close/read/write functions
respectively.

But that *may* be the only real difference. Due to my lack of success
in getting BLE working yet, I can't guarantee there aren't other
issues.

Linus

[Linus Torvalds]

On Wed, Jun 21, 2017 at 5:49 PM, Linus Torvalds
<torv...@linux-foundation.org> wrote:
>> Note: if we're lucky and the Bluetooth Low Energy (BLE) uses the same type
>> of packetization as their USB HID implementation, then we just need to swap
>> the I/O layer, and we're done.
>
> From what I've seen, they are very similar at least for both the EON
> Steel and the Scubapro G2.
>
> But there is one big difference: the packet sizes are different for
> BLE than from USB HID.

Ok, having gotten over (at least some) of the BLE GATT communication
issues with QtConnectivity, I can actually confirm that the problems
are worse than that.

The command structure seems fairly similar, but the packetization of
the commands is completely different over USB HID and BLE GATT.

The USB HID protocol is a simple "split it up into 64-byte packets by
having a 62-byte payload and two byte per packet size information".

The BLE GATT protocol, in turn, depends on GATT to do the
packetization, so it acts more like a streaming protocol, but then it
HDLC-encapsulates it (it looks like it uses a crc32 checksum, but I
haven't verified that part yet, but it would seem to fit).

I'm not quite sure *why* it does that (I thought BLE already gave you
a reliable stream), but whatever. It is what it is.

I _think_ it may be so that the GATT receiver code can tell when it
hits the last packet, without having to understand the stream data
itself (that would explain why the USB HID protocol also uses a
redundant packet size byte).

So the take-away is that sadly the libdivecomputer code does very much
need to know which protocol it's running over, and do different things
over different protocols.

At the same time, because BLE itself is so complicated,
libdivecomputer can't actually do the IO itself on its own.

Linus

[Jef Driesen]

This all sounds very similar to the I/O refactoring I proposed. Minus
the packetization stuff of course (because that wasn't necessary yet at
that time). But that's trivial to add. We only need to expose the packet
size (just like you did), so you can use the read/write functions with
the right size.

I don't think it's that easy to completely get rid of the serial
communication stuff. There are several backends that need to change the
serial line settings and DTR/RTS lines during the communication. That's
why those functions are present in the abstract I/O interface, even if
they only apply to serial communication. My reasoning was those
functions can be implemented as stubs for I/O implementations where they
don't make sense.

>> Note: if we're lucky and the Bluetooth Low Energy (BLE) uses the same
>> type
>> of packetization as their USB HID implementation, then we just need to
>> swap
>> the I/O layer, and we're done.
>
> From what I've seen, they are very similar at least for both the EON
> Steel and the Scubapro G2.
>
> But there is one big difference: the packet sizes are different for
> BLE than from USB HID.
>
> USB HID uses 64-byte packets, while BLE uses 32-byte packets but has
> various other BLE headers.
>
> In fact, I think there's only really 20 bytes of payload per packet in
> GATT, and that the packetization is entirely different - it looks like
> BLE over GATT acts more like a "stream" than the very obvious HID
> packetization that at least the Suunto EON Steel is very obviously
> very aware of.
>
> So at a minimum, the divecomputer-specific download code needs to know
> the packetization boundaries, in order to handle that correctly. Which
> is why my custom_io definition has five fields: one field for the
> packet size, and four fields for open/close/read/write functions
> respectively.
>
> But that *may* be the only real difference. Due to my lack of success
> in getting BLE working yet, I can't guarantee there aren't other
> issues.

If the differences are bigger than just a difference in the packet size,
then we can probably still deal with that with a minimal amount of
transport specific knowledge in the backend.

Take for example again the three uwatec variants: smart (IrDA), meridian
(usb-serial with some additional framing) and g2 (USB HID and BLE GATT
with their own packetization). Since the high level parts of the
protocol are the same, we could implement this as a single backend with
some function pointer for the transfer function:

typedef dc_status_t (*uwatec_smart_transfer_t) (uwatec_smart_device_t
*device, const unsigned char command[], unsigned int csize, unsigned
char answer[], unsigned int asize);

typedef struct uwatec_smart_device_t {
...
uwatec_smart_transfer_t transfer;
} uwatec_smart_device_t;


dc_status_t
uwatec_smart_device_open (dc_device_t **out, dc_context_t *context,
dc_iostream_t *iostream)
{
uwatec_smart_device_t *device;

...

switch (dc_iostream_get_type(iostream)) {
case DC_TRANSPORT_IRDA:
device->transport = irda_transfer;
break;
case DC_TRANSPORT_SERIAL:
device->transport = serial_transfer;
break;
case DC_TRANSPORT_USBHID:
device->transport = usbhid_transfer;
break;
case DC_TRANSPORT_BLE:
device->transport = ble_transfer;
break;
}

...
}

This way, the dive computer backend needs to be aware how the data
packets are structured, but it doesn't need to know how they are send
out. That's still up to the I/O implementation.

Thus if you implement a custom transport, you just need to indicate the
correct transport type, and you'll get the right type of packets. So for
testing purpose you can easily implement a transport that pretends to do
BLE, and then send out the data over a serial line (or a tcp/ip socket,
etc). (That's in fact how I test the smart backend against the simulator
without having to deal with IrDA.)

Jef

[Linus Torvalds]

On Mon, Jun 26, 2017 at 10:06 PM, Jef Driesen <j...@libdivecomputer.org> wrote:
>
> I don't think it's that easy to completely get rid of the serial
> communication stuff. There are several backends that need to change the
> serial line settings and DTR/RTS lines during the communication. That's why
> those functions are present in the abstract I/O interface, even if they only
> apply to serial communication. My reasoning was those functions can be
> implemented as stubs for I/O implementations where they don't make sense.

Yeah, I guess having empty stubs that you can just leave as NULL isn't
that painful.

It's effectively what the current "custom_io_t" does for the serial side.

Pretty much any modern equipment that will do something that looks
serial over a modern line won't be caring about any of the low-level
traditional serial details (ie break, dtr/rts, baud speed, parity
etc).

>> But there is one big difference: the packet sizes are different for
>> BLE than from USB HID.
>>

>> But that *may* be the only real difference. Due to my lack of success
>> in getting BLE working yet, I can't guarantee there aren't other
>> issues.

There definitely are other issues, having now gotten BLE to work with
three different dive computers.

In fact, the last one (Shearwater Perdix) uses BLE in a rather odd
way, and actually avoids some of the packet size limits that way.

Instead of treating the BLE GATT protocol as a way of sending a
packet, the Perdix actually uses it differently, and sends the streams
of data as "descriptor value changes" and let's the GATT protocol
itself actually re-assemble multiple packets into bigger data. So even
though each packet has a payload in the 20-byte range, I see single
updates as multiple packets that then show up in user space as one big
change.

So the 20-byte packet limit doesn't end up being a hard limit, it is
related to a particular choice of BLE GATT interface use.

> If the differences are bigger than just a difference in the packet size,
> then we can probably still deal with that with a minimal amount of transport
> specific knowledge in the backend.

Some of the nastiest differences end up being things that the front
end has to know about.

The one I hit with the Shearwater Perdix was that the way you connect
to it is different than the EON Steel or the Scubapro G2, because the
Perdix ends up using a "Random Device Address" rather than a normal
public address. And while nobody sane should care, they technically
are different address spaces entirely, and the Linux Bluez layer
*does* care. So even though you know the device address, you also have
to know whether to connect to it using the random device address flag
or not.

I have *no* idea why Shearwater did that. But I guess it means that
they don't have to register a company ID for the address.

But it does mean that for BLE GATT, I need to know "does this device
use a random device address or not".

I can make various hacks up (for example, I can just look at the
address and say "I don't recognize the top 24 bits as a company that
makes dive gear, so maybe it's a random address"), but what I think I
will do is to just trigger on the name (ie "Perdix") during bluetooth
scanning, and save away the quirk that "this device needs to be
connected to using the random device address flag".

And since I'm pretty sure that libdivecomputer does *not* want to do
the whole "scan for bluetooth devices" and also does *not* want to
know about things like crazy protocol details that have absolutely no
impact on libdivecomputer anyway, I need the custom IO model to be
able to just add its own information to its own info block.

That's what the "custom_io_t" is meant for, and libdivecomputer
doesn't even need to know about the details.

The older "customserial" protocol made the big mistake of not passing
its own IO data descriptor around, just passing that "fill in this
'void **userdata' thing", and it works as long as you really *just*
look like serial (which rfcomm does).

But immediately when you need to add your own transport quirks in
there, you need something more.

> Take for example again the three uwatec variants: smart (IrDA), meridian
> (usb-serial with some additional framing) and g2 (USB HID and BLE GATT with
> their own packetization). Since the high level parts of the protocol are the
> same, we could implement this as a single backend with some function pointer
> for the transfer function:

That's pretty much what I do for the G2 right now.

Note in particular how I use the "custom_io_t" not only as a way to
pass in the IO function from outside (which, as mentioned, is pretty
much required for BLE - I seriously doubt you want to handle all the
different OS details yourself, when something like Qt has it
reasonably well abstracted)..

I also actually use that "custom_io_t" inside of libdivecomputer
itself, creating a new one dynamically and making it use the USB HID
code that libdivecomputer already has:

if (io && io->packet_open)
status = io->packet_open(io, context, name);
else
status = dc_usbhid_custom_io(context, 0x2e6c, 0x3201);

in other words, either that code gets passed an IO descrpiptor from
outside, or it just generates its own custom IO descriptor using the
usbhid code and that USB vendor ID.

It should be possible to extend that to other models too (for example,
the non-HID USB transport that the Atomic Cobalt does), but right now
the dive computers I care about are all either BLE or USB HID, so
those are the two things I have worried about.

Anyway, right now that "custom_io_t" only has the packet size as a way
to discriminate with, but that clearly is not sufficient. But neither
is it good enough to say what type it is - it's also not sufficient to
say "USB vs USB HID vs BLE". Because it turns out that within BLE
there are variations, and obviously within USB there are certainly
possibilities for variations way past just the USBHID vs "random
vendor-specific USB" case.

Linus

[Linus Torvalds]

On Mon, Jun 26, 2017 at 11:37 PM, Linus Torvalds
<torv...@linux-foundation.org> wrote:
>
> Anyway, right now that "custom_io_t" only has the packet size as a way
> to discriminate with, but that clearly is not sufficient. But neither
> is it good enough to say what type it is - it's also not sufficient to
> say "USB vs USB HID vs BLE". Because it turns out that within BLE
> there are variations, and obviously within USB there are certainly
> possibilities for variations way past just the USBHID vs "random
> vendor-specific USB" case.

Btw, that may have come off the wrong way - I do *not* think that the
particular protocol should even be enumerated or described
particularly well at all using some generic descriptors.

No, in many ways I'm arguing for the reverse: not to describe things
very much at all, but instead just let each "custom_io_t" do its own
thing, and just have a "void *" that the particular transport fills in
with *its* particular details. And those details will be very
different for bluetooth than they will be for USB.

And I already ended up chaining these custom_io_t's together: the way
I did the Shearwater Perdix was to use the "rfcomm" serial interface
to expose the serial side, but then when using BLE GATT, literally
chaining that serial side though two levels of custom_io_t: the first
level does the buffering to make it look like a serial line, and the
second level is the regular BLE GATT packetization for the actual IO.

It's pretty hacky, and it's not some kind of truly generic "streams"
thing that is designed to chain, but more of just a special case a
"turn one interface into another" chain, but it works. And it largely
avoids exposing the details of one level to another, and it's not
passing any odd level descriptors around, because the custom_io_t
itself *is* the descriptor and contains the knowledge of what it's
doing and who it is acting to.

Linus

[Linus Torvalds]

On Mon, Jun 26, 2017 at 11:37 PM, Linus Torvalds
<torv...@linux-foundation.org> wrote:
>

> The older "customserial" protocol made the big mistake of not passing
> its own IO data descriptor around, just passing that "fill in this
> 'void **userdata' thing", and it works as long as you really *just*
> look like serial (which rfcomm does).
>
> But immediately when you need to add your own transport quirks in
> there, you need something more.

So I sent Dirk the pull request for my SSRF_CUSTOM_IO v2 code, which
updates the custom serial parts to pass along the IO pointer, and also
adds a opaque (as far as libdivecomputer is concerned)
"dc_user_device_t" field to the IO model.

That allows me to pass down not just the IO functions, but also the
"what device am I trying to download from" information, because the IO
model gets filled in early, and gets passed around to all the openm
code and IO accessor functions.

That, in turn, allows me to have different bluetooth logic for open
and IO based on the device I'm downloading from. Which I need, since
the rules are different for a Shearwater device than for a Suunto one.

It's not pretty, but then bluetooth LE really isn't pretty. It's very
much a "designed by committee" thing, and (similarly to USB,
presumably for similar reasons), bluetooth LE was explicitly designed
to *not* just have a standardized serial protocol.

Morons. USB did the exact same thing, and I think the reasons are the
same: both design committees wanted to explicitly avoid "transparent
serial emulation" simply because serial can be used for anything, and
they wanted to *describe* each protocol.

Never mind the fact that reality trumps the poor brains of committee
people, and people want to do serial communications over new
protocols, so they all then just make it happen anyway, but do it in
some crazy vendor-specific manner.

So instead of having a nice clean architected serial line emulation of
USB or over BLE, we have ugly shit-for-brains vendor-specific ones
that are different and often subtly broken.

Yay for committee standards - those committees really showed people
how much better things are when you try to force people to all do
their own described protocols rather than use a standard serial one.

Linus

[Linus Torvalds]

On Fri, Jun 9, 2017 at 11:13 AM, Stuart Vernon <stu...@force2.net> wrote:
> On an semi-related note: I'm just curious what factors caused you to buy a G2 over a Perdix AI.

So just coming back to this thread because another G2 question
triggered the memory.

I have now actually used the G2, and I rate it an "OK" dive computer.
It has reasonable features, it works fine, there's nothing strictly
wrogn with it.

But...

It's not a *great* dive computer. The UI is a bit cluttered while
diving, except in the simple mode (which I preferred overall), but
that simple mode is a bit _too_ simple and shows RBT or NDL (it shows
whichever is closer) but not both.

And the automatic safety stop behavior is pure garbage. Apparently
that's a case of "we've always done it that way, so we're doing it
that way now too", but I haven't used previous Uwatec/Scubapro dive
computers, so I know how it *should* work, and the G2 simply doesn't
do it right.

So there are no show-stoppers, but there are a couple of annoyances.
My EON Steel easily remained my favorite dive computer during that
trip.

Dirk was diving his Perdix AI, and liked it a lot. So I got one for
myself (hey, I like tech toys, and my excuse was that I needed it for
bluetooth testing anyway). It looks good, and you do get used to the
buttons after a while (my bluetooth testing caused me to use them a
lot to go into the bluetooth mode ;)

But I haven't been diving the Perdix AI yet myself, so maybe I find
some annoyance. The screen layout looks very good though, it hits all
my "simple and clean and gives me everything I care about in
consistent places" requirements.

Linus

[Davide DB]

It's time to update the dive computer rambling page :)

davide@mobile

[Jeff Waldrop]

I don't see that the G2 is yet supported by Subsurface.  The thread led me to believe support has been added.  I have 4.6.4 on my Mac and that is the last download available.  I am liking this new G2 less and less.  I sold a first gen Cobalt that I really say now I liked better and could see data on screen better.

jeff

[Dirk Hohndel]

You are right, the G2 is not supported in 4.6.4. 

It is supported in our latest test build. We are in the middle of an active development cycle and it will be a while before I release the next version of Subsurface, in the meantime feel free to try http://subsurface-divelog.org/downloads/test/Subsurface-4.6.4-308-g61fff71391ce.dmg (or whatever the latest version in that directory may be).

/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 post to this group, send email to subsurfac...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/subsurface-divelog/487a9fa8-9996-4ebd-bd59-3aa4f7bd536a%40googlegroups.com.

[Albe G]

Tried newest "beta" version of SubSurface on Win10_x64 with USB cable. No luck at all.

I had similar problem with Diving Log and the author sent me a updated libdive (+2 other files). No idea if the newer SubSurface version you are forging is BT specific or USB too.



Il giorno venerdì 2 giugno 2017 23:55:23 UTC+2, CZS ha scritto:

Not sure if you're aware, but Scubapro has just released a new dive computer, the Galileo 2 or G2. This computer features wireless bluetooth syncing through the LogTrak IOS/Android apps. Any idea how long it might take to get this computer syncing with Subsurface? I'd certainly offer any assistance I can in testing/troubleshooting, feel free to ask!

[Dirk Hohndel]

Subsurface supports USB Download from the Scubapro G2 - the one problem is that LogTrack registers a driver for the G2 with Windows that Subsurface doesn't work with.

So you need to switch the driver that is installed - you can do this with the Zadig tool http://zadig.akeo.ie/downloads/zadig_2.1.0.exe - if you switch the driver to WinUSB then the current test build of Subsurface will happily download from your G2.

BTW: it's Subsurface, no CamelCase. And these are 'test' builds, not beta versions, as the download location (download/test) clearly indicates. And right now the Windows build in that area has quite a few problems in other areas since we are changing the build environment around...

/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 post to this group, send email to subsurfac...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/subsurface-divelog/4c0f096a-281f-4188-bdbd-f2cc1706e2b3%40googlegroups.com.

[Albe G]

Thanks for the kind reply.

Unfortunately I followed your instruction (zadig has a newer version) but no way,

Il giorno domenica 30 luglio 2017 17:32:35 UTC+2, Dirk ha scritto:

Subsurface supports USB Download from the Scubapro G2 - the one problem is that LogTrack registers a driver for the G2 with Windows that Subsurface doesn't work with.

So you need to switch the driver that is installed - you can do this with the Zadig tool http://zadig.akeo.ie/downloads/zadig_2.1.0.exe - if you switch the driver to WinUSB then the current test build of Subsurface will happily download from your G2.

BTW: it's Subsurface, no CamelCase. And these are 'test' builds, not beta versions, as the download location (download/test) clearly indicates. And right now the Windows build in that area has quite a few problems in other areas since we are changing the build environment around...

/D

On Jul 30, 2017, at 5:24 AM, Albe G <tur...@gmail.com> wrote:

Tried newest "beta" version of SubSurface on Win10_x64 with USB cable. No luck at all.

I had similar problem with Diving Log and the author sent me a updated libdive (+2 other files). No idea if the newer SubSurface version you are forging is BT specific or USB too.



Il giorno venerdì 2 giugno 2017 23:55:23 UTC+2, CZS ha scritto:

Not sure if you're aware, but Scubapro has just released a new dive computer, the Galileo 2 or G2. This computer features wireless bluetooth syncing through the LogTrak IOS/Android apps. Any idea how long it might take to get this computer syncing with Subsurface? I'd certainly offer any assistance I can in testing/troubleshooting, feel free to ask!

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

[Albe G]

Ok, after a couple of try, I get this:

Attached log and bin files.

Il giorno domenica 30 luglio 2017 17:32:35 UTC+2, Dirk ha scritto:

Subsurface supports USB Download from the Scubapro G2 - the one problem is that LogTrack registers a driver for the G2 with Windows that Subsurface doesn't work with.

So you need to switch the driver that is installed - you can do this with the Zadig tool http://zadig.akeo.ie/downloads/zadig_2.1.0.exe - if you switch the driver to WinUSB then the current test build of Subsurface will happily download from your G2.

BTW: it's Subsurface, no CamelCase. And these are 'test' builds, not beta versions, as the download location (download/test) clearly indicates. And right now the Windows build in that area has quite a few problems in other areas since we are changing the build environment around...

/D

On Jul 30, 2017, at 5:24 AM, Albe G <tur...@gmail.com> wrote:

Tried newest "beta" version of SubSurface on Win10_x64 with USB cable. No luck at all.

I had similar problem with Diving Log and the author sent me a updated libdive (+2 other files). No idea if the newer SubSurface version you are forging is BT specific or USB too.



Il giorno venerdì 2 giugno 2017 23:55:23 UTC+2, CZS ha scritto:

Not sure if you're aware, but Scubapro has just released a new dive computer, the Galileo 2 or G2. This computer features wireless bluetooth syncing through the LogTrak IOS/Android apps. Any idea how long it might take to get this computer syncing with Subsurface? I'd certainly offer any assistance I can in testing/troubleshooting, feel free to ask!

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

On Tue, Aug 1, 2017 at 5:34 AM, Albe G <tur...@gmail.com> wrote:

Ok, after a couple of try, I get this:

Attached log and bin files

Ok, the log file shows that USB accesses clearly worked.  

And in fact, I can see three dives when I re-run that log file of yours:

​

Note: if you ask for the dump file, subsurface won't actually get any download data. So do a download without that.

               Linus

[Albe G]

I had Error parsing header error and no diving imported.

I generated the dump file to be of use here.

[Linus Torvalds]

On Aug 3, 2017 05:37, "Albe G" <tur...@gmail.com> wrote:

I had Error parsing header error and no diving imported.

Ahh. I think that may be because of a G2 parsing bug in libdivecomputer that we fixed a couple of weeks ago. Can you try a newer build? That would explain why I can see the dive when I just run using your dump data, but you didn't see the dive yourself.

    Linus

[Albe G]

Ok, now it works but only when I connect G2 to Intel 6 (chipset) USB port. When I connect to ASMedia USB 3 port. gives me insufficient privileges bla bla.

Why DivingLog works with libdivecomputer-0.dll without having to replace USB driver?

[Albe G]

Added to my previous message: importing does not take account of fresh or salted water and set fresh always.

[Martin Baumgartner]

Hi together,

on vacation I could test something more intensively.
Good part: Subsurface mobile (beta build 734) works reliably with the G2.
However, I noticed that the depth that the G2 logs and displays does not always match the read data in Subsurface mobile.
For example - G2: 33.0m subsurface: 33.8m.
Also shallower dives are no correct - G2: 6.9m Subsurface: 7.1m

Perhaps the conversion is not correct here.
The settings of my G2 are: m (meter) and water type: salt water.

With "fresh water" the error does not occur.

Best regards,
Martin

[Dirk Hohndel]

That sounds like the G2 already does the fresh/salt water adjustment internally and we do it AGAIN, which would cause about the change that you observe.

/D

[Linus Torvalds]

On Fri, Aug 25, 2017 at 6:38 AM, Dirk Hohndel <di...@hohndel.org> wrote:
>
> That sounds like the G2 already does the fresh/salt water adjustment internally and we do it AGAIN, which would cause about the change that you observe.

We do *not* use salinity to calculate the depth in subsurface.

But it does look like the uwatec download format gives some
pressure-dependent depth, and the salinity affects the download data
*there*. The libdivecomputer code does:

sample.depth = (depth -
depth_calibration) / salinity;
if (callback) callback
(DC_SAMPLE_DEPTH, sample, userdata);

and so if libdivecomputer gets the salinity wrong, it will get the
depth wrong too.

And it does look like the values are off exactly by the salinity difference:

> For example - G2: 33.0m subsurface: 33.8m.
> Also shallower dives are no correct - G2: 6.9m Subsurface: 7.1m

with fresh water having salinity 1.0, and salt having salinity 1.025,
that exactly matches the difference to the G2 logs.

I don't know why it would get the salinity wrong, though. The G2
header parsing is exactly the same as the regular galileo, but I'll cc
Jef in case he has some ideas.

Linus

[Jef Driesen]

I'll have to look into the details again, but I remember that I added the
salinity adjustment after complaints from users that the depth was off. One
possible source of inconsistency is that there are two applications: smarttrak
and logtrak. So it's not impossible that one of them takes into account the
salinity, while the other one doesn't do that.

I haven't verified whether the salt/fresh water flag is indeed in the same
location as the uwatecs. But I would be surprised if it's different because
everything else seems to be the same.

Jef

[Albe G]

Please look at this.

It works with DivingLog without having to replace any driver in windows.

[Linus Torvalds]

On Sat, Sep 2, 2017 at 3:01 AM, Albe G <tur...@gmail.com> wrote:
> Please look at this.
>
> It works with DivingLog without having to replace any driver in windows.

I think we have a HIDAPI version of libdivecomputer working now, but
Dirk had some issues testing the G2 on Mac, and none of the developers
actually use windows, so..

Linus

[Jef Driesen]

On windows, the hidapi based version works fine for both the G2 and Eon
Steel. I have confirmation by several users already. I don't expect any
problems for the other platforms either.

At the moment Divinglog is still shipping the libusb based version,
because switching will cause problems for existing users. They have
installed the Winusb/libusbk driver, and will need to uninstall the
driver again. The same will be true for subsurface users.

In the meantime, I did investigate the libusb code in more detail, and
it turns out that it can actually support both the HID driver and the
Winusb/libusbk driver. The reason why it doesn't work with the HID
driver right now is because the microsoft HID api expects to always get
33 byte packets (1 byte for the report id and 32 bytes payload). The
hidapi library internally pads the buffer to the expected size, but
libusb doesn't do this (*). I verified this by modifying libdivecomputer
to always send 33 bytes, and then the libusb version works fine with the
hid driver. But I don't know whether this breaks anything on non-windows
platforms or not.

(*) I reported the problem on the mailinglist already, but so far not
much response.

https://sourceforge.net/p/libusb/mailman/message/35996931/

Jef

[JEFF WALDROP]

Any strides forward getting Subsurface to work with the new Galileo G2?

Jeff W Waldrop

--
You received this message because you are subscribed to a topic in the Google Groups "Subsurface Divelog" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/subsurface-divelog/VPJhVIEBesc/unsubscribe.
To unsubscribe from this group and all its topics, send an email to subsurface-divelog+unsubscribe@googlegroups.com.
To post to this group, send email to subsurface-divelog@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/subsurface-divelog/70daf4096184b0ffc05fe691aec40b4e%40libdivecomputer.org.

[Linus Torvalds]

On Tue, Sep 26, 2017 at 12:39 PM, JEFF WALDROP <jeff.w....@gmail.com> wrote:
> Any strides forward getting Subsurface to work with the new Galileo G2?

It works fine for me, both bluetooth and USB (Linux).

Dirk also verified hidapi USB on at least MacOS.

Current subsurface seems to have some new BLE issues, I suspect
something happened when Dirk tried to get BLE working on MacOS. I'm
investigating.

Linus

[JEFF WALDROP]

Good to hear!  Has it been released yet ir still in beta?

I think I am running 4.6.4 on my Mac

[Linus Torvalds]

On Tue, Sep 26, 2017 at 1:21 PM, JEFF WALDROP <jeff.w....@gmail.com> wrote:
> Good to hear! Has it been released yet ir still in beta?
>
> I think I am running 4.6.4 on my Mac

Oh,m you definitely need the daily test builds.

https://subsurface-divelog.org/downloads/test/

should have a dmg from a few days ago.

Linus

[Martin Baumgartner]

Hello guys,
you're doing a great job. Thank you for your effort.
Subsurface mobile is great.

Is there any progress on the salinity-thing?

Best regards,
Martin

[Dirk Hohndel]

I don't think anyone is looking into this right now (we are all busy with

what feels like a million other issues getting to a point where we can

create new releases for both Subsurface and Subsurface-mobile).

Would you mind adding an issue on GitHub so we don't forget about

this problem?

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 post to this group, send email to subsurfac...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/subsurface-divelog/5f989380-bc15-4d2b-a228-dd23e3416f5f%40googlegroups.com.

[Linus Torvalds]

On Thu, Sep 28, 2017 at 7:26 AM, Martin Baumgartner
<baumga...@gmail.com> wrote:
> Hello guys,
> you're doing a great job. Thank you for your effort.
> Subsurface mobile is great.
>
> Is there any progress on the salinity-thing?

Can you check the last daily builds?

https://subsurface-divelog.org/downloads/test/

I'm not sure anything has been fixed, but I dove the G2 last week, and
I get correct salinity values when I download the dives.

So the bug you saw earlier _may_ be an older issue, there's been a few
small fixes to the G2 parsing that might have fixes this for you too.

Linus

[Martin Baumgartner]

Hi Linus,

I'm going to check it next dive.

Best regards,
Martin

[DE MEY Daniel]

Erased my logfile on G2... how to retore.

Please help

Thank you

Op vrijdag 2 juni 2017 23:55:23 UTC+2 schreef CZS: