Re: Windows 32 and 64 bit

[Richard Houser via subsurface]

The last 32-bit mainstream Intel processor was a 2002 era Pentium-4,
right?  AMD switched earlier.

> the likely overlap between people with a $1200+ brand new dive computer and
a 32bit Windows machine is... small.

I'm thinking the overlap is probably higher than you think.  A lot of
people with plenty of disposable income have stopped using PCs
entirely, switching entirely to tablets and phones.  There really
weren't many viable options in that space back in 2002, hence a
traditional PC.

My gut tells me that these same individuals are likely using
phones/tablets most of the time, however.  The chances of one of those
Windows users having only a 32-bit only PC and no compatible
phone/tablet is likely vanishingly small.  As long as that device
works on mobile, it's probably a non-issue, provided advance notice is
given.

On Thu, Oct 29, 2020 at 6:57 PM Dirk Hohndel via subsurface
 wrote:
>
> I'm considering moving our default Windows build to 64bit - it's 2020 after 
> all.
> Some studying of the information I can get from the people who have enabled 
> the update
> notifications tells me that we still have at least 50 users running Windows 
> on actual 32bit
> hardware - so below 1% of our Windows user base (but the number could be 
> higher if a
> lot of 32bit Windows users have disabled the update check).
>
> Either way, I think that's too many to completely drop having a 32bit binary, 
> but it certainly
> seems to make it reasonable to switch to 64bit by default.
>
> One thing that is triggering this is that I am having problems getting a 
> working libmtp
> build on a 32bit MXE build. It's entirely possible that that's simply my own 
> fault, but
> oddly the moment I tried a 64bit build it worked...
> Of course we only need libmtp (so far) for the brand new Garmin Descent 
> Mk2/Mk2i,
> and the likely overlap between people with a $1200+ brand new dive computer 
> and
> a 32bit Windows machine is... small.
>
> Curious to hear people's thoughts.
>
> /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

Re: Importing from two computers with air pressure sensors

[Richard Houser via subsurface]

Would this be a simple enough check?:

IF (start/end pressure are BOTH within X% of an existing cylinder) THEN
treat as the same, ELSE add as new?






On Fri, Jun 12, 2020, 15:17 Dirk Hohndel via subsurface <
subsurface@subsurface-divelog.org> wrote:

> Not something we have ever considered as a use case. If you have four
> different gas mixes, it should work. If some of the tanks have the same
> mix, it will assume that you are importing the same dive with the same two
> tanks from two different computers (as many of us dive with one or more
> backup computers, and many of us have redundant tank pressure sensors).
>
> I haven't thought about how this could be handled differently. And I am
> absolutely loath to add anything for such an extreme corner case to the
> mobile app. I'm not convinced that this is something that I would want to
> support on the desktop app, tbh.
>
> /D
>
> On Jun 12, 2020, at 11:56 AM, John Smith  wrote:
>
> 
> I have two Shearwaters that can record gas pressure, so in theory can
> monitor four cylinders at the same time.
>
> If I import using my ipad, the first download adds two cylinders to the
> dive (cylinder 1+2), correctly giving the start and end pressure. When I
> download the second DC, the dives merge automatically, but instead of
> having four cylinders, (adding 3 + 4)subsurface overwrites cylinder 1 +2
> information.
>
> This is after downloading DC 1
>
>
> Then this after adding DC2.
>
>
>
> The profile drawing also has issues - the pressure trails don’t match the
> data page
>
>
>
> Regards
> ___
> 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: fundamental design issues with trips and dives

[Richard Houser]

Agreed.  It's just an arbitrary container.

Consider the less crazy case of going on a trip with a group near West Palm 
Florida for example.  They aren't die hard divers, but have 6 dives spread 
across a week.  It's still a dive trip.

Then you hear a college buddy is in-state on vacation, and arrange a couple 
extra dives in a cave up-state.  This is all happening while everyone else is 
out doing land based activities.  That's also a dive trip, and the two overlap.

