<div dir="ltr"><div>> 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.<br><br></div><div>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.<br><br></div><div>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.<span class="im"><br><br></span><br><div><br></div>> 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.<br><br></div><div>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.<br><br><br>> 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.<br><br></div><div>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.<br><br><br>> My guess is that this is a rounding error: <a href="http://divelogs.de" target="_blank">divelogs.de</a> uses metric units internally so converting from imperial to metric and back could change the least significant digit.<br><br></div><div>I agree, but this worked in December with 4.4.2 and <a href="http://divelogs.de">divelogs.de</a> 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 <a href="http://divelogs.de">divelogs.de</a>, if others don't see this same behaviour. If <a href="http://divelogs.de">divelogs.de</a> is working in all metric internally though, and subsurface is working internally in metric, doesn't the fact that <a href="http://divelogs.de">divelogs.de</a> still displays the old values correctly indicate this is a problem between the subsurface export to <a href="http://divelogs.de">divelogs.de</a>? Perhaps one or both sides started using a different precision or something?<br><br><br><div>> 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).<br><br></div><div>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.<br></div><div><br></div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Feb 23, 2016 at 3:32 PM, Robert Helling <span dir="ltr"><<a href="mailto:helling@atdotde.de" target="_blank">helling@atdotde.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">Richard,<div><br></div><div>thanks a lot for all your reports/suggestions. I believe I cannot help for many of these but here are some comments:</div><div><br><div><span class=""><blockquote type="cite"><div>On 23.02.2016, at 19:55, Richard Houser <<a href="mailto:rick@divinesymphony.net" target="_blank">rick@divinesymphony.net</a>> wrote:</div><br><div><div dir="ltr"><div><div><div><div><div><div><div>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....<br><br><br></div>Anyhow, here they are...<br><br><br></div>#1 Using 4.5.3 AppImage, I located a segfault on exporting to <a href="http://divelogs.de/" target="_blank">divelogs.de</a>.<br><br>Sequence:<br>(a) I imported a dive from my computer and then added a location<br>(b) I realized I added that location to the wrong dive and removed it, then saved<br>(c) any <a href="http://divelogs.de/" target="_blank">divelogs.de</a> export containing that dive causes a segfault<br><br>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.<br></div></div></div></div></div></div></div></blockquote><div><br></div></span><div>I was not able to reproduce that here on my Mac.</div><span class=""><br><blockquote type="cite"><div><div dir="ltr"><div><div><div><div>#2 The imperial tank sizes appear to have some issues going back to at least 4.4.2....<br><br></div><div>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 :(.<br></div><div><br></div>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.<br><br></div><div>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.): <a href="http://www.xsscuba.com/tank_steel_specs.html" target="_blank">http://www.xsscuba.com/tank_steel_specs.html</a> <br><br></div><div>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.<br></div></div></div></div></div></blockquote><div><br></div></span><div>Let me quote from our source code:</div><div><br></div><div><div style="margin:0px;font-size:11px;line-height:normal;font-family:Menlo"> /* Most common AL cylinders */</div><div style="margin:0px;font-size:11px;line-height:normal;font-family:Menlo"> { "AL40", .cuft = 40, .psi = 3000 },</div><div style="margin:0px;font-size:11px;line-height:normal;font-family:Menlo"> { "AL50", .cuft = 50, .psi = 3000 },</div><div style="margin:0px;font-size:11px;line-height:normal;font-family:Menlo"> { "AL63", .cuft = 63, .psi = 3000 },</div><div style="margin:0px;font-size:11px;line-height:normal;font-family:Menlo"> { "AL72", .cuft = 72, .psi = 3000 },</div><div style="margin:0px;font-size:11px;line-height:normal;font-family:Menlo"> { "<span style="color:#ffffff;background-color:#000000">AL80</span>", .cuft = 80, .psi = 3000 },</div><div style="margin:0px;font-size:11px;line-height:normal;font-family:Menlo"> { "AL100", .cuft = 100, .psi = 3300 },</div><div style="margin:0px;font-size:11px;line-height:normal;font-family:Menlo;min-height:13px"><br></div><div style="margin:0px;font-size:11px;line-height:normal;font-family:Menlo"> /* Metric AL cylinders */</div><div style="margin:0px;font-size:11px;line-height:normal;font-family:Menlo"> { "ALU7", .ml = 7000, .bar = 200 },</div><div style="margin:0px;font-size:11px;line-height:normal;font-family:Menlo;min-height:13px"><br></div><div style="margin:0px;font-size:11px;line-height:normal;font-family:Menlo"> /* Somewhat common LP steel cylinders */</div><div style="margin:0px;font-size:11px;line-height:normal;font-family:Menlo"> { "LP85", .cuft = 85, .psi = 2640 },</div><div style="margin:0px;font-size:11px;line-height:normal;font-family:Menlo"> { "LP95", .cuft = 95, .psi = 2640 },</div><div style="margin:0px;font-size:11px;line-height:normal;font-family:Menlo"> { "LP108", .cuft = 108, .psi = 2640 },</div><div style="margin:0px;font-size:11px;line-height:normal;font-family:Menlo"> { "LP121", .cuft = 121, .psi = 2640 },</div><div style="margin:0px;font-size:11px;line-height:normal;font-family:Menlo;min-height:13px"><br></div><div style="margin:0px;font-size:11px;line-height:normal;font-family:Menlo"> /* Somewhat common HP steel cylinders */</div><div style="margin:0px;font-size:11px;line-height:normal;font-family:Menlo"> { "HP65", .cuft = 65, .psi = 3442 },</div><div style="margin:0px;font-size:11px;line-height:normal;font-family:Menlo"> { "HP80", .cuft = 80, .psi = 3442 },</div><div style="margin:0px;font-size:11px;line-height:normal;font-family:Menlo"> { "HP100", .cuft = 100, .psi = 3442 },</div><div style="margin:0px;font-size:11px;line-height:normal;font-family:Menlo"> { "HP119", .cuft = 119, .psi = 3442 },</div><div style="margin:0px;font-size:11px;line-height:normal;font-family:Menlo"> { "HP130", .cuft = 130, .psi = 3442 },</div></div><div><br></div>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.</div><div><span class=""><br><blockquote type="cite"><div><div dir="ltr"><div><div><div>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.<br></div></div></div></div></div></blockquote><div><br></div></span><div>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.</div><span class=""><br><blockquote type="cite"><div><div dir="ltr"><div><div><div>#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.</div></div></div></div></div></blockquote><div><br></div></span><div>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.</div><span class=""><br><blockquote type="cite"><div><div dir="ltr"><div><div>#4 Dives exported from subsurface to <a href="http://divelogs.de/" target="_blank">divelogs.de</a> 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 <a href="http://divelogs.de/" target="_blank">divelogs.de</a> and see what happens between those two different versions.</div><div><br></div></div></div></div></blockquote><div><br></div></span><div>My guess is that this is a rounding error: <a href="http://divelogs.de" target="_blank">divelogs.de</a> uses metric units internally so converting from imperial to metric and back could change the least significant digit.</div><span class=""><br><blockquote type="cite"><div><div dir="ltr"><div><div>#5 Feature Request: Any chance of getting a boat field added?</div><br>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.<br><br></div></div></div></blockquote><div><br></div></span><div>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.</div><span class=""><div><br></div><blockquote type="cite"><div><div dir="ltr">#6 Feature Request: Any chance of getting a SAC graph option?<br><br>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.<br></div></div></blockquote><br></span></div><div>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).</div><div><br></div><div>Best</div><span class="HOEnZb"><font color="#888888"><div>Robert</div><br></font></span></div></div></blockquote></div><br></div>