My computer idea... opinions?

Most are ultrasonic or thereabouts underwater. VLF works well, and no, you don't need a huge antenna. Think of it more like a speaker coil at those frequencies. You also don't care if it's a particularly efficient setup, as you're not transmitting very far - a couple meters at most.

The problem with most of these setups is that they suck for reliability.

Witness the disaster that is the AirZ O2 and Oxy2 from Uwatec. That was the first piece of Uwatec I ever bought, when I got a Dolphin five years ago as my "starter" Rebreather, and it's the last piece of Uwatec I'll ever buy. Three handsets and two replacement transmitters later, I gave up for a VR3 with the reliability of a wired cable. Not only would the thing crap out on me when I turned on my HID or my camera strobes, half the time, it would crap out on me if I wore the handset on my left wrist, with the transmitter on the right side hose of the rebreather. While I give them kudos for the free replacement, a continuous replacement of one pile of garbage with another identical one does not a happy consumer make, and the wires win the day.

WRT to the earlier discussions of how/what to write on the handset, it does take a lot less skill to write in Java or some other managed programming language than it does to write in C++ or lower level, even, in C or even Assembler.

That said, though, it takes just as much skill on the side of the programmer to actually get it right as opposed to cranking out poor code - the set of problems you encounter in a managed programming language, like Java (or C#, which I actually prefer 'cause it's got a better toolchain) is a lot different than writing lower level code, but you're just trading one set for another. In most cases, too, in a tightly power constrained embedded environment, you're wasting valuable resources running "unnecessary" code, like a GC, simply for the convenience of a developer... they're just not nearly as efficient as lower level code, except in the eyes of the authors. (FWIW, I have multiple teams of developers at work, one team codes in C++, two in Java, the rest in other obscure bits, and none gets a free ride...) My Java guys consume a lot more resources like memory, processor, and, by inference, electricity - to get the same job done, and the code tends to be slower overall. They write the code with less bugs in half the time, but spend the rest of the time trying to optimize it as fast as the other guys...who show up later, but with much snappier stuff out of the gate.)

You don't need such complexity in a handset. It's higher parts counts, higher BOM, higher instability, etc. You're working on life support gear, and the ultimate goal should be to keep it as simple and as deterministic as possible. The last thing I'd want on there is a full blown operating system to suck down the batteries...

As for the computer and the power consumption, i would use something
similar to this:
TS-7800 High-End Performance with Embedded Ruggedness

A more slimmed down version perhaps but something similar. This one
enclosed in, for example, a mineral oil filled Delrin compartment with an receiver to recieve the o2 data sent by the transmitters.

Cheers

No friggin' way! I actually own a Technologic Systems TS board that was going to use in other projects! Very neat boards, and they do run Linux with a 2.4.x kernel on the one that I have, but it is a bit large. It would have to go into a box that is mounted on the back, not in a handset. It *does* have great power management features in that you can slow down the clock cycles to save power. Nice boards IMHO. I am scared about the 2.4.x kernel though.

As far as high versus low level language.... I dunno, I still tend to like tight and efficient over the idea of rapid development. Last night at a "geek meet" a local throws a tiny board on the table... it's got this tiny module that contains a blackfin based 600mhz CPU, RAM, flash and who knows what else... 200ma draw. Has on board ethernet, USB, CAN buses, parallel data bus, serial busses... so tiny and they do run Linux.

Assuming I can lay paws on this one old dive computer to rip up, I'm going to try to do SPG function and depth first, and drive a full color LED backlit (or maybe full color OLED screen). I've seen circuit level implementations of accelerometers (this is what the liquidvision is probably using for tap sensing) but haven't ever tried to program against them. I've heard they are a bit tricky or some such, not sure.