REALLY complex project- Where to start?

Thread Starter


Joined Dec 15, 2012
I do not have very much experience in embedded electronics. Most of my experience is simple Arduino projects. I do quite a bit of diving and have fairly recently started diving a closed-circuit rebreather. While I feel the model of rebreather I currently use is the best currently on the market, I am not satisfied withe the electronic-controllers currently available in civilian closed-circuit rebreathers. My primary gripe is lack of redundancy and fault-tolerance in the electronic controllers. So basically, I have come to the conclusion that it might be an interesting experience trying to build one on my own.

The basic function is as follows:

3 galvanic oxygen cells are exposed to the atmosphere of a closed breathing circuit. These sensors produce voltage (around 14 mV in air) when exposed to oxygen and their readout is linear in nature.

3 cells are interpreted by the electronic controller. This controller has a stored calibration value and converts the cells' readouts from mV to partial pressure of oxygen. These values are displayed in Atmospheres of pressure (ATM) on a display.

The controller opens a solenoid valve and injects oxygen in the breathing loop to maintain a setpoint (typically 1.3 ATM of O2).

The controller also monitors several other sensors including several temperatures (system and environmental), absolute pressure, and ambient light just to name a few, and uses these parameters to display other pertinent dive info as well as system status.

As far as the general architecture of the system goes;

Two separate power supplies that will automatically take over for the other if one should fail will drive 3 op-amps that will amplify the 3 cells. Each output will be channeled into an ADC.

Data from all three cells will then be processed by triple-redundant flash-based FPGAs. Voting logic will be used to vote out a faulty O2 cell. The solenoid will be briefly opened when the partial pressure of O2 in the breathing loop is determined to be below the setpoint.

Separate from the triple-redundant FPGAs are dual ARM microcontrollers functioning in lockstep. The primary role of these controllers will be to perform the functions that are not critical to life such as system temp and absolute pressure. These controllers will also monitor the function of the FPGAs and should there be a total failure of the FPGAs, they will be able to take over life support functions and maintain the setpoint. Naturally, if an error occurred in any of the subsystems the diver would be alerted in order for him to abort the dive before a total system failure could occur.

Obviously this is just a very, very brief description of what I want to do.

Anyway, my question is where should I start? I know this is a huge and very advanced project, however, it is also really the only reason I am getting into embedded systems at all so I kind of want to get started on at least bits and pieces of this project as opposed to doing all kinds of other stuff to build up to this. Primary what I would like help with is:

1. Do I need a FPGA "development/evaluation board" or something else altogether? I would like to spend as little money as possible and try to only buy what I really NEED to build this controller.

2. Are there any books or resources you can recommend to help me get started?

3. Are there any MAJOR issues with my general project idea and if so what can I do to fix it?

Thanks for all the help!


Joined Jun 19, 2012
I would start with some good burial insurance.

No, seriously, this sounds fun and challenging, I would start by analyzing the architecture of existing systems in detail before trying to design anything, read lot's of patents and take apart some real gear.

Projects like this are more 'meta' that you think, keep your eyes on the big picture.

Thread Starter


Joined Dec 15, 2012
I would start with some good burial insurance.

No, seriously, this sounds fun and challenging, I would start by analyzing the architecture of existing systems in detail before trying to design anything, read lot's of patents and take apart some real gear.

Projects like this are more 'meta' that you think, keep your eyes on the big picture.
As far a burial insurance goes, I've got the good policy, lol. As scary a it sounds, you never really actually trust your life to a rebreather. In fact, almost every unit on the market has at least 2 methods to monitor the O2 levels and most people I know actually run the unit "manually" with the electronic controller as their "parachute" so it is a lot safer than it sounds.

As far as other units are concerned, many units are nowhere near this level of complexity. In fact, there are some units on the market that run off a single microcontroller and nothing else. My unit's electronics package is probably one of the best currently in production and it has 3 microcontrollers that all are assigned separate functions, however, for each function, there is a primary controller to which that function is assigned and then there is a secondary microcontroller that can take over that function. For example: microcontroller 1 controls the setpoint while microcontroller 2 drives the LCD display and Microcontroller 3 drives the heads-up display. If mc 1 crapped out, mc 2 would drive the LCD and control the setpoint. But it is not true triple module redundancy, because if mc 1 and mc 2 whent out, you would not have setpoint control, but mc 3 would take over driving the LCD in addition to driving the HUD. If this happened, the dive would add oxygen manually based off what he saw on the HUD and LCD and abort the dive.

There was a unit that has not been manufactured since 1999 (and there were very few ever made) that actually had true triple module redundancy with voting logic at the microcontroller level, but they are just not available to purchase and there is really nothing else that has been developed that is anything close to that unit.


