My computer idea... opinions?

tele

(I do not have rebreather experience yet, although I am going to try to take a Dolphin course this summer. I was looking at the prices on the Oxygauge, and got to thinking there might be some new ways to do things.... others have done DIY ppO2 displays so this would borrow some information from them with regards to power stability for the sensors and such).

1st, for the cells what about mounting each cell with it's own battery (liion) and micro-controller (atmel perhaps). The micro-controller would use it's ADC to sample the o2 sensor, and another one to monitor the battery. This information would then be sent to a bright LED or laser diode module. The o2 value, the battery value, and a checksum would be transmitted digitally, serially by light.

2nd, for the controller. The case would hold two separate computers, with two separate batteries. A similar micro-controller would be used. It would monitor the battery level. Data input from the cells would enter the housing optically, and be split optically to light detectors for each micro-controller. So the data from each of three cells would hit both micro-controllers, which would in turn drive two COLOR GRAPHICAL LCDs that you can get CHEAP, think the LCD displays on modern cell phones. White LED back lighting.

In addition, optical LED (not laser :-) outputs could be driven to drive a HUD that operates without copper cabling as well. Nothing but light pipes.

The battery recharging could be done using inductive coils, similar to electric toothbrushes. No physical copper outside connections.

Changing settings could be done by using different software on a PDA or laptop PC or some such, using a USB cable that terminates in a LED similar to the sensors. You could use the LED HUD output from the micro-controllers to read data, and the optical input for communications to a configuration application.

This would eliminate all copper interconnects, and it might be possible to shed weight.

Of course, there are definitely more batteries to deal with
in this configuration.

The computers could both warn of battery issues in any of the sensors, display ppO2.

Perhaps do the whole thing open source?

Thoughts? (Feel free to tear it up :-)

Dsix36

I would love to, But it is all way over my head

__________________
THE MORE THAT I LEARN, THE MORE THAT I STILL NEED TO LEARN!!!!!!

tdzao

What you are describing is very very similar to what the Liquivision X1 O2 link module already does. It avoids copper interconnects and uses LED's to transmit the data. It will be available around DEMA '08, and works with existing X1's. All X1's have a glass window on the side with a communication photodiode/LED transceiver.


Eric Fattah
Liquivision Products

tele

Looked it up! Very nice!

I've located a really old dive computer I've been after for a while. If I can lay hands on it, I plan to re-use the case to work on building my own simple digital SPG ... color graphics, etc. Then see if I want to go farther. The old computer should have pressure sensor for tank pressure and perhaps water pressure/temperature. I should be able to read these with a modern micro-controller.

The liquivision unit ... VERY nice hardware!!! Slick unit, nice case.

Freef

If you are on a Dolphin then the controller aspect is redundant anyway. My idea is here:

http://www.rebreatherworld.com/rebre...tml#post154938

with some comments by AD_ward9.

Most incidents that I have read about on here are to do with user error, those that aren't seem to be battery problems.

Tecme [ Tauchen - Cave, Nitrox, Rebreather Ausbildung, Tec Ausrüstung, Reisen ] have a choice of monitors and have a very good reputation for service.

__________________
David.

Currently owner of two differently sized ankles.

robertkarlsson

Funny that you mention this, ive been in the thoughts myself, but instead of using optical link to transfer data how about an RF transmitter.
I was just thinking if one could have the controller/computer encased in a plastic material like for instance Delrin. Wouldnt it be possible for the transmitter to send the sensor data through that thin piece of polymer even if the cells/transmitter have been all flooded?

I was thinking of a transmitter similar to what is used in some cars to monitor tire pressure. Like for instance:

http://www.atmel.com/dyn/resources/p...ts/doc4616.pdf

If its needed maybe the case would need some copper webbing to create a faraday cage to shield from possible interference.


Anyways i'm just speculating.

I was thinking of taking it even further, to have the microcomputer controlling the rebreather functions running a custom build of Linux/BSD.
And the controlling system should be running a higher level language. Imho,
writing in C/C++/ASM one has to deal with memory management that most likely will cause annoying and hard to find bugs which forces one to do allot of testing to straighten them out. If we abstract that layer one can concentrate on building a good solid controlling logic.

And of course it should be all opensource, from the cad drawings to the code.
One idea would be to have lets say a public wikipedia for building a rebreather, where people add their ideas, experience and knowledge for
all to benifit from, free for anyone to implement. Maybe in the end it will result in something better and safer.


Just my thoughts




Cheers!

PaulTG2

Hello,

If you're going to use RF why not just use bluetooth. Good for short range and low power, base-level security, and they have off-the-shelf technology for use in extremely small packages.

One of the likely problems with RF is the vast differences in various countries for the legal sale and use of RF systems. IR links don't have the same restrictions.

-p

tele

Ah very nice! One thing is always the more complex any system is, the more chances of issues.

An argon laser system I have (odd hobby I know) has a water flow meter to make sure the water is moving through the cooling jacket at the high rate required. It's got this neat monitor that involves a spinning wheel, that drives an optical pickup wheel that feeds a rate counter circuit. I was thinking something like that could be used to verify solenoid firing, but it might not work with short bursts of gas versus liquid. The thread above confirmed that there is solenoid verification. I guess it could be done through EMF generated from the coil firing, or from an optical gate that is broken.

tele

Hey guys, I already looked into the prospect, of building (for fun) a system that allowed text messaging underwater. It's _NOT PRETTY_. My thought was a small output device with the diver(s) that has some sort of passive data entry that is quick, and then a "gateway" on the surface running BSD or Linux that takes message traffic from internet protocol over cellular data networks and passes it into the water.

Bluetooth and 2.4ghz radio based technologies will not work. Water is water, and that kills them. You pretty much have to go VLF (Very low frequency) as far as I know, and generally the transmission setups for that isn't lightweight. Generally the lower the frequency, the longer the antenna.

I have not checked underwater wireless comms boxes to see how they do it. I did find some various bits and pieces that looked juicy, and tried to contact a hardware vendor or two but found little response. There was a DSP based module for passing data from underwater sensors, but I think it would be cost prohibitive for a youtube brag video. That was the company that never responded. Some small outfit, perhaps in .au if I remember.

I don't know how true it is (I don't own one), but I've heard the dive computers that wirelessly transmit the data from the pressure sensor to the computer hit a bunch of errors just moving the data in the short distance. I've heard it isn't displayed on the handset, it just displays the good receives (based upon a checksum, and mathematical checkout of the passed data). I can't validate this or confirm it, I just remember reading it somewhere (perhaps usenet archives). Not that it has that much of an effect, if the xmitter sends it ever second it's not like a few missed receives would be detrimental. I don't know if there is a way to display an error rate.

camerone

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...