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