Joined Mar 31, 2012
I was approached about 15 years ago by a professional underwater shark photographer asking me to do something similar but for a different reason -- he was using surplus military gear and it was getting hard for him and his colleagues to find replacement parts. The deal fell through because adequate commercial gear apparently started becoming availlable about the same time (that's what I heard from him, anyway), in part because surplus military gear was becoming hard to get. So I'm passingly familiar with what you are doing and the manual safety options that are likely available should the electronics fail.

I would start by listing the features you want to eventually include and prioritizing them. Then I would design each feature, first without considering failure modes and then with enhancements to support the failure modes. Then prototype each of the high priority features (without redundancy) and get them working individually, first without worrying about supporting the failure modes and the with that support. Then I would look at combining them to support the redundancy you want.

Along the way, you will need to make a lot of decisions such as how you will detect that a given controller has gone south, how the controllers will communicate with each other, how you will avoid single-points-of-failure in the system, and on and on.

The beauty of a project like this is that you have a personal interest and the project has tangible goals.


Joined Mar 31, 2012
If you can find a development board with many/most of the features you think you might eventually want, it will probably be worth the money. Assuming you can find suitable versions of everything you need (i.e., suitable for use on a solderless breadboard or wirewrap board), you will quickly discover that wiring up something as complex as you are heading toward will be extremely time consuming, error prone, and fragile.

Thread Starter


Joined Dec 15, 2012
Ok, thanks for all of the advice thus far. I have never prototyped a project before that was beyond the capabilities of a single breadboard so all the tips y'all have been giving are much appreciated.

As far as a list of features and systems is concerned, I plan on using the FPGAs to run the actual "life support" systems. The ARM will run the less critical systems whose failure would not likely result in death.

The systems/features on the FPGAs would include:

Setpoint control-

This system measures and maintains the partial pressure of oxygen (set by the user) in the breathing loop. It consists of 3 basic functions:

1. 3 galvanic O2 cells in the breathing loop output voltage when in the presence of O2. Cell output is linear and ranges from 0-approximately 100 mV. Output of each cell is compared to a calibration value set at system startup. This calibration value is derived by exposing the O2 cells to a gas of a known O2 content (typically 100% O2), compensating for atmospheric pressure (measured by an absolute pressure sensor), and deriving a calibration factor for each cell to convert mV to partial pressure of O2 (PPO2). The PPO2 readings are averaged and if a single cell deviates too far from the value of the other 2 cells, that cell is voted out. Outputs from a temperature/humidity sensor in the breathing loop are also used to adjust PPO2 readings as the output of galvanic O2 sensors varies slightly with changes in temperature and humidity.

2. The derived PPO2 of each cell is displayed on a LCD display. A multicolor LED on a Heads-Up display blinks in a specific code that reflects a PPO2 value from an O2 cell. 3 separate groups of LED pulses correspond to each O2 cells' reading. A "Buddy Light" located on the rear of the rebreather unit mimics the pulses of the HUD in order that other divers in the team can easily note the status of the unit at a glance. If the loop PPO2 reaches a dangerous level (<0.6 ATA or >1.6 ATA) or if PPO2 deviates more than 0.3 ATA from the setpoint, the LCD display and HUD switch to their brightest setting, an audible alarm begins to beep at its loudest setting, and a vibration motor mounted in the mouthpiece begins to pulse. These alarms continue until the breathing loop PPO2 is no longer at a dangerous level.

3. When the loop PPO2 drops below the setpoint, a solenoid opens and injects O2 into the breathing loop. The duration that the solenoid is open is based upon deviation from the setpoint so that the solenoid opens slightly longer the lower that the loop PPO2 drops below the setpoint, however, there is a maximum duration that the solenoid can be opened as to prevent O2 spikes.

Power down prevention/wake up system-

This system prevents the controller from going into low power sleep mode or wakes the system upon certain conditions.

System will automatically wake and attempt to maintain a breathable atmosphere upon:

Sensing a PPO2 <0.18 ATA
Sensing a pressure equivalent to 5 foot of sea water (fsw).
Sensing the pressurization of the O2 system through a pressure transducer.
Sensing the pressurization of the Diluent system through a pressure transducer.

If the controller is woke from a low power state in this manner and either the diluent system or the oxygen system is not pressurized the HUD and LCD will go to their maximum brightness and display a warning, the vibration motor in the mouthpiece will pulse, and an audible alarm will tone.

System will not allow the controller to go into a low power mode until:

Depth sensor registers <1 fsw.
Pressure transducer no longer senses pressure in the O2 system.
Pressure transducer no longer senses pressure in the Diluent system.

The systems/features on the ARM processor will include

Dive guage-

Recording of time, depth, water temp, and PPO2 on a flash memory device.

Upload of dive data to a personal computer post dive.

System monitoring-

Monitoring the function of the life-support systems.

None of the features I want to include in this controller are really new features. Really what I want to set my controller from the rest of the controllers is redundancy and fault-tolerance, which I understand is something that comes later in the design process.

So to start out, I have to select an FPGA to work with. I am just starting to learn about these chips and one of the things that I find kind of confusing and difficult is understanding the size of the FPGA as it relates to how much I can make it do.

Do you think an Actel Igloo Nano with 250,000 system gates would be sufficient for a system like this or would I need a bigger FPGA?