I could even see the case with the above example of a dive being in two 
different trips if two groups overlapped at the same dive site, but that's 
pushing an edge case

On November 7, 2019 12:40:04 PM EST, Linus Torvalds 
 wrote:
>On Thu, Nov 7, 2019 at 9:17 AM Dirk Hohndel  wrote:
>>
>> (4) ??? other ideas?
>
>Stop thinking that dates have anything to do with dive trips.
>
>A dive is in a trip. A trip is just a container. The date is
>completely and utterly irrelevant, and has nothing to do with what
>trip a dive is.
>
>The *only* thing the date is used for trip-wise is the initial
>heuristic of which trip to put a dive in (or whether to create a new
>trip). Nothing else.
>
>Anything that believes that trips are anything but collections of
>random dives is fundamentally broken.
>
>  Linus
>___
>subsurface mailing list
>subsurface@subsurface-divelog.org
>http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: replacement android tablet for subsurface ftdi download

[Richard Houser]

Kindle Fire HDX 3rd gen is the latest model that supports custom firmwares 
(LineageOS, Google Play Store, etc.), and that doesn't support USB-OTG.  The 
newer generations may have the hardware, but are locked down.

On February 8, 2019 8:46:04 AM EST, Chris Shelley  
wrote:
>I had a Hudl which was great and I could use FTDI to access my suunto
>s4i whilst away from home. However , that’s now dead and I’m looking
>for another option. I already have an iPad so I’m not looking for an
>expensive replacement such as the Samsung’s.
>
>My requirement is for a cheap (sub $200 would be good) tablet which
>allows access to my suunto and ideally also has Bluetooth LE so I can
>also download from my shearwaters.
>
>Is anyone using a Kindle Fire? Does anyone know if you can access FTDI
>with it? 
>
>Thanks
>
>
>Sent from my iPad
>___
>subsurface mailing list
>subsurface@subsurface-divelog.org
>http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: who has BLE dive computers - which one, which OSs can you test

[Richard Houser]

App installed, but I need a couple days to get back to the dive computer and 
copy off my last dives first.

Please keep in mind that I also have desktop Linux access, if any of that 
tooling could be more beneficial than the android side.  I'd also be willing to 
schedule some time for SSH access to a desktop in range and sit around to 
manipulate the dive computer on demand if it would help, too.

On September 19, 2017 1:54:35 PM EDT, Dirk Hohndel <d...@hohndel.org> wrote:
>
>> On Sep 19, 2017, at 9:08 AM, Richard Houser <r...@divinesymphony.net>
>wrote:
>> 
>> Aeris A300CS (understood no support yet)
>
>I know that Linus has this same dive computer and started looking at
>supporting
>it but ran out of time. It would be great to add it... can you install
>"nRF Connect"
>on your Android device, connect to the A300CS and send a screen shot of
>the
>services that it offers? You have to tap on the name of the service to
>then get
>to the characteristics... there should be one or more that offer read,
>write and
>notify...
>
>
>/D

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: who has BLE dive computers - which one, which OSs can you test

[Richard Houser]

Aeris A300CS (understood no support yet)

GNU/Linux (Mageia 6/Cauldron)
Android/Linux (LineageOS on Nexus 5x - could install whatever on a Nexus 4 w/o 
SIM, if it helps)

