New Bug Reports/Feature Requests

[Richard Houser]

> The weight of the metal changes at least for different manufacturers so
unless you weight your cylinder, which value are you going to use? The
weight of the gas is of course always the same.

Well, the weight of the metal itself isn't so important, but rather the
bouyancy when switching between tanks.  These are published for each tank,
however, and they will be in a similar ballpark at least between
manufacturers.  For example with valve, an empty HP 120 PST is about -1.3,
Worthington is about -2 and a Faber is -0.65.  Pick a center point and that
whole range is less than 1lb +/- for the range of tanks.

My LP72 comes in about neutral, and my AL80 is around +4.4lb.  I just think
it would be really helpful to have that information on the same equipment
page with the rest of the weighting, so it's less mental math and manual
notes to figure out what all went into a dive (including which pony bottle,
etc.) to adapt that portion of the weighting back to something usable for
other dives with different details.



> As you see, we indeed use the nominal sizes even though they are not
exact. We had a discussion in the past (but I am not able to find it either
in the mailing list archives or trac) if we should use the „real“ values as
shown on that web page but ended up the conclusion that that would actually
be even more confusing.

In my classes back in Michigan, and during checkout dives I witnessed as a
bystander in Ohio and Florida, instructors with at least 5 different shops
(SSI/PADI/NAUI) have explicitly reminded students that when doing their
logs, air capacity in an AL80 is 77cuft, NOT 80.  So, the software's
insistence on using incorrect values even after I correct it in earlier
dives would seem to be more confusing overall.  Granted, this might be
partially a Midwest USA style teaching thing (much of Florida is the
midwest region transplanted to warmer climate).  If someone has already
changed a capacity for these in their logs, perhaps the easier compromise
is to respect any earlier correction in the log and not default back to the
nominal/incorrect capacities from the source?  That way, it would have no
effect on someone that doesn't understand how the cylinders are named, and
they would continue to have the incorrect numbers, but other users wouldn't
be affected?  Any potential bouyancy field could potentially do the same.


> A field is only changed when the keyboard focus leaves it (changing it
with every keystroke would have strange side effects as you would end up
with strange values in the middle of typing a number). But you can for
example use the TAB key if you don’t want to change to the mouse.

This is exactly what I experienced, but I argue that is an aspect of bad UI
design.  The workaround of clicking or tabbing to another field shouldn't
be neccessary, IMO.  As a user, when I select save, I expect it to save.
Discarding portions of what I entered breaks the contract with of the user
of what a Save operation does.  Hitting save at any point should not result
in data loss from what the user has on the screen.  The ideal behaviour,
IMO, would be to commit any outstanding changes a user has made to the
current field prior to committing that data, like other desktop
applications do.


> My guess is that this is a rounding error: divelogs.de uses metric units
internally so converting from imperial to metric and back could change the
least significant digit.

I agree, but this worked in December with 4.4.2 and divelogs.de at that
time.  It certainly looks like a regression, but I can go back and confirm
it's on the Subsurface side by re-exporting old dives in 4.5.3 and 4.4.2
once I return from my trip and match it up to divelogs.de, if others don't
see this same behaviour.  If divelogs.de is working in all metric
internally though, and subsurface is working internally in metric, doesn't
the fact that divelogs.de still displays the old values correctly indicate
this is a problem between the subsurface export to divelogs.de?  Perhaps
one or both sides started using a different precision or something?


> Do you realize that the color of the depth graph is already a
representation of the momentary SAC? Given the resolution of the pressure
sensor I guess it would make little sense to present finer granularity than
a color coding (there is only very limited numerical precision).

I did not (thanks for pointing it out), but my logs (Aeris A300 CS - aka
Oceanic VTX) seem to imply I have at least 1psi resolution.  I think this
would be plenty to give a useful graph of the SAC calculations as well as a
smoothed out rolling SAC average over the last 4 samples or something (with
presentation similar to the average depth of the dive thus far
calculation).  If I had a less accurate computer, I would certainly expect
a little more noise in any calculations, like I currently do with the 1
degree resolution of the temperature sensor.



On Tue, Feb 23, 2016 at 3:32 PM, Robert Helling <helling at atdotde.de> wrote:

> Richard,
>
> thanks a lot for all your reports/suggestions. I believe I cannot help for
> many of these but here are some comments:
>
> On 23.02.2016, at 19:55, Richard Houser <rick at divinesymphony.net> wrote:
>
> First off, I'd just like to say I thin Subsurface is an amazing piece of
> software and far superior to the proprietary crap manufacturers push out
> (kodos to you all), so please don't interpret this as a rant by any means.
> I would have submitted these tickets directly, but the email verification
> message still isn't coming through from the bug tracker.  If someone was to
> "validate" this same email that was already confirmed via the mailing list,
> I could submit these as tickets directly myself....
>
>
> Anyhow, here they are...
>
>
> #1 Using 4.5.3 AppImage, I located a segfault on exporting to divelogs.de.
>
> Sequence:
> (a) I imported a dive from my computer and then added a location
> (b) I realized I added that location to the wrong dive and removed it,
> then saved
> (c) any divelogs.de export containing that dive causes a segfault
>
> Looking through the XML (which I no longer have - sorry!), it looked like
> the dive was still associated to a location in the top of the xml, but that
> entry had no location text.  Shutting down subsurface, deleting that
> particular id attribute on the dive and then restarting the application let
> me complete the export.  I would think the correct behavior when someone
> removes the location text from then Notes tab and saves would be to
> automatically remove the association with that site entirely.
>
>
> I was not able to reproduce that here on my Mac.
>
> #2 The imperial tank sizes appear to have some issues going back to at
> least 4.4.2....
>
> It looks like someone used to metric tanks may have just taken the names
> of the cylinders and assumed that matched the capacity?  Sadly our stuff
> doesn't work that way :(.
>
> AL80 in particular stood out.  Despite the name, these are ~77.4cuft
> capacity when filled to working pressure of 3000.  It would be nice if we
> could get a tenth position added for precision, but the big problem is the
> bad default.  I have to edit each and every dive after selecting AL80 at
> present.
>
> The steel tanks seem to have a similar problem, but a subset of the more
> common sizes just happen to match up.  For example, my Faber XS-120 is
> close enough to 120 to look like a round off error.  However, things like
> the HP119 are significantly off.  This should give you a good idea what I'm
> talking about: (ex.): http://www.xsscuba.com/tank_steel_specs.html
>
> Older tanks might be a bit more complicated, but at least LP72s (6.9") are
> still pretty common.  I have one and it's rated at 65cuft at 2250 working
> pressure - (when over-filled by 10% as allowed by hydro + rating that only
> some hydro facilities will check and stamped, that gets you up to 71cuft).
> The default values listed seem to be 2466 psi, which I don't see a
> reference to anywhere, although it's close to an overfill rating it
> probably won't trash SAC calculations, but it's still a bit off.  It's
> definitely not the stamped rated pressure, though.
>
>
> Let me quote from our source code:
>
>         /* Most common AL cylinders */
>         { "AL40", .cuft = 40, .psi = 3000 },
>         { "AL50", .cuft = 50, .psi = 3000 },
>         { "AL63", .cuft = 63, .psi = 3000 },
>         { "AL72", .cuft = 72, .psi = 3000 },
>         { "AL80", .cuft = 80, .psi = 3000 },
>         { "AL100", .cuft = 100, .psi = 3300 },
>
>         /* Metric AL cylinders */
>         { "ALU7", .ml = 7000, .bar = 200 },
>
>         /* Somewhat common LP steel cylinders */
>         { "LP85", .cuft = 85, .psi = 2640 },
>         { "LP95", .cuft = 95, .psi = 2640 },
>         { "LP108", .cuft = 108, .psi = 2640 },
>         { "LP121", .cuft = 121, .psi = 2640 },
>
>         /* Somewhat common HP steel cylinders */
>         { "HP65", .cuft = 65, .psi = 3442 },
>         { "HP80", .cuft = 80, .psi = 3442 },
>         { "HP100", .cuft = 100, .psi = 3442 },
>         { "HP119", .cuft = 119, .psi = 3442 },
>         { "HP130", .cuft = 130, .psi = 3442 },
>
> As you see, we indeed use the nominal sizes even though they are not
> exact. We had a discussion in the past (but I am not able to find it either
> in the mailing list archives or trac) if we should use the „real“ values as
> shown on that web page but ended up the conclusion that that would actually
> be even more confusing.
>
> Adding full/empty buoyancy stats to the cylinder page would be really
> useful, IMO, as we can't always control what we get with rental tanks.  I
> was on HP100s one day, AL80s the next, etc.
>
>
> The weight of the metal changes at least for different manufacturers so
> unless you weight your cylinder, which value are you going to use? The
> weight of the gas is of course always the same.
>
> #3 When I'm editing the cylinder sizes (and I assume all over the place
> elsewhere), I have to enter the tank type, then select the volume, then
> make the change, then click off somewhere else unrelated, then save.  If I
> leave off that second to last step, then save, it reverts to the old
> value.  I think that when a save is attempted, the equivalent field save
> action of clicking out should be done automatically in the background so
> the last change is not lost.
>
>
> A field is only changed when the keyboard focus leaves it (changing it
> with every keystroke would have strange side effects as you would end up
> with strange values in the middle of typing a number). But you can for
> example use the TAB key if you don’t want to change to the mouse.
>
> #4 Dives exported from subsurface to divelogs.de are now showing an
> additional 0.1lb more than what they show in subsurface.  My dives as of
> early September on 4.4.2 (from Mageia cauldron) are correct, but all dives
> I have done this February on 4.5.3 have the extra 0.1lb.  I'm guessing this
> subsurface is a regression post 4.4.2, but if it's not obvious, I could
> back things up after this trip, delete them from divelogs.de and see what
> happens between those two different versions.
>
>
> My guess is that this is a rounding error: divelogs.de uses metric units
> internally so converting from imperial to metric and back could change the
> least significant digit.
>
> #5 Feature Request: Any chance of getting a boat field added?
>
> I'm looking for something like we have for Buddy and Divemaster.  Captain
> (in some areas, they bounce around a lot between organizations) or dive
> operation/charter organization might be useful too.
>
>
> You can of course always enter what you like in the notes field.
> Alternatively use one of the existing fields for this (I for example never
> use the dive master field so I could use that for boat information if I
> wanted). The UI is already quite crowded so I think it is unlikely that we
> will add further fields lightly.
>
> #6 Feature Request: Any chance of getting a SAC graph option?
>
> I think it would be useful to see where breathing went up, in particular
> paired with other events there, like timestamped photos and other trackable
> events.  In particular, on one of my recent dives, I added about 25-30lb of
> weight on the bottom.  It would be nice to see how much something like that
> acquisition or chasing an elusive lobster actually cost me in bottom time.
>
>
> Do you realize that the color of the depth graph is already a
> representation of the momentary SAC? Given the resolution of the pressure
> sensor I guess it would make little sense to present finer granularity than
> a color coding (there is only very limited numerical precision).
>
> Best
> Robert
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20160223/a95b126f/attachment-0001.html>