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