On September 19, 2017 10:45:33 AM EDT, Dirk Hohndel  wrote:
>
>Hi there,
>
>I asked almost the same question before, but only a few people
>answered...
>
>I'm trying to figure out how much coverage we have for testing BLE
>support, but at this 
>point I can't really tell how many of us have access to such devices
>(and which OSs 
>they might be testing on).
>
>So, could you please respond and tell me
>
>- which BLE dive computer do you have access to 
>  (So far only support Suunto EON Steel, Heinrich Weikamp OSTC 4, 
>Shearwater Perdix AI (and dual stack Perdix / Petrel 2), and Scubapro
>G2 -- 
>  if you have others, I'd love to know as well)
>
>- which OSs can you test on
>
>
>I'll start:
>
>Suunto EON Steel
>Shearwater Perdix AI
>Shearwater Petrel 2 dual stack
>
>Mac
>Linux (only Fedora on a physical machine, BLE doesn't work in a VM)
>Windows (currently an ancient netbook with BLE dongle)
>Android
>iOS
>
>Thanks
>
>/D
>___
>subsurface mailing list
>subsurface@subsurface-divelog.org
>http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: OSTC over BLE experiences and questions

[Richard Houser]

I have a later Aeris A300CS (purchased just after the VTX launch) with about 30 
dives on it and really like it *now*.  Some things did change, and it's 
important to have an updated firmware.  I use the VTX compression mount on my 
lower arm, for what it's worth.

Never had the mirror issues underwater, but it came with a plastic screen 
protector which I promptly applied before the first dive. Perhaps that was 
taking out much of the glare?  Can you confirm if yours is bare glass?  I did 
experience the wash out effect and needing to keep brightness above 50% 
mid-day.  The OLED was amazing for a series of night/twilight dives, btw. Small 
text is not a big issue for me personally.  I can easily read that in clear 
water, but don't recall really needing to leave the main screen or compass 
during a dive (more curious about temperature).

*now* - Four major snags along the way:

I ran into a defect where the computer silently added a bunch of nitrogen 
during a surface interval at the end of a 6 dive series while I was prepping to 
go back in and went into a deco condition 30 sec underwater. I submitted the 
dive logs, etc., and Oceanic published a specific firmware update to patch it.

The main UI was also updated more similar to the VTX in the later firmwares. 
When they did that, they switched the low battery indicator to a green battery 
indicator. I managed to miss that detail, thought it was good, and had it 
completely die on me at Bonne Terre. Stupid UI decision on that indicator 
color, but can be worked around easy enough. They were discontinuing further 
features on the A300CS in favor of the VTX, so the interfaces will likely start 
to diverge again.  The new interface is much better, though overall.

The PO2 warning is crazy annoying, and you can't really turn it off if you have 
audible alerts on.  It's hard coded at .2 below your PO2 limit, so for 1.4 
constantly trips at 1.2.  When diving EAN36, that's basically right into the 
middle of the ideal depth range I tend to want to be at for the reef, and it 
sounds off each and every time you cross that threshold descending a foot of 
so.  You have to set it to 1.6 to avoid having the warning going off 
constantly, and that messes things up a bit in planning mode.  If I recall, you 
could not set it higher, so tech divers would likely need to do without audible 
alarms.  I find those audible alerts particularly handy for things like ascent 
rate, just really wish the PO2 alert matched the set limit.

Initially no transmitted pressure readings.  Support had me remove the battery 
and short two contacts inside the device.  After that, the transmitter has 
worked fine.

On July 11, 2017 1:18:55 PM EDT, Linus Torvalds  
wrote:
>On Tue, Jul 11, 2017 at 6:57 AM, Matt Thompson 
>wrote:
>>
>> The Aeros 300CS, the Oceanic VTX, and the Aqua lung i750TC are all
>basically
>> the same computer, all manufactured by Pelagic Pressure Systems, all
>> suitable for grooming ;). They also all do BLE, hopefully the same
>flavor.
>>
>> I have screenshots of my i750 from nRF Connect that I can send to the
>list
>> tonight when I get to my hotel.
>
>I actually have an Aeris A300CS, and hated it with a passion. The
>screen turns into a mirror underwater, and it doesn't have all the
>data I want on it, and the "secondary screen" (which you get to with a
>button press) ends up having such a small font that together with the
>mirror-effect, it was completely unreadable.
>
>Plus the battery only lasted for a couple of days of diving in my
>experience (admittedly, that may have been a "five hours underwater
>each day" trip). And that was with the default screen brightness
>(60%?). If I had been forced to actually rely on it, I would have had
>to up the brightness to 100% and probably thus lose even more battery.
>
>So I was singularly unimpressed. I had it with me for one dive trip
>and never touched it again.
>
>Maybe I had a dud. Maybe they fixed the shaving mirror effect in the
>VTX. Or maybe there's just something wrong with me, but I really
>didn't like the A300CS even though I really wanted to.
>
>Annoyingly, it seems like I have lost the tank sensor for it. And I'm
>annoyed mainly because I think that tank sensor would work with my
>Perdix AI.
>
>ANYWAY.
>
>After that rant, I can report that I did take a quick look at the
>A300CS BLE, and it should be something we can support.
>
>The thing uses a Blue Radios "nBLUE" bluetooth chip that implements
>serial over BLE GATT (yet another "the standard didn't make a standard
>serial protocol, so we made our own". Damn to hell all the f*cking
>incompetent morons on the bluetooth committee).
>
>Oops, I'm ranting again.
>
>ANYWAY #2.
>
>The good news is like the OSTC3 chip, that nBLUE chip is actually
>documented, because it's used in various random IoT projects. For
>example
>

Re: Downloading FTDI dive log using desktop Subsurface on Android

[Richard Houser]

OTG deals primarily with the handset portion, not the devices you plug into it. 
 So, except for the handset, OTG adapter, and power requirements, devices 
aren't OTG compatible or not.  OTG adapters actually signal in hardware (via a 
specific resister value, like cables in USB-C) for the device to flip it's mode 
from a normal device and instead drive the USB bus.  I actually have two 
non-compliant devices that can be modded to work: Nexus 4 (incorrectly gives 
3.3V instead of 5V) and an HP touchpad (doesn't enter the OTG mode unless it's 
also receiving power, necessitating an additional Y cable to inject power or an 
OTG hub I have that backfeeds power).

I think what you will find is that most of those devices with both USB-A and 
micro-USB actually are just a normal USB device with an extra micro connector 
wired as an OTG adapter.  If your device is already supporting OTG with that 
secondary connector. Your unit should also work on normal hardware like a 
keyboard via a traditional OTG adapter that looks like this: 
https://www.amazon.com/Micro-USB-OTG-Adapter-Cable/dp/B00D8YZ2SA.

My guess is during the failure you were connecting your devices with a USB-A to 
micro-USB adapter that is not an OTG adapter (they could look physically 
identical, but the resistance would not be correct to signal OTG mode).

On February 8, 2017 8:42:53 AM EST, Willem Ferguson 
 wrote:
>On 08/02/2017 13:36, Anton Lundin wrote:
>>
>> Basically you can't connect anything else to you phones usb-port than
>> the USB-OTG cable. You might be able to use a USB-OTG-cable which
>> injects power but nothing else. You might be able to use a usb-hub
>for
>> the power inject, but I've never seen one which can feed power to a
>> USB-OTG connected phone.
>>
>> Remember USB-OTG != USB. They are two completely different modes in
>the
>> usb-hardware and software in your Android device.
>>
>> If you simultaneously need adb access, you need to enable adb over
>wifi,
>> and connect to your Android device that way.
>>
>>
>> //Anton
>>
>>
>
>Anton, I need a bit of help here to understand how an OTG protocol
>would 
>communicate with a normal non-OTG USB device like a dive computer. I 
>have always assumed OTG is a software upgrade to the existing USB 
>infrastructure that allows a device to become USB bus master and 
>actively talk to other USB devices. Now I see that there are so-called 
>OTG adapters that allows a memory stick to be OTG-compliant. Does this 
>mean that only OTG-compliant devices can be accessed by Android? What 
>exactly in hardware is required to get my phone to talk to a non-OTG 
>dive computer? I happen to have a memory stick with a micro-USB plug as
>
>well as a full-sized USB plug. If I connect it to Android with the 
>full-sized end, the OTG detector on my phone does not register it. If I
>
>switch to the micro-USB end of the memory stick, it registers an OTG 
>device on Android. I need to understand what the equipment
>ramifications 
>are for a diver with a FTDI-nased deive computer.
>
>Kind regards,
>
>willem
>
>
>___
>subsurface mailing list
>subsurface@subsurface-divelog.org
>http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: New Bug Reports/Feature Requests

[Richard Houser]

When you are looking into the tank editing, would you please try a couple tanks 
completely from the imperial specs we get from the manufacturers spec sheets?  
When I'm shopping for this stuff, I don't typically see water volume 
measurements.

Examples:

Luxfer AL80 77.4cuft 3000psi (from manufacturer specs online)
XS Scuba HP120 (Faber tank) 120.6cuft 3442psi (confirmed in the dive ship 
catalogs and online)
LP72 (forget the brand) 65cuft 2250psi (an optional + overfill hydro stamp gets 
it near 72, hence the name)
Catalina AL80 77.4cuft (from specs online)

Also, when I look up the details on that worthington x8-119 tank, I show 3442 
psi ~= 237bar and a volume of 14.8l (though that volume is reseller provided 
and does not show in the spec sheets over here).  I don't suppose the 200/207 
and 230/237 bar discrepancy is a factor either way?

On February 24, 2016 5:16:36 PM EST, Linus Torvalds 
 wrote:
>On Wed, Feb 24, 2016 at 11:47 AM, Linus Torvalds
> wrote:
>>
>> So you can add your *specific* cylinder type by editing the tank info
>> details completely. You should be able to (for example), specify your
>> cylinder by editing the cylinder information to be (take a
>Worthington
>> HP119 as an example):
>>
>>  X8-119, 14.4l, 230bar
>
>Ugh. Testign this shows that particularly in imperial mode we're less
>than graceful about adding new cylinder types.
>
>I'm pretty sure it used to work better, but it's been ages since I
>needed to add a specific cylinder, so it could have been this for a
>long time. Probably the whole Qt timeframe.
>
>From some quick testing, bugs I found if you try to create a new
>cylinder type in imperial mode:
>
> - During the editing of a manually added new dive, you don't seem to
>be able to do it at all - only choose from the existing types
>
>   This is an odd bug. I *can* edit the cylinder name in my real
>dives. I'm not sure what the difference is.
>
> - if you pick an existing type without work-pressure (eg a 10 l
>metric bottle), it shows that "10 l" wet-size in cubic feet (0.35
>cuft). It should show it as 10 l because we don't have a workpressure,
>and we just cannot convert to cuft at all.
>
>So our cylinder editing is certainly not without fault.  I'll have to
>think about this.
>
> Linus

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: New Bug Reports/Feature Requests

[Richard Houser]

Thank you for the prompt investigation.

I would be happy to test this whenever you are ready (or you could use my 
subsurface div XML), but I've had some trouble trying to build 4.5.3.  I might 
need an AppImage to do so.

On February 24, 2016 8:49:31 AM EST, Miika Turkia <miika.tur...@gmail.com> 
wrote:
>I think I see the bug in XSLT transform, naturally hidden in common
>templates and not on the actual file doing the conversion to
>divelogs.de format. Looks like using only one decimal has been there
>from the beginning. Makes me wonder if Richard has just been lucky
>with an earlier version of Subsurface. Anyway, I'll send a patch
>shortly for this.
>
>miika
>
>On Wed, Feb 24, 2016 at 12:27 PM, Rainer Mohr <m...@divelogs.de> wrote:
>> OK, found the uploaded DLD file.
>> This dive: https://en.divelogs.de/dive/1659944
>> has 9.1in the XML
>> So converting this to lbs: Divide by 0.4536 gives me 20.06 lbs, which
>is
>> diplayed as 20.1 lbs (I do round to one digit for displaying).
>>
>> So now the question is: At which point did the 9.1 get its value for
>putting
>> it into the XML. If the subsurface conversion from the entered lbs to
>stored
>> metric uses the same factor (which I do believe), it should be 9.072
>kilos.
>>
>> I guess your subsurface file would now come in handy to check whats
>in
>> there.
>>
>> Thanks,
>> Rainer
>>
>>
>> Am 24.02.16 um 11:13 schrieb Richard Houser:
>>
>> My id there is DiverMidMi, so feel free to look at the whole logbook.
>All my
>> logs before this February display the values I see in Subsurface.
>Those were
>> initially entered in 4.4.2. The new dives from this month show the
>excess
>> weight. I can supply the actual Subsurface xml entries after I get
>home
>> (probably tomorrow, last plane lands in a blizzard).
>>
>> The computer dives were one of these depending on the date:
>>
>> A300 CS -> ACI (Aeris proprietary app) -> CVS -> Subsurface -> export
>to
>> divelogs.de option --- my first 10ish dives in Florida last year. I
>did have
>> to do some really minor cleanup to the original XML (minutes vs.
>Seconds on
>> samples if I recall)
>>
>> A300 CS -> Subsurface > export to divelogs.de (switching from Mageia
>> Subsurface 4.4.2 to Subsurface 4.5.3 Appimage before the dives this
>month.
>>
>> On February 24, 2016 3:49:42 AM EST, Rainer Mohr <m...@divelogs.de>
>wrote:
>>>
>>> Am 24.02.16 um 07:42 schrieb Dirk Hohndel:
>>>>
>>>>  On Wed, Feb 24, 2016 at 08:10:04AM +0200, Miika Turkia wrote:
>>>>>
>>>>>  On Wed, Feb 24, 2016 at 12:52 AM, Dirk Hohndel <d...@hohndel.org>
>>>>> wrote:
>>>>>>
>>>>>>  On Tue, Feb 23, 2016 at 01:55:28PM -0500, Richard Houser wrote:
>>>>>>>
>>>>>>>  #4 Dives exported from subsurface to divelogs.de are now
>showing an
>>>>>>>  additional 0.1lb more than what they show in subsurface.
>>>>>>
>>>>>>  Rounding error somewhere. Silly American
>>>>>> pounds.
>>>>>
>>>>>  Both Subsurface and divelogs.de work in metric units internally.
>I
>>>>>  just did a quick test and 5lb turns out to be 2.268 kg in
>Subsurface
>>>>>  and is displayed as 2.2 kg on the divelist. Divelogs.de displays
>this
>>>>>  as 2.3 kg (as is correct rounding). However, it seems that
>divelogs.de
>>>>>  uses this rounded number when displaying the imperial weight (5.1
>>>>>  lbs). What has changed, I have no idea, but Rainer might be able
>to
>>>>>  clarify. (Us showing incorrect metric rounding is irrelevant
>regarding
>>>>>  divelogs.de import/export as we use the exact value in
>calculations
>>>>>  and export.)
>>>>
>>>>  That's odd, Rainer. Why would you convert the rounded value?
>>>
>>> I don't...
>>>
>>> Just entered a weight of 2.268 kilos in a dive at divelogs.de (which
>>> I
>>> do round to 2 digits, as I never thought a few grams would be of
>>> importance).
>>> This results in 2.27 kilos in the database and diplays as exactly 5
>lbs
>>> on the dive after setting my logbook to imperial. I have the
>feeling,
>>> that the dive had 2.3 kilos when it got into divelogs.de (as this
>would
>>> explain the 5.1 lbs). I don't do any additional rounding when
>reading
>>> the XML of the DLD files, so I'd like to check what got exported to
>>> divelogs.de
>>>
>>> Richard, could you please give me a link to the dive? How did the
>dive
>>> get into divelogs.de? The exact path of where the dive went in its
>>> digital life would help figure out where the rounding got screwed
>up.
>>>
>>> Thanks,
>>> Rainer
>>>
>>
>> --
>> Sent from my Android device with K-9 Mail. Please excuse my brevity.
>>
>>

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: New Bug Reports/Feature Requests

[Richard Houser]

My id there is DiverMidMi, so feel free to look at the whole logbook.  All my 
logs before this February display the values I see in Subsurface.  Those were 
initially entered in 4.4.2.  The new dives from this month show the excess 
weight.  I can supply the actual Subsurface xml entries after I get home 
(probably tomorrow, last plane lands in a blizzard).

The computer dives were one of these depending on the date:

A300 CS -> ACI (Aeris proprietary app) -> CVS -> Subsurface -> export to 
divelogs.de option --- my first 10ish dives in Florida last year.  I did have 
to do some really minor cleanup to the original XML (minutes vs. Seconds on 
samples if I recall)

A300 CS -> Subsurface > export to divelogs.de (switching from Mageia Subsurface 
4.4.2 to Subsurface 4.5.3 Appimage before the dives this month.

On February 24, 2016 3:49:42 AM EST, Rainer Mohr <m...@divelogs.de> wrote:
>Am 24.02.16 um 07:42 schrieb Dirk Hohndel:
>> On Wed, Feb 24, 2016 at 08:10:04AM +0200, Miika Turkia wrote:
>>> On Wed, Feb 24, 2016 at 12:52 AM, Dirk Hohndel <d...@hohndel.org>
>wrote:
>>>> On Tue, Feb 23, 2016 at 01:55:28PM -0500, Richard Houser wrote:
>>>>> #4 Dives exported from subsurface to divelogs.de are now showing
>an
>>>>> additional 0.1lb more than what they show in subsurface.
>>>> Rounding error somewhere. Silly American pounds.
>>> Both Subsurface and divelogs.de work in metric units internally. I
>>> just did a quick test and 5lb turns out to be 2.268 kg in Subsurface
>>> and is displayed as 2.2 kg on the divelist. Divelogs.de displays
>this
>>> as 2.3 kg (as is correct rounding). However, it seems that
>divelogs.de
>>> uses this rounded number when displaying the imperial weight (5.1
>>> lbs). What has changed, I have no idea, but Rainer might be able to
>>> clarify. (Us showing incorrect metric rounding is irrelevant
>regarding
>>> divelogs.de import/export as we use the exact value in calculations
>>> and export.)
>> That's odd, Rainer. Why would you convert the rounded value?
>
>I don't...
>
>Just entered a weight of 2.268 kilos in a dive at divelogs.de (which I 
>do round to 2 digits, as I never thought a few grams would be of 
>importance).
>This results in 2.27 kilos in the database and diplays as exactly 5 lbs
>
>on the dive after setting my logbook to imperial. I have the feeling, 
>that the dive had 2.3 kilos when it got into divelogs.de (as this would
>
>explain the 5.1 lbs). I don't do any additional rounding when reading 
>the XML of the DLD files, so I'd like to check what got exported to 
>divelogs.de
>
>Richard, could you please give me a link to the dive? How did the dive 
>get into divelogs.de? The exact path of where the dive went in its 
>digital life would help figure out where the rounding got screwed up.
>
>Thanks,
>Rainer

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: New Bug Reports/Feature Requests

[Richard Houser]

I completely agree that the metric to imperial tank measurement conversions 
suck, but I think there may be more to it than just the compressibility and 
temperature aspects. The Luxfer cylinder site seems to have been down about two 
weeks, but the third-party references I can find in the online tank catalogs in 
the US, etc. certainly reference that Luxfer AL80 as 77.4cuft, not 80cuft. So, 
those instructors are just looking at manufacturer spec sheets, like I did when 
I got my Faber 120 steel.

It doesn't make sense to me that a manufacturer like XS scuba (the link I 
provided earlier with the Faber Steel tanks) would change measurement metrics 
between tanks on the same table, so if the nominal cuft values for something 
like a current Faber 120 or 119 are even used to initially convert to a metric 
equivalent, it seems that something will be off for one tank or the other. From 
memory (flying atm), I think the 119 tank in that table held something like 
123cuft as opposed to the 120cuft listed for an HP120. If it's not the 119 
specifically, it's one of the other tanks on that table.

As an imperial tank user, it's just really confusing to have Subsurface 
reporting different cuft values than the tanks I'm using, even if the 
underlying conversion calculations are correct. And, I'm still not convinced 
those calculations are correct across our spectrum of standard tanks. I'll look 
into it further, when I get back to my computer. Do metric tank volumes already 
account for the valve displacement?

On February 23, 2016 6:46:44 PM EST, Linus Torvalds 
<torva...@linux-foundation.org> wrote:
>On Tue, Feb 23, 2016 at 2:18 PM, Richard Houser
><r...@divinesymphony.net> wrote:
>> 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.
>
>That's complete bullshit. Sorry. That's an oversimplification of the
>problem, and it's an over-simplification to the point of just being
>wrong.
>
>The fact is, it depends on the exact manufacturer, but also people are
>entirely confused about what "true capacity" is.
>
>For example, a Luxfer AL80 (which is just about the most common one
>out there) is a 11.1L bottle ("wet volume", aka "metric size", aka
>"not completely buggered and screwed up idiotic imperial units").
>
>That's the only _real_ "true capacity". The wet volume of the cylinder
>is the *actual* volume of the cylinder, with no idiotic "air at
>rpessure and temperature" effects.
>
>And guess what? When you look at what we translate "AL80" into, that's
>*exactly* what we give:
>
>cylinder vol=11.097l workpressure=206.843bar
>
>so our cylinder calculations are 100% correct. We never actually use
>"80" in any calculations, except to initialize that metric volume that
>we got right.
>
>So we actually use a 11.1 liter volume (and the "workpressure" is
>actually immaterial for everything, the _only_ use for that is for the
>crazy imperial conversion).
>
>Now, where does that "true capacity" come from? It's some fairly BS
>measure that comes from how idiotic the imperial cylinder measurements
>are to begin with, and involves a test of how much air you can
>actually get out of the cylinder. The difference to actual 80 cuft
>seems to come from a few places:
>
> (a) when you empty a cylinder, it ends up not empty (as in a vacuum),
>but full of air at 1 atm.
>
> So even if there was 80 cuft of air in the cylinder, you won't
>get all out of *out* of the cylinder, there will be that 11.1L
>(roughly 0.4 cuft) remaining in the bottle.
>
> It's somewhat unclear whether people use absolute pressure or
>gauge pressure for the working pressure, so that 0.4 cuft is actually
>debatable, but the "naive" math model (which is what I'd expect the
>cylinder sizing to be, considering all the other things going on)
>would give you a 0.4 cuft deficit.
>
>So that accounts for part of it, but only 0.4 cuft. Where did the rest
>go?
>
> (b) air is not actually entirely compressible.
>
> This is a fairly small factor at 3000psi, but it's a factor.
>HOWEVER. The rule for cylinder sizing is that the stated cylinder size
>is basically the "theoretical" size, not the real size.
>
> As seen before, we actually use the correct _real_ size for a
>Luxfer AL80 bottle. Don't believe me? Go look at the Luxfer data
>sheets, it really is 11.1 liter wet size. And just turn Subsurface
>into metric mode, and you really will see 11.1 liter, not 80 cuft.
>
>So that

New Bug Reports/Feature Requests

[Richard Houser]

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.



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

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.



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



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



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



#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.
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface