Discussion - eCCR controller - price and what's gotta be there

Genesis

I'd like to open a discussion about what everyone thinks "has to be there" in a homebrew eCCR controller.

My intent here is to toss out some ideas that I've come up with (and which are either going into or ARE in the one I'm building right now), along with some targets.

First, targets - I believe that its reasonable to shoot for:

1. Housing cost under $150 in small quantities (two magnetic switches, one cable gland, housing itself proof tested in a pot to 10 ATA minimum)

2. Controller cost under $200 complete, less consumables and external items (e.g. sensors.) This is DEFINITELY doable, even in quantity 1. Controller goes in the head - the actual uP is less than 1 inch square, discretes and associated ICs (solenoid driver IC, ADC, DS I2c RTC, op amp, bypass caps, protection zeners and misc "stuff") will push this to roughly 2" on a side on a through-hole PCB or wire-wrap; display requires five wires (three for the LCD, +5V, GND, DATA and one each additional for each switch) on a fischer or E/O-style connector (the latter is what I prefer but those will blow the budget from the pricing I've been able to obtain thus far.) Alternatively you could hard-wire the cord cheap with two cable glands. Power can either go in the head or for super-long life and easy to build use a small (e.g. 4.5ah) delrin light can. Secondary HUD display, if you want one, would be well under an additional $100; there's an argument in that case to be made for putting the Opamps on a small driver board IN THE LOOP; the ADCs I'm using are 12 bit and with a 10:1 amplification ratio return sensor values to within 0.1mv assuming you use discrete components with tight enough tolerances.

This puts the whole shooting match well under $500, including solenoid and sensors (of course sensors need replacement every year or so.)

Here's my thoughts on the control and monitoring functions:

1. PO2 control/reporting
   • Monitor 3 sensors (2 optional).
   • Operate solenoid only if all agree within reasonable tolerance (explicitly declare a "fault" on a cell error, suspend solenoid function, instead of trying to "vote one out" and assuming that the two are good and one bad. In the event of a cell fault PO2 display is still active - your brain becomes the computer ) This is known as a "complacency reducer".....
   • Adaptive injection based on distance of the loop from desired PO2, user-controllable minimum interval between injection events (trade-off here is between a possible runaway in the event of a current-limited set of cells or electrical fault .vs. the "tightness" of control of the loop PO2)
   • PO2 settable from 0.7 - 1.6 in steps of 0.1
   • Declares "critical fault" and alarms (minimum flashing backlight on LCD, optional buzzer) on PO2 < .20 or >1.6 on any sensor.
   • Operates "common" solenoids with current draws up to 500ma @ 6V using a standard and common driver IC.
2. RTC, date/time, non-volatile backed up to some extent (either large capacitor or secondary lithium coin cell)
3. Backlight timeout in 10 second intervals from 10-50 seconds. Light illuminates on any keypress.
4. Data logging to EEPROM ("black box") sufficient to cover the maximum reasonable/possible single dive, not user clearable (builder read-out only.) Must log sensor mv readings, depth (if sensor is fitted), selected PO2 and other user-initiated parameter changes, and timestamps (e.g. timestamp when scrubber lid last opened, cal run, etc)
5. RTC display on handset at all times (useful for timing stops, etc)
6. Automatic calibration/verification demand on a timed interval (e.g. one week since last calibrate.) Must calibrate in atmospheric air (open scrubber), detected with either a reed switch or photocell sensor. Forced verification using O2 flush after calibration. Refuse to go into "dive mode" if calibration is out of date or fails. Refuse to calibrate if sensor is marginal in air (indicating potential current limited sensor at depth.)
7. DESIRABLE: Verification of hyperbaric PO2 (e.g. 1.6) required on the same interval or the unit will not allow a setpoint over 1.0 to be selected.
8. LCD "dive mode" display (2x16 LCD, backlight programmable selective) has all three PO2 displays, setpoint, and RTC in normal operation.
9. Two-button support (magnetic reed or hall-effect) for menu/select and increment/confirm buttons. Press of any button when LCD is off turns it on but takes no action. No repeat on buttons EXCEPT for set-time function (otherwise it takes forever to actually set the time/date!)
10. Low power consumption in operation, microamp draw when "sleeping".
11. Operates on commonly-available battery options (e.g. 6VDC) easily built up.
12. DESIRABLE: Wet contacts to put the unit to "sleep" when out of the water.

Any adds, changes, or deletions out there from others? What would YOU like in there?

About 90% of what's in this list right now is in the firmware/unit that I have running on my workbench, and the rest is a matter of coding and verification (the calibration/verification has to wait until I have loop construction finished and can run tests - simulation accuracy is difficult without that) The controller costs are running WELL under the target as things stand right now.... with no expectation they will go up, as I've got all the hardware here already. I've got a LOT of space (only about 20% consumed) remaining for code as things sit right now.....

This is running code on a running controller right now - not a "design goal". The attached images show some of the screens - the "*" in the first one indicates that injection is actually occurring at that moment (took a few tries to catch that with the cam) - the "verify" of the bump in the PO2 from injection is currently commented out since I do not have a "real" loop at the moment and I'm running some "worst case" power consumption tests at the moment on it (thus the locked-on backlight as well in the config - set to "zero" timeout, or infinitely on.)

The others are some of the setting screens.... No mock-ups here - this is all fully-functional (on a breadboard, natch) right now - all the settings can be modified, and do what you'd expect.

Display is 2x16, approximately 3.25" x 1.5"; should fit in a nice compact housing..... nice big display too; great for people with "less than perfect vision"

Sorry about the focus on some of these; my cam is having a shizfit due to low light levels with the backlight - probably more camera shake there than real focus trouble

lilou

Hello Genesis,

Interesting work, on which micro controller do you work ?

Best regards

Lilian

TR300

Hi Genesis,

I also playing around with this Ideas.
My Idea was to have an "allround" usable controller, best with to watersealed connectors, one for the Sensor and one for the selenoid so it can be fixed on a bunch of rebreathers. The main controller should be in the housing.

Holger

__________________
If it makes bubbles it means its brocken
Visit: www.tr300.com, Missions: www.rebreatherteam.de

PCDiver

Why don't you guys try wireless?

Main computer in the box while all other peripheral devices like HUD, consoles, buddy display on the back, ... communicate with the controller via some underwater wireless protocol. It needs to be two-way. Commands from the console to the computer and status info from the computer to all other devices.

Just an idea.

Scuba_Vixen

How about for the same reason that no one diving at tech levels uses a wireless computer for tank pressure data:

There's wayyy to little gain for the additional failure possibilities.


Darlene

Genesis

I code for several general-purpose microcontrollers (both in various HLLs and assembly) but this particular implementation is running on a BS2pe. The code has to be written very "tightly" due to extremely limited RAM space but that has not proven to be a significant issue thus far...

There's nothing preventing this from going in the handset; the "gotcha" with putting it there rather than in the head is the number of wires necessary.

For integrity reasons I do not want sensors and power-level stuff in the same wire - that's a severe engineering "no-no" in this sort of environment.

PCDiver

Isn't the main reason that tech divers don't use wireless computers for tank data, that they tend to have multiple tanks and not enough receivers/transmitters?

Having reliable underwater data transmission, even short range like a couple of meters, would make other features available. Think about data logging, instructor monitoring, even controlling the unit of a student. One big benefit is that all the "peripheral devices" are isolated. So failure of one does not compromise the integrity of the main unit. It would also make CCRs cheaper. Less expensive cables, less connectors. A handset breaks down ... no problem, just take a spare one and link it to the CCR. It would even be possible to create a standard interface protocol for third party devices.

Genesis

I ran a wireless pressure transducer (Vytec) for a couple of years.

I stopped not due to reliability problems but due to deciding to go with Apeks DS4s, which wouldn't route cleanly with it.

There was one nasty glitch I discovered, which was that if you did a valve shutdown it would reset its pairing code and thus you'd lose pressure info! Not good! Suunto sent me a new unit with different firmware that avoid that "gotcha".

Wireless though has a number of problems - RF doesn't penetrate the water well at all unless its very-low-frequency, the power required is MUCH higher than wireline signalling - even higher than optical - and it also runs afoul of FCC regs in the states (read: expensive rules relating to making something you can sell commercially) unless you use specific unlicensed bands which happen to be not in the right places for underwater use. There is also the possibility of interference with others with the same gear; you have to be careful in your engineering to preclude this sort of thing, otherwise you could have a handset that is reading your BUDDY'S loop instead of yours! That could be REAL bad....

Another possibility is optical signalling. This avoids housing penetrations as well (e.g. sealing things in 1 ATA "capsules" becomes entirely reasonable), its easy and cheap (just a phototransistor and IR led pair at the minimum), if you define a protocol you can insure data integrity (e.g. CRCs or checksums) and it also enables "plug and play". For the cables you could easily use the home audio "Toslink" light-pipes - they're inexpensive ($20 in 3' length) and have no metal parts in them nor any airspaces - ergo, no corrosion concerns. It also provides complete isolation between components. The bad side is that this "isolation" comes with a cost - each "item" now needs its own independant power source (some would say this is a feature rather than a bug)

Genesis

BTW, to expand on the "what controller" question a bit... this is what's currently "on the breadboard".....

uP - BS2pe (Parallax) - 32kb EEPROM program, 32kb EEPROM data ("black box"), very low power - 15ma run, 36ua in sleep mode.
LCD - Generic serial LCD display - this one needs some work to get power consumption down, as it is, comparatively, a pig (20ma)
ADC - TLC2543CN, 11 channel, 12 bit ADC, serial I/O (Data/Clock/Chipselect)
RTC - DS1307 (very cute I2c device - has a coin cell battery input for backup and automatic power switching. Also has some scratchpad "RAM" that is battery-protected)
Solenoid driver - L293DNE, general-purpose 4-channel high-current driver

steevke

Genesis, look into polymer led displays.

I used one of those for a design project lately and they are very very yummie!

http://be.farnell.com/jsp/endecaSear...=4141921&N=401

Regards

Steven