Open Source Rebreather Project

Rebreathing Red

Hello all you homebuilders. I'm thinking about starting a truely open source rebreather project. I guess I'm wondering if any one would contribe to the project if one was started?

As I see it, the project could be broken down into the following sections
1.Cansiter Design
2.DSV/BOV
3.ADV
4.Counterlungs
5.Hardware ECU
6.Firmware

Anyhow it's just an idea right now....

wedivebc

I trust you have read this thread?http://www.rebreatherworld.com/rebre...ebreather.html

__________________
Cheers,

Dave....

Man is the only animal burdened with the knowledge he will eventually die

robertkarlsson

Well, imho what Alex has done is something we all can benefit from, the result of his very thorough research will help the community allot.

But since this is gear that will be sold i doubt we can just take a 1:1 copy of his design and build it.

Imho, with truly open i think the design, software and the implementation should be free to anyone to implement and modify.

I started a small project, nothing fancy just in the startup. Added my ideas and design thoughts to a internal wiki. I will put it online later when i think it has enough substance. Then people with way more experience and knowledge can bash my ideas and thoughts or contribute and make it better
I believe with all this huge amount of knowledge and experience that is found here it will be a good thing.

As a sidenote i have started to build the software controlling the rebreather functions. As it is now im developing it in two separate modules. One is the controlling software and one is the simulator.
The controller/simulator is basically an gui built on Jruby/swing where it runs multiple threads to achieve some type of parallelism on the hardware it simulates. Eg one thread for each sensor and input parameter. The Rebreather controller software module is separated from the simulator, the only thing it sees is the variable from the sensor outputs. This is to simulate sensor data poller. The reason i want them separated is thati want to have a controller logic that can easily be adapted to be used with the actual hardware instead of the simulator.

So with the simulator i can test different cases and see how my controller logic solves those issues. e.g. sensor errors/failures. The plan for now is that it all will run on a slimmed down version of a stable Linux / BSD kernel. As for controller i will use an rugged power efficient ARM based microcomputer.


I'm also pondering the best way to deliver sensor data to the contoller logic. I first thought about using RF and send it to the controller logic.
The pros are that i dont need the weakness of the cables and i also can send it to multiple controllers at a single time for redundancy without making a hole in the casing to the controller compartment. Maybe its even possible to send the data directly to a handheld sensor display(that will require a longer range and im sure it complicates things)?
The drawbacks of all this are that i will need more electronics and also a battery to the transmitter and A/D.

Using a cable, the pros are that i don't need external electronics and extra power source to get the sensor data. The drawback is that i need to make a hole to controller compartment. And if i need redundancy, eg multiple controllers i need to make multiple holes.

This all started as a project for me to get a better understanding of ECCR rebreather working principles and i like to tinker with things

Any feedback are highly appreciated.

mik

What about fibre-optics transmitting light from LEDs for the controllers rather than cables? There would be no breach of watertight integrity that way.

__________________
It just fell apart in my hands, Chief!

jsevland

Hi

I'm not (likely) to build my own eCCR, but as part of my simple Evolution simulator I have been pondering the suitability of RF underwater.

Bear with me on my naive approach:
- Developing the wrist display controller on a J2ME platform
- Using "standard" Bluetooth for RF communication
- The setpoint controller(s) should be keept as simple as possible (not on Java), but with an RS-232 to Bluetooth IF

The advantage is that the development platform for J2ME is well supported,
and there are plenty of test-devices (any new mobile phone).
During development, simply stick the phone in a waterproof casing and dive it :-)

For production, the hardware needs to be a dedicated design, but using standard components (J2ME and Bluetooth).

I realize that Bluetooth is not without problems, both stability and RF underwater. To overcome RF transmition under water, could one use a cable as an antenna? The "antenna cable" would look like a normal cable, but there is little need to pressure guard it - since it is just a piece of metal to run the RF over.

Anyone who's tried Bluetooth periferals know that it can be a hassle. So it may be asking for trubble using it in a critial design. On the other hand, the community using Bluetooth is huge, and stability should improve.

This is just my $0.02, and I assume people like Alex would give it a horrible MTBF estimate ;-)

jsevland