Re: Location, location, location
On Wed, Jul 15, 2015 at 2:56 PM, Linus Torvalds torva...@linux-foundation.org wrote: On Wed, Jul 15, 2015 at 6:38 AM, Rick Walsh rickmwa...@gmail.com wrote: I see the benefit of the autocomplete to create a new site with the same name as an existing site isn't so much that it saves a few keystrokes, but that it is explicitly either creating a new site or assigning a dive to an existing site. It helps avoid confusion. Not just confusion. It gets rid of special cases. I believe I understand now why your use cases seem so alien to me. It's all about the idea that there should be more than one dive site with the same name on Subsurface. You clearly believe there should: 1. either because the local name is the same and you want the the dive site name in Subsurface to be just the local name; 2. or because you want the same dive site to appear several times with different GPS fixes because you are not sure of the GPS fix. I don't want to have 2 dive sites with the same name on Subsurface at all. Never. When dealing with common dive sites (case 1 above) I do some distinction on then like: - Blue Hole, Niquelândia/GO, Brasil - Blue Hole, Nobres/MT, Brasil - Blue Hole, FL, USA - Blue Hole, Belize I really don't want to have several different sites named just Blue Hole in Subsurface, one in the center of Brazil, the other on the southwest of Brazil, one in Florida and the other on the Caribbean sea. And just by looking at their name I want to be sure about which dive site I'm dealing with. The second reason you seem to want different dive sites with the same name is that they actually are the same dive site but you want several GPS fixes for it. I might decide to change the GPS fix for a dive site but I certainly want that all occurrences of that dive site to share this new GPS fix. The idea of having several dive sites with the same name about a kilometer apart when they actually are the same dive site is rather strange to me. If I were to deal with this situation (wanting several GPS fixes for the same dive site) I would start to name them Fix 1, fix 2 etc until I finally decide for a final fix and them go back to having just one dive site with that name with all occurrences sharing the same GPS fix. If Subsurface is to support the idea of different dive sites with the same exact name as you like, I believe all this mess and special cases you mention might make some sense. I just don't think this idea is intuitive at all. It never even occurred to me. I don't think the people who complain have really used the old subsurface location model with the GPS information very much. Or if you did use it, you didn't realize how subtle it was, and what kind of odd internal tricks it did. Now that you mention it, I see that my feeling that Subsurface was doing tricks on me was real. These tricks on the old code might deal well with several of these special situations created by the idea of having different dive sites with the same name. If you start to deal with the dive site name as a unique identifier, all these special cases simply disappear. I understand that from now on you would have to make some distinction on the name of several Blue Hole dive sites you probably have but I really don't think these distinctions would be strange of artificial at all as the ones I use aren't. Unfortunately I know I'm suggesting a much more radical change in Subsurface than just the location interface but please keep in mind that all these tricks to deal with dive sites with the same Subsurface internal names might make lots of sense to the way you deal with dive site naming but they are completely disruptive for other naming strategies. In this simpler Subsurface I envision, a new name is always a new dive site. The same name is always the same dive site as the other(s) with the same name. If I edit a GPS fixes of a dive site, all occurrences of that dive site are also changed because they are the same actually. And now back to the messy having-the-same-name-in-subsurface-means-nothing-as-they-might-be-different-dive-sites-or-not world we actually live in. Rodrigo Severo ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Location, location, location
On Wed, Jul 15, 2015 at 10:45 AM, Dirk Hohndel d...@hohndel.org wrote: On Wed, Jul 15, 2015 at 10:27:16AM -0300, Rodrigo Severo wrote: On Wed, Jul 15, 2015 at 10:15 AM, Henrik Brautaset Aronsen subsurf...@henrik.synth.no wrote: The autocompleted Blue Corner - Create dive site with this name is not useful IMHO. How often would you create a new site with the exact same name as one that is already existing? I think this would only create confusion. I agree with you but apparently this feature is considered VERY USEFUL by others. I think it's not really useful because either: 1. it's a common AND simple name like Blue Corner so why bother saving the trouble of retyping Blue Corner; 2. it's a long and difficult to type name and so it's NOT common and probably won't be used twice. IMHO, the autocomplete should always autocomplete to help select an already existing dive site, whenever this already existing dive site has GPS coordinates or not. If the user doesn't use autocomplete, a new dive site would be created. And that was exactly what I had proposed. So I agree. And as Tomaz just mentioned: Well, Take a look about linus rant from yesterday, in the other location e-mail. He stated that There are many dive sites with same names, for instance Turtle Reel or Blue Hole so he wanted to have a way to autocomplete the name without copying the dive site coordinates. The examples that Linus presented that actually repeat are common, small and simple. (case 1 above). That long dive site name Linus mentioned from Brazil won't ever be used anywhere else in the world (case 2 above). Really, autocomplete to just get the same (small and simple) name for a new site is silly and confusing. Autocomplete should be restricted to selecting an already existing dive site (which might already have GPS coordinates or not). I completely agree. If the user wants to create a new site, just type it in. If they want to use an existing site, pick it from the auto completion. Easy, consistent, doesn't waste screen real estate. Linus, are you ready to acknowledge that it's just not worth the trouble to use autocomplete to save a few keystrokes when getting the same name for a different dive site? Rodrigo Severo ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: [PATCH] MOD of oxygen at pO2 of 1.6 is 20ft
On Mon, Jul 6, 2015 at 4:24 AM, Henrik Brautaset Aronsen subsurf...@henrik.synth.no wrote: On Sun, Jul 5, 2015 at 11:03 PM, Rick Walsh rickmwa...@gmail.com wrote: Serious question: does anyone switch to 50% at 22m? For tank MOD markings around me usually round to the nearest 3 (meters). So 21 meters (not 22) for 50% and 6 meters (not 5) for o2. Etc. Also to the nearest 10ft. I dive metric, my stops are all multiple of 3 m and my tanks have the real MODs, not rounded ones, as I understand MODs as maximum operation depth, not mandatory other-gas depth ;) But obviously I understand that having the MOD equal to some deco stop might seems less confusing. Truncating sounds more conservative but actually I bet that if your dive plan gets unsafe because of half a meter on a deco stop or worst half a foot you have other problems not rounding related so rounding seems to me as the right thing to do. Rodrigo Severo ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Shearwater Petrel Bluetooth connection on Fedora 20
On Sun, Apr 12, 2015 at 8:23 PM, Rick Walsh rickmwa...@gmail.com wrote: I made a quick attempt this morning, but ran out of time and needed to go to work. I'm not familiar with rfcomm or Bluetooth on Linux. Please excuse my ignorance, but what is the correct command? Hi, I managed to get stable connections using the rfcomm connect command. Here is the script I use to connect the Petrel to my computer just before using downloading data on Subsurface: # cat /usr/local/sbin/petrel_download #!/bin/bash read -p Abra o Subsurface, abra o log de mergulho onde ficaram guardados os mergulhos a serem baixados. Abra a opção Registros Transferir do computador de mergulho. Verifique que a porta indicada na janela de transferência é /dev/rfcomm0. Ligue o Petrel e ponha ele no modo 'Upload log'. Tecle [Enter] quando estiver pronto. hciconfig hci0 up # Antigo Petrel com porta externa (vendido para o Cristofer) #rfcomm connect /dev/rfcomm0 00:13:43:04:F2:F1 # Novo Petrel controlador do O2Ptima rfcomm connect /dev/rfcomm0 00:13:43:08:96:48 # Novo Petrel sem porta externa #rfcomm connect /dev/rfcomm0 00:13:43:07:90:CD echo Se não houve nenhum erro, só falta ir no Subsurface e mandar baixar os mergulhos. -- Unfortunately the comments are in portuguese but Google Translate is your friend... I have several rfcomm connet lines because I have/had more than one Petrel. Leave only one of them uncommented. Rodrigo ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: *****SPAM***** Re: Cylinder pressure interpolation and end pressure display for CCR
On Sun, Nov 9, 2014 at 7:23 AM, Willem Ferguson willemfergu...@zoology.up.ac.za wrote: These are real readings taken with accurate pressure sensors on both the oxygen and diluent cylinders. Is the real-life situation perhaps a bit different from the expected theoretical situation? You guys have the experience. Certainly one cannot ignore the real measurements? Sorry. Didn`t figure it out you were talking about real measurements. To interpolate them, I believe we should use linear interpolation, no matter if we are dealing with oxygen or diluent. But surely I`m not following this issue as closely as I should ;) Rodrigo ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Cylinder pressure interpolation and end pressure display for CCR
On Sun, Nov 9, 2014 at 5:49 AM, Willem Ferguson willemfergu...@zoology.up.ac.za wrote: As far as the present implementation is concerned, I suspect it would be fairly easy (not simple) to to changes. We just need to agree on the principle of interpolation for the diluent. I was initially proposing a method that would use the regular OC depth dependent interpolation method with one modification: only the samples that represent an increase in depth to be considered, i.e., when ascending or maintaining depth, we would consider diluent consumption as zero. This method creates the problem of separating what actually is a depth increase and what is simply noise in depth reporting. Two methods where suggested to solve this issue: * a threshold (3 feet? something changeable by the user on preferences?) that would define the minimum depth change that we would actually consider a depth increase * a 1 minute time average depth (suggested by Dirk). I like Dirk`s idea but I believe any one of them would work. Regarding the graph you posted Willem, I believe that during ascends and fixed depths periods, the diluent graph should be a perfect horizontal line (no consumption as I mentioned above). Regards, Rodrigo ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Two more rebreather patches
On Tue, Oct 28, 2014 at 9:36 AM, Paul Sargent paul.lions...@icloud.com wrote: On 27 Oct 2014, at 17:56, Rodrigo Severo rodr...@fabricadeideias.com wrote: For example: A one hour dive should be 20bar (60 litres) out of a standard 3 litre cylinder - just calculating 1 litre a minute. That's just way off. I always use about ~50 bar on a ~40 metre dive, so I tend to make sure I've got at least 100 bar when I jump in. (or have a missed a different method of calculating things in the various mails?) The method of calculation is just that but, as I see things, it would happen the other way around: After this dive Subsurface would show you that your oxygen SAC is 2,5 l/min (50 bar of a 3 l cylinder used on an hour dive). So on your next planning you should use 2,5 l/min for oxygen and not the usual 1 l/min. The problem here is that going from a one hour to a two hour dive doesn’t double my O2 use. I might go from 50 bar to 70 bar (i.e. Same use for the ascent aspects, another 20 bar for the extra hour). To me it sounds to me like we’d need a SAC component (litres/min) and an ascent component (litres/metre.bar). Diluent would just have a descent component (litres/metre.bar). In the example above reasonable figure might be: - O2 SAC: 1 litre/min - O2 Ascent: 30bar * 3l = 90l 90l / 40 metres = 2.25 litres/metre 2.25l / 2.5 bar (Avg. Pressure during ascent) = 0.9l / metre.bar I don't understand way the ascent component has a bar in it (and why you divided the average consumption per meter by the average pressure). Shouldn't the ascent component just be 2.25 litres/metre here? - Diluent Descent: 50bar * 3l = 150l 150l / 40 metres = 3.75l / metre 3.75l / 2.5 bar (Avg. Pressure during descent) = 1.5l / metre.bar Here again I don't understand why getting a litre/metre*bar. Why not jsut litre/metre? Rodrigo ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Two more rebreather patches
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? 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. Regards, Rodrigo ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Two more rebreather patches
On Mon, Oct 27, 2014 at 2:10 PM, Dirk Hohndel d...@hohndel.org wrote: With the benefit of absolutely know subject matter expertize, I think what would make sense is to smooth out the depth graph. Something like a gliding average across one minute - that should remove jitter and the quick pop down to look at things that you describe, at the same time it should be reasonably close to what I would call the perceived depth during a dive - and I think that's what people will tend to base their change to the counter lung content on... I believe this gliding average could be a really good solution for this issue. Could it be used for anything else or would it be used just for SAC calculation of diluent on CCR dives? Rodrigo ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Fwd: Subsurface UI for CCR dives
On Sat, Oct 18, 2014 at 5:29 PM, Paul Sargent paul.lions...@icloud.com wrote: I wrote some notes on a ticket about gas consumption on CCR dives several months ago (before I knew the Poseidon logged cylinder pressure). Maybe those are useful. http://trac.subsurface-divelog.org/ticket/80. Unfortunately the attachments I added seem to have been lost. I've just added a commetn on the above mentioned ticket. It's about diluent SAC calculations: I believe we should consider that diluent is only used on decends, taking depth (ambient pressure) in account just like we do to calculate SAC for OC. In other words, when depth is maintained or reduced, we should consider diluent spend as zero, all use of diluent happening on decends. Regards, Rodrigo -- Rodrigo Severo | DIRETOR DE TECNOLOGIA Tel. +55 61 3030-1515 Siga a Fábrica no twitter:@empautaclipping fabricadeideias.com 12 ANOS DE TECNOLOGIA E COMUNICAÇÃO NUMA COMBINAÇÃO PERFEITA ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
