Re: 5.0.6 released and some other news

[William Perry via subsurface]

If you need other M1 testers or folks to try out replicating builds, I also 
just got one of the 13” M1 Pros courtesy of work.

-bill

> On Feb 2, 2022, at 2:27 PM, Dirk Hohndel via subsurface 
>  wrote:
> 
> In theory this should mean that I have more time to spend on Subsurface for a 
> while. We'll see how that goes. One thing that I did do to get myself 
> motivated to work on stuff is that I bought a Mac with an m1 processor... 
> having one of those in front of me hopefully will motivate me to tackle all 
> the missing pieces to get that working... and of course there are a million 
> other things in the back log that won't result in new features, but in 
> extending the life of the things that we already have working today.
> 

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

Re: Statistics code for desktop (and soon mobile)

[William Perry via subsurface]

Are there cool ‘recipes’ that should be available by default?   SAC rate
over time binned by water temperature, things like that?

-bill

On Fri, Jan 8, 2021 at 5:25 PM Christof Arnosti via subsurface <
subsurface@subsurface-divelog.org> wrote:

> Same here. I just did give it a second go with the current AppImage (which
> works perfectly now). I didn't find anything "buggy" and there isn't much
> to complain about (the most German compliment ever). I like it! :-)
>
> I don't have too many dives (86), and everything is open circuit, so it's
> maybe a bit harder to get interesting statistics, but I did find:
>
>- My SAC sucks and didn't get much better over the years, but gets
>better at the end of the holidays. And less SAC in warmer water (makes
>sense, but I didn't think about it before I played around here)
>- Dives with a higher max depth are shorter (duh)
>- Buddy counts (Interesting!), total and over the years.
>- In my first year I had a suspicious high number of dives reaching
>exactly 18 meters...
>- And lots of other interesting insights.
>
> It's really a nice feature to play around! But now I want to go diving :-(
>
> Some Questions and remarks:
>
>- When I select date(yearly) as base variable and buddies as data, bar
>charts have a yellow warning in the drop down. Why's that?
>- The trend line does not always appear in the scatter graph. For
>example, when I select date (no binning) / depth, there is no trend line,
>except for when I filter out very shallow depths. For water temp over date
>I get a trend line right away. I'm sure that's correct and there is a
>statistical reason for this that I'm not aware of.
>- When I select Buddies over Date(yearly), and then grouped vertical
>bar chart, the bars are oddly spaced. I suspect that for every buddy there
>is a bar every year, even if the number is zero. This might make sense in
>some cases (for example water temperature), but in the buddy case it looks
>weird. Maybe add some "don't show empty bars" option for the grouped bar
>charts?
>- Is there some Export functionality planned? For example simple image
>export of the graph?
>- For me the Filter GUI seems a bit unintuitive. When there is no
>constraint present, it's not very obvious that constraints can be added
>(the button is in an odd place). A change to make it more obvious could be
>to add a "Constraints" heading below the fulltext search, and move the
>button there? And maybe also display a "No constraints" text when no
>constraint is set? I really like the "Filter sets" functionality!
>- What I didn't find was an "Average depth" variable, this would maybe
>also be interesting to add.
>- "Dive number" as Base Variable would maybe make sense to show
>changes over number of dives. This would be interesting for me since I go
>diving once or maybe twice a year, so when I use non-binned date as base
>variable, there are basically vertical lines in the scatter plot (see
>below).
>
> What would be really nice, but might be complicated to implement, would be
> to have a kind of "Zoom" or "Select" possibility to add constraints. For
> example my Depth over Date Scattergraph looks like this:
>
> Now to have a look at a single holiday I can add a constraint over a range
> of dates, for example 1.1.2017 to 1.1.2018. This works fine! But the cherry
> on top would be if I could simply drag a rectangle over the points in 2017,
> and set the constraints like this (Sort of a "Zoom into range"
> functionality).
>
> Best regards
>
>
> Christof
> On 08.01.21 21:42, Martin de Weger via subsurface wrote:
>
> I have played with it a bit, and it looks great. I haven’t looked into it
> deep enough to say I actually tested it.
>
>
> Op 8 jan. 2021 om 21:33 heeft Dirk Hohndel via subsurface
>  
> het volgende geschreven:
>
> 
>
> On Jan 3, 2021, at 5:17 PM, Dirk Hohndel  wrote:
>
>
>
> On Jan 3, 2021, at 3:44 PM, Dirk Hohndel via subsurface <
> subsurface@subsurface-divelog.org> wrote:
>
> Right, I didn't test the AppImage. Silly me. I'll add that to my list.
>
>
> AppImage is fixed, also Subsurface now reacts more gracefully if the
> QtCharts QML modules can't be found.
> Instead of a crash the statistics chart is simply empty. What we really
> need is a reasonable error message (or alternative disable the statistics
> entry in the menu.
> But this is at least a step in the right direction.
>
> New AppImage should appear in downloads/test in the next few minutes
> as Subsurface-v4.9.10-235-gc63994f77-x86_64.AppImage
> This one was tested on a couple of different Linux flavors...
>
>
> So we have working binaries for all platforms, but we have heard basically
> no feedback on the new statistics feature.
> No indication that anyone has tested this, likes it, hates it, has
> suggestions.
>
> It's really hard to develop in a vacuum. And it's a bit frustrating, too.
>
> I 

Re: Statistics code for desktop (and soon mobile)

[William Perry via subsurface]

I ran some quick tests on OS X - looks very nice.  I will do some more piddling 
around this weekend between dives and see if I can get some of the other folks 
I’m diving with to give it a spin as well.

-bill

> On Jan 8, 2021, at 3:42 PM, Martin de Weger via subsurface 
>  wrote:
> 
> I have played with it a bit, and it looks great. I haven’t looked into it 
> deep enough to say I actually tested it. 
> 
>> 
>> Op 8 jan. 2021 om 21:33 heeft Dirk Hohndel via subsurface 
>>  het volgende geschreven:
>> 
>> 
>> 
>>> On Jan 3, 2021, at 5:17 PM, Dirk Hohndel >> > wrote:
>>> 
>>> 
>>> 
 On Jan 3, 2021, at 3:44 PM, Dirk Hohndel via subsurface 
 >>> > wrote:
 
 Right, I didn't test the AppImage. Silly me. I'll add that to my list.
>>> 
>>> AppImage is fixed, also Subsurface now reacts more gracefully if the 
>>> QtCharts QML modules can't be found.
>>> Instead of a crash the statistics chart is simply empty. What we really 
>>> need is a reasonable error message (or alternative disable the statistics 
>>> entry in the menu.
>>> But this is at least a step in the right direction.
>>> 
>>> New AppImage should appear in downloads/test in the next few minutes as 
>>> Subsurface-v4.9.10-235-gc63994f77-x86_64.AppImage
>>> This one was tested on a couple of different Linux flavors...
>> 
>> So we have working binaries for all platforms, but we have heard basically 
>> no feedback on the new statistics feature.
>> No indication that anyone has tested this, likes it, hates it, has 
>> suggestions.
>> 
>> It's really hard to develop in a vacuum. And it's a bit frustrating, too.
>> 
>> I know that guilt-tripping people into doing things simply doesn't work. 
>> Berthold, Willem, and I will continue to just work along.
>> But we sure would appreciate some input. Even if it is just a simple "this 
>> is the best software ever written in the universe"...
>> 
>> Thanks and have a great weekend
>> 
>> /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

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

Re: G2 HUD support?

[William Perry]

Verified that ‘btName' at this point contains only the string ‘HUD’.  Because 
surely nobody would ever create another HUD dive computer that works over 
bluetooth.

-bill

> On Apr 25, 2019, at 10:56 AM, William Perry  wrote:
> 
> With Jef’s changes to libdivecomputer I was able to download over USB just 
> fine.  The bluetooth seems a little iffy - I was able to download after 
> forcing it into LE mode.  It looks like the bluetooth device name starts with 
> ‘HUD’:
> 
> diff --git a/core/btdiscovery.cpp b/core/btdiscovery.cpp
> index 7e75994da..c057abd8b 100644
> --- a/core/btdiscovery.cpp
> +++ b/core/btdiscovery.cpp
> @@ -56,9 +56,10 @@ static dc_descriptor_t *getDeviceType(QString btName)
>   product = "EON Core";
>   }
> 
> - if (btName.startsWith("G2")  || btName.startsWith("Aladin")) {
> + if (btName.startsWith("G2")  || btName.startsWith("Aladin") || 
> btName.startsWith("HUD")) {
>   vendor = "Scubapro";
>   if (btName.startsWith("G2")) product = "G2";
> + if (btName.startsWith("HUD")) product = "G2 HUD";
>   if (btName.startsWith("Aladin")) product = "Aladin Sport 
> Matrix";
>   }
> 
> 
> 
> -bill
> 
>> On Apr 25, 2019, at 8:49 AM, William Perry  wrote:
>> 
>> I have a build of subsurface with your changes in it and will be spending 
>> the day at the quarry.  Will see if I can snag the HUD while I am down there.
>> 
>> -Bill
>> 
>>> On Apr 24, 2019, at 10:58 AM, Jef Driesen  wrote:
>>> 
>>> On 2019-04-23 22:32, Linus Torvalds wrote:
>>> 
>>>> Have you found where the GPS coordinates might be? The G2 HUD
>>>> allegedly supports GPS.
>>>> (Btw, right now we export GPS information with the extra-string
>>>> interface, but it would actually be much better to have an actual GPS
>>>> event. No, they won't happen under water, but in addition to the
>>>> beginning/end they can happen in the middle of the dive when
>>>> surfacing, so an event with a timestamp etc would be really useful).
>>> 
>>> No, I didn't look for the GPS info. Since the Uwatec data format uses a 
>>> type/value encoding for the sample data and I didn't notice a new type, the 
>>> only place where GPS info can be stored is in the MISC sample. I have seen 
>>> some unknown subtypes before. A quick check shows there are indeed some 
>>> unknown subtypes present in the G2 HUD data:
>>> 
>>> Unknown misc sample with type 24 and length 3.
>>> Unknown misc sample with type 16 and length 91.
>>> Unknown misc sample with type 17 and length 67.
>>> 
>>>>> I have the necessary fixes ready to push.
>>>> Apparently they aren't out yet, but I'll merge them when they are and
>>>> we can get testing going.
>>> 
>>> I have pushed the changes now.
>>> 
>>> Jef
>> 
> 

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

Re: G2 HUD support?

[William Perry]

I will triple check, but I was only seeing “HUD” in the debugger.

-bill

On Thu, Apr 25, 2019 at 12:04 PM Linus Torvalds <
torva...@linux-foundation.org> wrote:

> On Thu, Apr 25, 2019 at 7:56 AM William Perry  wrote:
> >
> > With Jef’s changes to libdivecomputer I was able to download over USB
> just fine.  The bluetooth seems a little iffy - I was able to download
> after forcing it into LE mode.  It looks like the bluetooth device name
> starts with ‘HUD’:
>
> I'd rather match the whole name. Is it really *just* "HUD", or is it
> perhaps something like "HUD G2" or whatever?
>
> But even the partial name matching is better than none, of course.
>
> Linus
>
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: G2 HUD support?

[William Perry]

I have a build of subsurface with your changes in it and will be spending the 
day at the quarry.  Will see if I can snag the HUD while I am down there.

-Bill

> On Apr 24, 2019, at 10:58 AM, Jef Driesen  wrote:
> 
> On 2019-04-23 22:32, Linus Torvalds wrote:
> 
>> Have you found where the GPS coordinates might be? The G2 HUD
>> allegedly supports GPS.
>> (Btw, right now we export GPS information with the extra-string
>> interface, but it would actually be much better to have an actual GPS
>> event. No, they won't happen under water, but in addition to the
>> beginning/end they can happen in the middle of the dive when
>> surfacing, so an event with a timestamp etc would be really useful).
> 
> No, I didn't look for the GPS info. Since the Uwatec data format uses a 
> type/value encoding for the sample data and I didn't notice a new type, the 
> only place where GPS info can be stored is in the MISC sample. I have seen 
> some unknown subtypes before. A quick check shows there are indeed some 
> unknown subtypes present in the G2 HUD data:
> 
> Unknown misc sample with type 24 and length 3.
> Unknown misc sample with type 16 and length 91.
> Unknown misc sample with type 17 and length 67.
> 
>>> I have the necessary fixes ready to push.
>> Apparently they aren't out yet, but I'll merge them when they are and
>> we can get testing going.
> 
> I have pushed the changes now.
> 
> Jef

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

Re: Scubapro Galileo 2 (G2)

[William Perry]

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.

-bill

On Fri, Jun 9, 2017 at 1:29 AM Linus Torvalds 
wrote:

> On Wed, Jun 7, 2017 at 8:17 AM, CZS  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
> ___
> devel mailing list
> de...@libdivecomputer.org
> http://libdivecomputer.org/cgi-bin/mailman/listinfo/devel
>
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: [PATCH] Poseidon MK6 import

[William Perry]

I can probably get my instructor to run a download against a bunch of 
shearwaters or Nitek Qs with the 4th cell monitoring if we need test data for 
subsurface or libdivecomputer.

Maybe I can convince my wife that I need to buy the rebreather a bit earlier 
than planned so I can help… :)

-bill

 On Oct 27, 2014, at 11:23 AM, Paul Sargent paul.lions...@icloud.com wrote:
 
 
 
 On Oct 27, 2014, at 03:34 PM, Dirk Hohndel d...@hohndel.org wrote:
 
 Good morning...
 
 On Mon, Oct 27, 2014 at 08:42:12AM +0100, Robert Helling wrote:
   Robert appears to have stepped up to help our Willem to get this right,
   but the more people work on this and help figure out what's the right way
   to do things, the better.
  
  indeed, more people needed here. I cannot say I have any sort of
  overview about the recently added CCR functionality. I have only only
  spent some time on debugging to make sure features that worked before
  got unbroken again. And of course, I don’t dive rebreathers myself
  (currently I am not diving anything unfortunately, stupid flu!) so all
  my knowledge is from hearsay anyway.
 
 So who are the rebreather divers besides Willem who are helping to get
 this right and are especially testing this as thoroughly as possible.
 
 I'd hate to release 4.3 and announve rebreather support and then have to
 say never mind...
  
 I'm certainly happy to look over as much as I can, but it's limited by what I 
 can exercise from my dive data. As far as I can tell a number of the patches 
 recently deal with utilising ppO2 data from the sensors, and the only unit we 
 can import ppO2 data from is a MkVI. I don't dive a MkVI, so whilst I can 
 test planning CCR dives, or imported constant ppO2 CCR dives from an OSTC, I 
 can't exercise everything.
 
 Let me know what you'd like me to attack ;-)
 
 Paul
 
 
 
 ___
 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: Two more rebreather patches

[William Perry]

 On Oct 27, 2014, at 10:42 AM, Rodrigo Severo rodr...@fabricadeideias.com 
 wrote:
 
 On Mon, Oct 27, 2014 at 12:37 PM, William Perry wmpe...@kadath.us wrote:
 
 I just finished  by CCR training down in Bonaire last week so I don’t have a
 lot of experience, but I did find that minor depth changes did not impact
 the loop volume enough for me to feel the need to add diluent.  My inhale
 was cut very slightly short (I was diving with the auto-diluent-valve off
 after the initial big descent).  This would be equivalent to the occasional
 mask clear at depth.  If you are doing a ton of 10 meter ascents/descents in
 a cave system as it winds around then those will add up quickly, but 1-2
 footers is noise.
 
 Bill,
 
 
 I agree: 1/2 foot is noise, 10 m is significant.
 
 What value do you think we should use as limit? I just proposed 1 m on
 my previous email to Robert but I'm not sure if this value is big
 enough.
 
 What do you think?

Maybe start tracking it if they stay at the new depth for more than a certain # 
of samples?  If I just drop down quickly to look at something I’m not going to 
mind a short breath or two but if I am following the contour of the reef and 
stay at that depth for 5-10 minutes I will probably squirt in some diluent.  
I’m generally not a fan of heuristics like that though.

 Would tracking only the size of the counter lungs be sufficient?
 
 I don't think any of this is necessary, neither counter lungs volume
 nor loop volume as I mentioned on my previous email.

Yes, if we are just worrying about determining a SAC rate after the fact.  
Would some indication of loop volume help for planning these dives though?

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