SparkFun Forums

[Mee_n_Mac]

Just a little OT ... I saw a NOVA program recently about cave diving in the Bahamas. They were using re-breathers for various reasons and the show went on for a few minutes about how tricky they are to use and how the crew does a lengthy checklist on the equuipment before every dive because, according to the show, some 10% of the divers using them end up dead. Too little O2 is hard for a human to detect and I guess they just pass out w/o ever realizing there's trouble. Were I you, I'd be thinking about how to improve on those odds and make a better piece of gear than what's available now.

An interesting read ...
http://www.deeplife.co.uk/files/How_Reb ... People.pdf

[atedeschi]

Yeah trying to make smaller and easy displays.

[ReLiC]

Howzit Dude ...

I am also on this quest to build a PPO2 Sensor. Have you gotten somewhere ? I have bread boarded up a solution so far with the following.

1. Pressure
2. Temp
3. RTC
4. LCD
5. OP-AMP with O2 Sensor

I am getting readings from all and have started coding the physical app for the arduino. Would love to share ideas around this and some solutions.

[Mee_n_Mac]

The OP hasn't been back in over a year. My guess is you won't get an answer. My concern was that the OP wanted to basically copy (w/a better display) the work Munro had done earlier. I was concerned that his digital panel meter really wasn't up to the task of such a critical piece of equipment. Nor did I get a warm and fuzzy feeling that the OP knew what the requirements needed to be. My GUESS was that proper calibration and pre-dive check was critical to getting accurate info from the unit. That it needed proper engineering ahead of time and not the usual hobbyist level of effort and that meant a good understanding of the error sources and a budget for each.

[ReLiC]

Look, I know exactly what is needed for this and it is not a small task. I have a few people helping me on this and this is R&D that will take a very long time.

I am a software engineer that is now coming into hardware so I have an idea of how extensive the testing and budget should be for this and how much time has to go into this to make it safe. I have hit my first little problem that has caused me to discard hardware cause it is not up to the task. I have sadly come to the limits of the Uno and unfortunately is it not something I can do much about cause its the 32k memory, so out with the prototypes for the Uno, new pro to shields and everything enter the Mega ...

If anyone would be interested in joining the endeavour I would gladly share my ideas and code and layouts I am still on the hardware for the management of everything and the measurement. The other elements of this build being the physical re-breather I am still settling on a design and the pro's and con's of each type of design. I have spent extensive time on the MK 6 rebreather from Poseidon in order to understand everything I can about all this.

Unfortunately I am like a dog with a bone, I am not gonna stop till I am in the pool with my breather working It might not look pretty but it will work ( I specialise in working solutions that dont look good )

Just an update where I am before the Uno reached its end last night

Got all the sensors working and wanted to start logging everything to the SD card ... POOF !!!!!! 36k compile after adding the SD libs. So I have a nice display, working OP-AMP (LM358), working temp, working altitude, displaying the mbar pressure (I need to get it to a meter or 2 under water in order to calibrate and check the pressures so I can convert to meters instead of showing mbar pressure.

So anyone else feel like getting involved

[Mee_n_Mac]

Sounds like you're working on more of a whole dive computer than just the PPO meter. I know nothing about diving but if you want a hardware guy to look over your electronics and critique them ... I'm up for that. Post what you've got or a link to a webpage and I'll have a looksee.

[ReLiC]

Yes I am not just after PPO2 so it is a complete thing. I will get everythihng drawn up on Fritzing and post it for you to have a look .. Give me a day or so to finish off some testing and I will post it up.

I will have to get the dive tables coded for NDL but the comp will have 2 functions. Rebreather and Open circuit... As for not knowing much about diving, we can always fix that

[ReLiC]

Ok here we go ... this is the mock-up of the sensor side.

I cant mock up the SD card and TFT Screen cause fritzing does not have the TFT and SD card with the correct pin out. I am busy getting to that ...

The 2 LED's are to represent the O2 Sensors since there are not O2 sensors on Fritzing. The BMP085 is a temp and barometric pressor sensor and the DS1307 is the RTC.

So looking ok ?

[Mee_n_Mac]

I'll get a chance to look at the above on Mon, it's takes me longer to interpret a Fritzing diagram vs a schematic. But while I ponder that let me ask you the same questions (as I can remember them) that I had for the OP.

In order to be effective and safe, what must the accuracy (+/- some % or +/- some O2 PPM) of the O2 reading in the 'puter be ? Given you can't (always) calibrate the O2 sensors in 0% oxygen and 100% oxygen to determine the slope and offset of the whole chain (O2 sensor, amplification circuit, A/D) ... that in general all you can expect to (? routinely ?) do is a single point calibration in the atmosphere (~21% O2) at whatever temp it is ... what's your thinking re: calibration procedures to eliminate errors ? I can elaborate more if needed but one extreme might be there's no calibration, I hope everything works over the years it'll be used and no matter what the temp of the water is. That might call for some "self calibrating" circuitry in combo with some compensating software.

W/o checking the wiring above, I might assume you have a simple op-amp getting the small voltage out of the sensors (I'll have to look that up again) and gaining it to be read by the A/D of the Arduino. This might be OK (depends on accuracy needed and cal procedures you intend to use) or it might not. I might recommend that (see my earlier post and block diagram in this thread) rather than rely on the internal A/D reference normally used, you use a precision external voltage source. This ensures that despite whatever the battery voltage is, or temperature, that the A/D weighting (how many volts/bit) is constant and remains whatever you calibrated it to be on Day #1 (more or less).

I also question (it might be OK, or not) the use of the LM358. Again I'll have to review the O2 sensor and LM358 specs to know. And ask ... what voltage are you running it (LM358) off of ? I surmise from the above Fritzing, it's the Arduino's 5v. That might be OK (see my concerns on page2), depends on the use of the external reference above and the op-amp specs. For more detail than you might care to know, have a read of the "op-amp" thread in this very forum for all the troubles you may get into using the wrong op-amp for the task at hand. Lucky for you I'm really "up to speed" on this now.

Lastly can I assume the intent is to develop your dive 'puter using the parts above and then sometime, after it's all been proven to work, make your own PCB and condense the parts needed onto that board ?

ps - why only 2 O2 sensors above when the OP of this thread had 3 ? I forget what each was used for.

[ReLiC]

in order to be effective and safe there can be a 5% variance as the levels you are working with should be high 0.5 to 1.4 PPO2. The lowest amount where life is sustainable is 0.16 (after which you first black out) and when it reaches higher than 1.6 then you get oxygen toxicity on deeper dives.

The sensor will be calibrated with 2 gasses. 1 will be 21% O2 (Normal Air) and 100% O2 (Which is checked anyway before putting it in the system so you know that there is 100% O2 before you will even switch this on. The cells will have to be calibrated each time you use them cause the mV output changes over time so you will have to calibrate before each dive basically.

As for the simple op amp, yes, LM358 with 100k and 1k Resistor is used to up the output of the sensor and currently it is on 5V but this I can change so that I use the 3.3V rail. As my program has over run the UNO memory capacity, I will have to look into the Mega that I think just has 3.3V support, either way, I will most likely switch it to 3.3V

The point of this is to first do it on breadboards above water and test and then put in a pool and test. The above water tests will all be done with a breadboard layout so that I can change anything at any point to optimize the circuit. Once this phase is done I will move it to proto boards and start building a smaller version (but at this stage change of components will not become easy so I would like to avoid that.) After it have been proven to work in the pool at about 3m and all is well I will then do a PCB on this and get it smaller. At which point I will probably make it available in public domain so anyone can use it

As for the 3 sensors versus 2, the goal of this is a recreational re-breather and not really a technical one. With technical you have backup on backup, you carry 3 dive comps, the rebreather has a bail out, you carry and off board bail out and so on and so forth, so the 3 sensor are there for primary, backup, and backup of backup but any of these might fail and the user then has to judge.

What I am aiming for is to calibrate the cells before the dive, and calibrate during the dive as well to see that they function properly, aboe ground wil be done with both the 21% and 100% and when diving only done on 21% and the readings compared. If one of the cells fail or stop responding (these cells have a 5 second response time and I aim to calibrate every 10 minutes during the dive.) then it is an automatic abort, which would cause the user to switch to his 21% on board the breather and bail out.

I hope this explains a bit more of what I have in mind and enlighten you to where my head is going. Any flaws in logic would be appreciated if you point them out now

[Mee_n_Mac]

As for the simple op amp, yes, LM358 with 100k and 1k Resistor is used to up the output of the sensor and currently it is on 5V but this I can change so that I use the 3.3V rail. As my program has over run the UNO memory capacity, I will have to look into the Mega that I think just has 3.3V support, either way, I will most likely switch it to 3.3V

I still have to dig up some more info re: the O2 sensors, the PDF I have recommends a 10k load resistor and so the normal high impedance non-inverting op-amp configuration may not be ideal for them. I do recall figuring this all out last time so redoing it shouldn't be an issue. As far op-amp supply voltage goes you want to stay as high as possible. A better op-amp could run on reduced voltages but as it is the LM358 is not a "rail-to-rail" device. When the output has to go higher than Vcc-1.5V it'll start to become non-linear and the reading will be in error. When you request that the output go lower than perhaps 200 mV, the same type of thing happens. Running it off of 5V means it can go to about +3.5V w/o error. Running it off of 3V (it's min supply voltage) is not recommended.

My initial thinking is that I might set the gain so the 0% oxygen output of the O2 sensor gets you as close to 0V as possible and so 100% oxygen (@ 1ATM) gets you to perhaps 1.5V. Then as the pressure increases with depth you could measure beyond the 1.6 bar you mentioned, up to 2.0 bar before the circuitry becomes error prone. Or would you cut it off sooner, at 1.8 or even 1.6 bar ? One "wild" idea that crosses my mind is that you could have a programmable gain amp and change the gain depending on the measured pressure. That way you'd always have the best resolution/least error from the A/D process. I'd have to run some numbers to see if it would be worth the trouble and $$s.

I would use a precision voltage reference of 3.0V, maybe a little higher, to set the A/D ref max. I wouldn't use any offset cancelling circuitry, I'd leave that to software. Ideally then the op-amp's output (amplified signal plus and offset voltage) into the Arduino would always fall into the A/Ds 0 - 1023 range. Calibration would then remove the offset and correct any gain error, the correction terms to be stored in EEPROM (or other NVM).

I would add at least a simple LPF to reduce noise, the bandwidth can be pretty small given the O2 sensor's slow response time. I'll work on a simulation to check all the above tonight, if I can find out about the O2 sensor.

Looking at your Fritzing diagram I see some minor wiring errors for part of the op-amp circuit. See below. Don't bother fixing as I get the idea and would recommend some changes per the above.
(click on to open)

Dive Comp - Mockup_Errors.jpg

[Mee_n_Mac]

Do you know what O2 sensor you'll be using ? If so a link would be nice. It seems they come in a few varieties, each of which would have a different "interface" to the op-amp ... which is why Munro in his design allowed to a 10k load resistor ... no to not have one. The base sensor is a galvanic cell which is a current source. Some sensors add an internal resistor network that turns that current into voltage, and perhaps compensates for temperature as well. Others are "naked".

[ReLiC]

Well none of the hardware is set in stone and the last thing I want is to have issues. I will get 3v to the aref as you suggested and sorry about the errors on the diagram, cant believe I missed that, would explain why my circuit diagram looks wrong.

http://www.maxtecinc.com/docs/sensors/MAX16specs.pdf

This is the sensor I have currently to play with but it can be changed. I will hae a look at a LPF to put in there as well and see how that goes.

Thanks so much for your input, I really appreciate it.

[ReLiC]

Just a though on the programmable gain amp ... how about something like this instead of the onboards ADC pins

http://robotics.org.za/index.php?route= ... uct_id=630

That would free up the analog pins for other worj and also give a better resolution being 16 Bit and there is a programmable gain amp on there to use

[ReLiC]

Just another note, I can set the AREF programatically to 3.3 without wiring anything to the AREF pin. Would this help ? I would however mayb rather go with your suggestion of the programmable gain and remove the LM358 amp ... MIght be the better option although it is a more $$$ one ... BUt at the end of the day rather shell out for the better option.