Re: messing with the gas / tank handling
On Fri, Oct 31, 2014 at 05:08:54PM +0100, Davide DB wrote: If I correctly understand this topic, its' about the same old rant about cylinder management... I hope this could be solved in 4.4 at least. I'm editing multiple technical dives after a week of training and it's a nightmare between bugs and missing functionalities. While testing bugs 753 and 754 I realized that some dives have the current cylinder in use PITA on all of them. Actually I do not understand why in a row of six imported dives just a couple of them have this problem on all cylinders. Sorry - as far as bug reports go... this one isn't really helping me understand what's going wrong. - I never touched profiles - I played with copy paste on multiple tanks and god knows what happened. I understood that you were referring to download tank data from your DC but I use only a stupid BT and I would like to be in full control of my cylinder data. Yes. So tell us in small words and short sentences ( :-) ) what it is that you would like and what the various bugs and missing features are. Ideally one at a time. I'm not trying to be funny - but it's really really hard to debug this / write the code when you don't quite understand what's wrong. For the developers usually the way we use things work. Otherwise we'd fix it :-) /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: messing with the gas / tank handling
G Once my EON Steel arrives we'll need to drive up to Hoodsport and do some data collection... :-)? As in Hood Canal, WA? Somehow I thought you were located in Europe. Guess I need to be more curious in the future! --Steve (Enumclaw, WA -- OC mostly at Redondo) PS Looks like I'll need to pick up a modern language like C to add to my ancient language list (COBOL, Fortran, PL/SQL, etc). Become more useful here. ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: totally off topic [was: Re: messing with the gas / tank handling]
On Thu, Oct 30, 2014 at 10:57 AM, Dirk Hohndel d...@hohndel.org wrote: On Thu, Oct 30, 2014 at 07:45:47AM -0700, Steve Butler wrote: G Once my EON Steel arrives we'll need to drive up to Hoodsport and do some data collection... :-)? As in Hood Canal, WA? Somehow I thought you were located in Europe. Guess I need to be more curious in the future! Hehe. Linus, Thiago and I all three live in Portland, OR. But we're originally from Finland, Brazil, and Germany, respectively. I did almost all my dive training in Hoodsport, WA and occasionally pretend to work there as a dive master or tec dive master. And as much as I enjoy warm water diving, there is no warm water anywhere in driving distance, so if I need to collect data, I drive up to Hoodsport - especially for things like multi-cylinder diving or deco diving. But since we are entirely off topic already... John Hawley, a coworker of mine at Intel, is currently building the Auto Diver. A contraption that will allow us to automatically lower and raise a dive computer into a pool... which makes it possible to add a lot of really boring dives to a dive computer (for cases where we are concerned with things that happen once there are tons of dives on a DC, e.g. for the EON Steel where we don't know what will happen to its directory entries). Some of the tests I want to see on a dive computer involve volume of data and also depths. For volume I need to exceed the enormous limits of Cochran computers, like 1450 hours of sample data and 1024 logged dives. For depth I need to exceed 256 ft to verify how the data is encoded. I'm neither trained nor comfortable doing a dive like that. The LDS had cut the bottom 12 off an old AL80 and had a machine shop modify it to be a pressure chamber, add water and it's a dive simulator. It's manual, in that the user presses a valve to add compressed air and turns a bleed screw to release. Unfortunately it maxed out at 150ft and far too manual to do 1000 dives. However add some solenoids and maybe it could be automated. --Steve (Enumclaw, WA -- OC mostly at Redondo) So you're 60 miles closer to Hoodsport than we are :-) PS Looks like I'll need to pick up a modern language like C to add to my ancient language list (COBOL, Fortran, PL/SQL, etc). Become more useful here. Yes, please. Especially, please pick up C++ and focus on Qt development. That's the number 1 area where we need more active contributors :-) After your tenth UI related patch I'll invite you to a dive weekend at the Yellow House (only partly kidding). /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface -- John Van Ostrand At large on sabbatical ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
messing with the gas / tank handling
Hey Linus, Usually whenever I touch this code I break it. And then you have to fix it later when you notice that I messed with things. So this time I'll alert you directly. Danger, danger, Dirk touched the gas / tank handling code!!! Bug #742 shows that we got things pretty badly wrong for the Cobalt if the primary gas used on a dive (or in the case of his sample data, the only gas used on a dive) was not tank 0. We showed that ugly gas change, we showed that two gases were used during the dive, we associated the pressure from the samples with the wrong tank, etc. I just pushed out a commit that pretends to fix this. And it makes sense to me. But I'd really appreciate if you (or anyone else for that matter) would take a look and double check that this is ok. My biggest concern is the logic I added to fixup_dive_dc(). Because I don't know if sample-sensor == 0 means we explicitly switched to sensor 0 or we don't know which sensor we are using (i.e., which tank the sensor is connected to). The code there worked for all dives that I could find (I have a bunch of Cobalt dives from a couple of years ago when I got a Cobalt as a loaner for one of the tech classes we did). And it works with all my other multitank dives. Still - there is too much black magic in the way we handle gases / tanks. /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: messing with the gas / tank handling
On 28 October, 2014 - Linus Torvalds wrote: On Tue, Oct 28, 2014 at 2:13 PM, Dirk Hohndel d...@hohndel.org wrote: Bug #742 shows that we got things pretty badly wrong for the Cobalt if the primary gas used on a dive (or in the case of his sample data, the only gas used on a dive) was not tank 0. We showed that ugly gas change, we showed that two gases were used during the dive, we associated the pressure from the samples with the wrong tank, etc. I just pushed out a commit that pretends to fix this. And it makes sense to me. But I'd really appreciate if you (or anyone else for that matter) would take a look and double check that this is ok. It looks fine, but the whole = 30s and first sample thing looks a bit confused. Do you really need *both*? Also, that whole /* if we have an explicit first cylinder */ if (sample-sensor == 0 first_cylinder != 0) sample-sensor = first_cylinder; looks a bit iffy. I guess we're stuck with it, but my gut feel is that it's actually an Atomic Cobalt back-end bug, and that the Cobalt should just have reported the right sensor, rather than reporting sensor 0. The reason it's iffy is that another dive computer that does this *right* might be impacted. But right now, I guess only the Cobalt has this whole first_cylinder issue, so maybe worry about that possibility later.. And quite frankly, we'll need to eventually fix the fact that we can only have one cylinder pressure per sample, so this code will end up needing changes in more fundamental ways eventually. So the whole this might break in the future is not a very strong objection. The code is pretty much *guaranteed* to break in the future for other reasons anyway. Multiple sensor support feels way better than the current separate diluent-sensor code we currently carry for the Mk6. //Anton -- Anton Lundin+46702-161604 ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: messing with the gas / tank handling
On Tue, Oct 28, 2014 at 3:38 PM, Anton Lundin gla...@acc.umu.se wrote: Multiple sensor support feels way better than the current separate diluent-sensor code we currently carry for the Mk6. I think Dirk has another EON Steel with pressure sensor coming once they are public, so then we can finally test the whole two independent and concurrent pressure sensors from a dive computer that supports it. They've been around before, but we haven't had access to any real data. And even some that are around don't seem to really report multiple pressures (ie they'll switch on gas switch events, or they support showing buddy pressures, but don't log them). It's possible the EON Steel does the switch on gas switch events thing too, but judging by the encoding, I *think* it will actually log pressures from all the cylinders in parallel. We'll have to wait and see. It's going to be somewhat painful. Going to *two* sensors wouldn't be an issue: it doesn't take much more room than our current sensor index + pressure for our single sensor model, and in fact if we re-use one of the cylinders for diluent, we'd actually be shrinking our data structures. But our MAX_CYLINDERS value is currently 8, and it feels a bit wrong to make cylinderpressure an array of eight. But I suspect that's what we'll have to do. Anything more complicated would not just increase confusion, but on 64-bit machines even just carrying a pointer to sensor data around takes up the space of two of the pressures, so it's hard to make it much denser with extra indirection or something. I guess 32 bytes per sample just for sensor data isn't really all that excessive in the end. It's not like people are likely to run this on really old machines. Linus ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: messing with the gas / tank handling
On Tue, Oct 28, 2014 at 02:58:50PM -0700, Linus Torvalds wrote: On Tue, Oct 28, 2014 at 2:13 PM, Dirk Hohndel d...@hohndel.org wrote: Bug #742 shows that we got things pretty badly wrong for the Cobalt if the primary gas used on a dive (or in the case of his sample data, the only gas used on a dive) was not tank 0. We showed that ugly gas change, we showed that two gases were used during the dive, we associated the pressure from the samples with the wrong tank, etc. I just pushed out a commit that pretends to fix this. And it makes sense to me. But I'd really appreciate if you (or anyone else for that matter) would take a look and double check that this is ok. It looks fine, but the whole = 30s and first sample thing looks a bit confused. Do you really need *both*? From reading the Cobalt code we don't need the = 30s code anymore - it's ALWAYS on the first sample. I wondered if there was another dive computer that did something similar where we might still need it. I can't think of one, though. Maybe I should just remove it and see if something breaks :-) Also, that whole /* if we have an explicit first cylinder */ if (sample-sensor == 0 first_cylinder != 0) sample-sensor = first_cylinder; looks a bit iffy. I guess we're stuck with it, but my gut feel is that it's actually an Atomic Cobalt back-end bug, and that the Cobalt should just have reported the right sensor, rather than reporting sensor 0. I was wondering about that as well. The backend clearly has code there to try to report this data - but without access to a Cobalt this is hard to figure out... the Cobalt is another one of the dive computers where we can't just do a memory dump. Jef - I think you were working on a tool to dump the raw data for a dive? That might be helpful here... Or I could just send the user a hacked version of Subsurface that dumps the raw data to a file. He is responsive on trac... The reason it's iffy is that another dive computer that does this *right* might be impacted. And that's exactly why I wanted to show this to you... But right now, I guess only the Cobalt has this whole first_cylinder issue, so maybe worry about that possibility later.. And quite frankly, we'll need to eventually fix the fact that we can only have one cylinder pressure per sample, so this code will end up needing changes in more fundamental ways eventually. So the whole this might break in the future is not a very strong objection. The code is pretty much *guaranteed* to break in the future for other reasons anyway. Lovely. See my comment above :-/ Thanks for taking a look. I'll remove the = 30s checks and leave it as is otherwise. /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: messing with the gas / tank handling
On Tue, Oct 28, 2014 at 04:00:05PM -0700, Linus Torvalds wrote: On Tue, Oct 28, 2014 at 3:38 PM, Anton Lundin gla...@acc.umu.se wrote: Multiple sensor support feels way better than the current separate diluent-sensor code we currently carry for the Mk6. I think Dirk has another EON Steel with pressure sensor coming once they are public, so then we can finally test the whole two independent and concurrent pressure sensors from a dive computer that supports it. We have two other combinations that we can test. We have two Uemis sensors and we have two Icon HD sensors. Once my EON Steel arrives we'll need to drive up to Hoodsport and do some data collection... :-) They've been around before, but we haven't had access to any real data. And even some that are around don't seem to really report multiple pressures (ie they'll switch on gas switch events, or they support showing buddy pressures, but don't log them). I know we tested this with the Uemis and that simply switched between sensors in the samples. I can't remember what the Mares did, though. It's possible the EON Steel does the switch on gas switch events thing too, but judging by the encoding, I *think* it will actually log pressures from all the cylinders in parallel. We'll have to wait and see. It's going to be somewhat painful. Going to *two* sensors wouldn't be an issue: it doesn't take much more room than our current sensor index + pressure for our single sensor model, and in fact if we re-use one of the cylinders for diluent, we'd actually be shrinking our data structures. But our MAX_CYLINDERS value is currently 8, and it feels a bit wrong to make cylinderpressure an array of eight. How many tank sensors does the EON Steel support? The Uemis supports up to three. But I suspect that's what we'll have to do. Anything more complicated would not just increase confusion, but on 64-bit machines even just carrying a pointer to sensor data around takes up the space of two of the pressures, so it's hard to make it much denser with extra indirection or something. I guess 32 bytes per sample just for sensor data isn't really all that excessive in the end. It's not like people are likely to run this on really old machines. Do we really need 4 bytes for pressure data? Yes, we do when saving in mbar... we could switch to storing things in cbar - unsigned int16 gives us up to 650 bar... I'll admit, I'm not really serious. I'm not worried about 16 bytes more per sample and just staying with sane types. /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: messing with the gas / tank handling
On Tue, Oct 28, 2014 at 4:24 PM, Dirk Hohndel d...@hohndel.org wrote: I know we tested this with the Uemis and that simply switched between sensors in the samples. Right. The Uemis wasn't a reason to switch from our current sensor idx + pressure model. I can't remember what the Mares did, though. Did we even have multiple sensors? How many tank sensors does the EON Steel support? The Uemis supports up to three. I think the docs said up to ten. Do we really need 4 bytes for pressure data? Yes, we do when saving in mbar... we could switch to storing things in cbar - unsigned int16 gives us up to 650 bar... Hmm. Looking at the sample pressures I have, none of them have higher resolution than centibar anyway. So we could do that for cylinderpressure. But I only have a few pressure sensors and sources of data: the Uemis, and two different versions of the Suunto one. The surface pressures and cylinder working pressures are actually saved in mbar, though, so we'd have to use a separate type for cylinderpressure. Might not be a bad idea, though. In fact, the EON Steel uses a 16-bit centibar representation for its cylinder pressure data (or kPa, which is the same thing as cbar): PTHsml.DeviceLog.Samples.Sample.Cylinders.Cylinder.Pressure FRMuint16,nillable=65535 MOD1000*x,x so at least *one* divecomputer clearly thinks it's sufficient. Linus ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: messing with the gas / tank handling
On Tue, Oct 28, 2014 at 04:47:31PM -0700, Linus Torvalds wrote: I can't remember what the Mares did, though. Did we even have multiple sensors? I could have sworn that we had two. I even remember talking to the Mares guys about it. But I can only find one. Does anyone have a spare Mares Icon HD transmitter that they wouldn't mind borrowing us for a while? Or does anyone here have an Icon HD with two transmitters from which we could get raw data? How many tank sensors does the EON Steel support? The Uemis supports up to three. I think the docs said up to ten. Wow. We need to increase MAX_CYLINDERS :-) Do we really need 4 bytes for pressure data? Yes, we do when saving in mbar... we could switch to storing things in cbar - unsigned int16 gives us up to 650 bar... Hmm. Looking at the sample pressures I have, none of them have higher resolution than centibar anyway. So we could do that for cylinderpressure. But I only have a few pressure sensors and sources of data: the Uemis, and two different versions of the Suunto one. I did a quick look through libdivecomputer sources. I cannot find any device that appears to devote more than 16 bits to this. And I actually find several that appear to do this in 8 bits (i.e., 2 bar resolution). The surface pressures and cylinder working pressures are actually saved in mbar, though, so we'd have to use a separate type for cylinderpressure. Might not be a bad idea, though. I'm really torn. Do we really care that much? This would be our third pressure type. We have pressure_t which is 32bit mbar, we have o2pressure_t which is 16bit mbar. And then we'd have cylpressure_t which is 16bit and cbar. so at least *one* divecomputer clearly thinks it's sufficient. As far as I can tell ALL divecomputers think that's sufficient. /D ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
