Re: Garmin Mk2i - unlikely dive gas

[Dirk Hohndel via subsurface]

Yeah, it would be good to know how this is all done in a multi gas scenario.

For now I'd be tempted to add code that says "if there is only one gas mix, but 
more tanks, assume the same gas is in all tanks"

/D

> On Jun 13, 2022, at 2:19 PM, Mark wrote:
> 
> 
> Hi Dirk,
> 
>>> I have a Garmin Descent Mk2i myself and have done a fair number of air 
>>> dives with it, so I don't believe this is a general issue.
>>> But you may have set things up differently compared to the settings on mine 
>>> - so I'll poke at your .FIT file and find out :)
>> 
>> From your FIT file it seems that you have more than one tank pod connected 
>> to your Garmin, but only one gas mix defined. That confuses our code a bit 
>> and it thinks that the second pod is connected to a dive with undefined gas 
>> data - and then it defaults to air for that
>> 
>> Do you actually have more than one pod attached? Are you using both? How 
>> does this look in the on-watch settings?
> I was thinking about this in bed after I sent you my FIT last night, but 
> didn't have the brain power to work through it, or the desire to start wading 
> through the Garmin menus.  Yes, I do have two transmitters connected and for 
> all these dives only one gas mix.
> 
> The first transmitter is mine, and is set to be included in SAC calculations. 
> The second transmitter is on my partner's regs - she's only just started 
> diving, and I like to be able to keep an eye on her pressure at a glance. The 
> second transmitter is excluded from SAC calcs. I've had a look through the 
> dive setup on the watch, but it doesn't look like you assign a gas mix to a 
> transmitter, even in multi-gas mode. I've not done multi-gas dives with my 
> Garmin, so I don't know how it deals with matching mixes to cylinders (or 
> indeed if it does).
> 
> Next single gas dive I do, I could add a backup gas and see if it assigns the 
> backup gas to my second transmitter?
> 
> It'll probably be a while before I get out again, but I can experiment a bit 
> over the next few dives if you think that will help.
> 
> When I first import these dives with two transmitters, the graph shows both 
> cylinder pressures, but the SAC rate is blank until I delete the second 
> cylinder. I assume something in there is also confusing Subsurface's SAC 
> calcs?
> 
> Mark.

___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Garmin Mk2i - unlikely dive gas

[Mark Stiebel via subsurface]

Hi Dirk,

I have a Garmin Descent Mk2i myself and have done a fair number of air 
dives with it, so I don't believe this is a general issue.
But you may have set things up differently compared to the settings on 
mine - so I'll poke at your .FIT file and find out :)
From your FIT file it seems that you have more than one tank pod 
connected to your Garmin, but only one gas mix defined. That confuses 
our code a bit and it thinks that the second pod is connected to a dive 
with undefined gas data - and then it defaults to air for that


Do you actually have more than one pod attached? Are you using both? 
How does this look in the on-watch settings?
I was thinking about this in bed after I sent you my FIT last night, but 
didn't have the brain power to work through it, or the desire to start 
wading through the Garmin menus.  Yes, I do have two transmitters 
connected and for all these dives only one gas mix.


The first transmitter is mine, and is set to be included in SAC 
calculations. The second transmitter is on my partner's regs - she's 
only just started diving, and I like to be able to keep an eye on her 
pressure at a glance. The second transmitter is excluded from SAC calcs. 
I've had a look through the dive setup on the watch, but it doesn't look 
like you assign a gas mix to a transmitter, even in multi-gas mode. I've 
not done multi-gas dives with my Garmin, so I don't know how it deals 
with matching mixes to cylinders (or indeed if it does).


Next single gas dive I do, I could add a backup gas and see if it 
assigns the backup gas to my second transmitter?


It'll probably be a while before I get out again, but I can experiment a 
bit over the next few dives if you think that will help.


When I first import these dives with two transmitters, the graph shows 
both cylinder pressures, but the SAC rate is blank until I delete the 
second cylinder. I assume something in there is also confusing 
Subsurface's SAC calcs?


Mark.
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: [map] Where to import maps from?

[Jason Bramwell via subsurface]

There is nothing definitive that I’ve ever heard of. I capture my own GPS 
coordinates and plot them on my dive log map.

Jb

Sent from my iPhone

> On 13 Jun 2022, at 19:19, Daniel Azuelos via subsurface 
>  wrote:
> 
> Hello,
> Is there an official source of diving sites maps to import
> .ssrf or .xml from?
> I failed to find one after a long search on the web,
> For example:https://dive.site/
> shows 2 sites around a location where I saw about ten.
> 
> If not are there any local sources of good diving sites maps
> -- 
>« The only thing necessary for the triumph of evil
>is for good men to do nothing. »
>Edmund Burke
> 
> daniel Azuelos
> ___
> subsurface mailing list
> subsurface@subsurface-divelog.org
> http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: time for 5.0.9

[Dirk Hohndel via subsurface]

Just a quick update.

Jef and I are working with a user who has a newer version of an Aqualung i200C 
which isn't recognized by Subsurface.
There's a chance that this is a very quick fix (and we are having the user test 
that right now). If that's the case, then I'd love to include that update in 
the next version, otherwise I'll release what we have later this week.

/D

> On Jun 5, 2022, at 4:46 PM, Dirk Hohndel via subsurface 
>  wrote:
> 
> 
> We have a few bug fixes and a few new dive computers (and fixes to existing 
> dive computers).
> Nothing really exciting, but enough to make it worth cutting a new release, I 
> think.
> 
> There are just a couple new strings that need translations, so I'll give it a 
> few days, but again, nothing super complex... I think it's 8 total, and 5 of 
> them are for the different numbering for depth lines...
> 
> If there's anything I should be waiting for, please let me know.
> 
> Thanks
> 
> /D
> ___
> subsurface mailing list
> subsurface@subsurface-divelog.org
> http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

[map] Where to import maps from?

[Daniel Azuelos via subsurface]

Hello,
Is there an official source of diving sites maps to import
.ssrf or .xml from?
I failed to find one after a long search on the web,
For example:https://dive.site/
shows 2 sites around a location where I saw about ten.

If not are there any local sources of good diving sites maps
-- 
« The only thing necessary for the triumph of evil
is for good men to do nothing. »
Edmund Burke

daniel Azuelos
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: time for 5.0.9

[Dirk Hohndel via subsurface]

> On Jun 13, 2022, at 10:22 AM, Linus Torvalds  
> wrote:
> 
> On Sun, Jun 12, 2022 at 7:53 PM Dirk Hohndel  wrote:
>> 
>> /usr/bin/ld: cannot open linker script file 
>> /builddir/build/BUILD/qtbase-everywhere-src-5.15.3/.package_note-qt5-qtbase-5.15.3-2.fc36.x86_64.ld:
>>  No such file or directory
>> 
>> Hey Linus - is this something that you see, too?
> 
> Just checked, and yes.
> 
>> The hack around this that I found and then forgot is hidden in 
>> packaging/copr/subsurface.spec:
> 
> Removing that package_not works for me too. No idea what/why/how it
> gets generated.


There are LONG discussion threads on the Fedora bugzilla how this is this super 
cool thing that allows you to do super important things and how it's totally ok 
that this breaks stuff because it's super cool.

OK, I may be paraphrasing slightly - but that's pretty much what I took away 
from them.

You'll see bugs like this https://bugzilla.redhat.com/show_bug.cgi?id=2055863 
 which say "oh well" and 
then nothing happens.
And stuff like this https://bugzilla.redhat.com/show_bug.cgi?id=2043178 
 that says "oh, we fixed 
it for this specific package by hacking around it".

But what I haven't found, yet, is something that explains why I want these 
package_notes and why Fedora 36 enabled them even though it breaks so many 
things...

/D___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: time for 5.0.9

[Linus Torvalds via subsurface]

On Sun, Jun 12, 2022 at 7:53 PM Dirk Hohndel  wrote:
>
> /usr/bin/ld: cannot open linker script file 
> /builddir/build/BUILD/qtbase-everywhere-src-5.15.3/.package_note-qt5-qtbase-5.15.3-2.fc36.x86_64.ld:
>  No such file or directory
>
> Hey Linus - is this something that you see, too?

Just checked, and yes.

> The hack around this that I found and then forgot is hidden in 
> packaging/copr/subsurface.spec:

Removing that package_not works for me too. No idea what/why/how it
gets generated.

   Linus
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Garmin Mk2i - unlikely dive gas

[Dirk Hohndel via subsurface]

> On Jun 13, 2022, at 8:41 AM, Dirk wrote:
> 
>> On Jun 13, 2022, at 5:31 AM, Mark wrote:
>>> 
>>> Ideally we'd figure out which one it is and have you send us just send that 
>>> one file, but that puts the onus on you, if you don't mind sharing the data 
>>> privately, you could simply put ALL of the .FIT files under Garmin/Activity 
>>> on your Mk2i into a .zip file and send it off list to me and then I can 
>>> figure this out here.
>> It's all dives, not just particular ones. Well, all air dives anyway. Have 
>> not confirmed nitrox.  Without having looked into it at all, I'm 
>> hypothesizing something like the Garmin using a flag for air/not-air, and 
>> assigning the O2% a nonsensical value (null/zero) for air dives.
> 
> I have a Garmin Descent Mk2i myself and have done a fair number of air dives 
> with it, so I don't believe this is a general issue.
> But you may have set things up differently compared to the settings on mine - 
> so I'll poke at your .FIT file and find out :)

From your FIT file it seems that you have more than one tank pod connected to 
your Garmin, but only one gas mix defined. That confuses our code a bit and it 
thinks that the second pod is connected to a dive with undefined gas data - and 
then it defaults to air for that.

Do you actually have more than one pod attached? Are you using both? How does 
this look in the on-watch settings?

I'm trying to figure out how to parse this correctly, but since I only have one 
pod, this isn't something I can experiment with here...

/D___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Cylinder list mismatch

[Dirk Hohndel via subsurface]

> On Jun 13, 2022, at 2:26 AM, Jef wrote:
> 
> On 13/06/2022 05:04, Dirk Hohndel via subsurface wrote:
>> A couple of dive computers will import all gases that are configured, even 
>> if you never switched to them. And if you have a default cylinder configured 
>> in Subsurface, then this turns into these ghost cylinders.
> 
> One reason libdivecomputer usually returns all configured gas mixes is 
> because (as Steve mentioned) some users want to see those unused mixes. But 
> it not always consistent, and depends on the backend implementation (*). 
> Maybe it would a good idea to include an enabled/disabled flag to give a bit 
> more information to the application?
> 
> Whether a gas mix is used or unused is something the application can already 
> detect by looking at the gas switches in the samples. But the 
> enabled/disabled state (if present) is not something that is exposed now.
> 
> (*) For example the iconhd backend discards disabled gas mixes, but the ostc 
> and ostc3 backends does report them.

Yeah, I noticed that this wasn't consistent, but didn't feel like this was 
really worth worrying about...
Obviously Subsurface has a concept of unused cylinders and hides those in the 
UI by default. And that's part of the issue here. We don't take that status 
into consideration when filtering dives...

/D
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Garmin Mk2i - unlikely dive gas

[Dirk Hohndel via subsurface]

> On Jun 13, 2022, at 5:31 AM, Mark wrote:
>> 
>> Ideally we'd figure out which one it is and have you send us just send that 
>> one file, but that puts the onus on you, if you don't mind sharing the data 
>> privately, you could simply put ALL of the .FIT files under Garmin/Activity 
>> on your Mk2i into a .zip file and send it off list to me and then I can 
>> figure this out here.
> It's all dives, not just particular ones. Well, all air dives anyway. Have 
> not confirmed nitrox.  Without having looked into it at all, I'm 
> hypothesizing something like the Garmin using a flag for air/not-air, and 
> assigning the O2% a nonsensical value (null/zero) for air dives.

I have a Garmin Descent Mk2i myself and have done a fair number of air dives 
with it, so I don't believe this is a general issue.
But you may have set things up differently compared to the settings on mine - 
so I'll poke at your .FIT file and find out :)

> Was a little bit of a hassle. Mainly from distraction. I've just come back 
> from a dive trip, where I was downloading the FITs onto my laptop and 
> importing them. Now I'm back home I plugged my Garmin into my desktop and 
> started fighting with Garmin USB. On my desktop I've installed drivers using 
> Zadig to import directly into Subsurface, but now Subsurface is the only 
> thing that works - I can no longer connect to my Garmin using MTP or via 
> Garmin Express. Argh, Why can't Garmin make things that play nice? 

This is more a combination of the libraries that I chose to use for MTP 
communication - since we build across Linux, macOS, and Windows, I went for 
something that supports all three OSs to simplify life - and that one requires 
a different driver on Windows. So it seems a wee bit unfair to blame Garmin. 
That's more a Subsurface issue, to be honest.

/D

___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Garmin Mk2i - unlikely dive gas

[Mark Stiebel via subsurface]

When importing from my Garmin Mk2i, I always get a red error bar on 
the bottom of the Subsurface window:

"unlikely dive gas data from libdivecomputer: o2 = 0 he = 0"


And O2 value of 0 is, admittedly, fairly unlikely, wouldn't you say?

O2 value of zero definitely not going to result in a good dive.

It happens after hitting the "Download" button. In all cases the dive 
computer has been set to Air.  Have not dived nitrox since I've bought 
the Garmin. Have thought about setting to 22% and see what happens, 
but have not go around to that yet.


So this is almost certainly a .FIT file on your device that confuses 
our parser.


Ideally we'd figure out which one it is and have you send us just send 
that one file, but that puts the onus on you, if you don't mind sharing 
the data privately, you could simply put ALL of the .FIT files under 
Garmin/Activity on your Mk2i into a .zip file and send it off list to 
me and then I can figure this out here.
It's all dives, not just particular ones. Well, all air dives anyway. 
Have not confirmed nitrox.  Without having looked into it at all, I'm 
hypothesizing something like the Garmin using a flag for air/not-air, 
and assigning the O2% a nonsensical value (null/zero) for air dives.


Obviously there is a risk that some sort of personal data might be 
included in those .FIT files (I seriously don't know exactly what is 
and isn't included in those... they contain the wildest stuff...), but 
I doubt it will be anything more than information about where you did 
exercises (and what exercises you did) and I really don't care about 
any of those things... but likely this will help us figure out what 
causes that annoying error above.
I'll send you a FIT that I've confirmed raises the error (well, warning) 
off list.


Let me know if you need help how to do this (or if you'd rather figure 
out which .FIT file it is and then only send me that... I'm somewhat 
hopeful that I could walk you through how to do that as well)
Was a little bit of a hassle. Mainly from distraction. I've just come 
back from a dive trip, where I was downloading the FITs onto my laptop 
and importing them. Now I'm back home I plugged my Garmin into my 
desktop and started fighting with Garmin USB. On my desktop I've 
installed drivers using Zadig to import directly into Subsurface, but 
now Subsurface is the only thing that works - I can no longer connect to 
my Garmin using MTP or via Garmin Express. Argh, Why can't Garmin make 
things that play nice?


Mark.
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Cylinder list mismatch

[Jef Driesen via subsurface]

On 13/06/2022 05:04, Dirk Hohndel via subsurface wrote:
A couple of dive computers will import all gases that are configured, even if 
you never switched to them. And if you have a default cylinder configured in 
Subsurface, then this turns into these ghost cylinders.


One reason libdivecomputer usually returns all configured gas mixes is because 
(as Steve mentioned) some users want to see those unused mixes. But it not 
always consistent, and depends on the backend implementation (*). Maybe it would 
a good idea to include an enabled/disabled flag to give a bit more information 
to the application?


Whether a gas mix is used or unused is something the application can already 
detect by looking at the gas switches in the samples. But the enabled/disabled 
state (if present) is not something that is exposed now.


(*) For example the iconhd backend discards disabled gas mixes, but the ostc and 
ostc3 backends does report them.


Jef
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface