Controller pics..... :)

Genesis

Thought you folks might like these.....

No mock-ups here.... (sorry about the crap contrast; the flash interacts oddly with the display; I took these with the backlight off so that I didn't get "shake" from low shutter speeds....)



[imghttp://www.denninger.net/ccr/DSC01948.JPG[/img]











Questions? Feel free to ask!

Scuba_Vixen

I see you got the new 4 X 20 LCD in.

Looks great!


Darlene

wizbang

Yep nice work, looks great.

Crazyduck

Very Nice sir!

What are you going to put it all in??

Andrew

__________________
Howdy Senor- What’s Happening!
Rob Davie April 2005-

Presently in a state of transition from Open Circuit to Closed Circuit.

"You will not be punished for your anger; you will be punished by it." - Buddha.

Andy M

Ah! the BIG question!!! Electronics are straightforward. Keeping it all waterproof is the problem...

__________________
Know your PO2 at all times

Genesis

I'm going to have a housing milled out for the LCD - its just an I/O device. The connection to the wrist unit is 6 wires - +5, Gnd, LCD Signal and two for reed switches for the buttons (left/right) plus an output for an alarm alert (either a shaker motor or a pizeo buzzer)

I looked at Hall effect sensors for the switches and there is one disturbing reality with them - they consume about 10ma EACH! That's a LOT of power - the enitre LCD, backlight off, is 20ma (but 80ma with the backlight on!)

The CPU is going in a 4.5ah light can along with the battery. It will fit on my standard Hog-rigged harness behind my actual can light (if I'm carrying one - I usually do, even in open water) without problems and is a nice convenient thing to buy that is watertight. No switch - if the batteries are in it, its "on". 5 NiMH 2800 mah cells provide approximately 60 hours of runtime with no solenoid, and ~30 hours of diving - way more than you need and they're individually chargable (in a Maha 4-AA charger) - so this is a nightly deal, but that's good. In a pinch 4 AA alkalines will also work. The CPU also has a Dallas 1307 RTC attached with a lithium coin cell that will hold the clock up for about 2 years.

The CPU draws 20ma when running - but its duty cycle is only about 10%. The rest of the time it draws a few tens of microamps. As such its total power consumption is closer to 3ma on a time-weighted basis.

The CPU board is 2.5 x 1.9" in size complete. It will fit down the "bore" of a standard 4.5ah (or 9ah for that matter, although that one is way too long for what I need) light can. It will be attached to a bracket that will be affixed to the lid, so it comes out when the lid is withdrawn. The CPU board also has control of the peripheral power - on the surface it can shut the LCD (and sensors) off most of the time to save power. I'm still mulling over whether its worth utilizing that to extend battery life - the main consumer of power is the LCD..... The CPU board has a DB9 on the "tail" end of it for field reprogramming or "black box" data download (the latter is one that I hope nobody ever wants to use...)

I considered putting the CPU in the wrist unit but decided against using a charge-pump to crank up a 1.5-3.6V supply battery (e.g. one of the SAFT cells) due to power consumption issues. Yes, it works, but the amount of juice in one cell means relatively short runtimes or using EXPENSIVE disposable lithium batteries. I'm adverse to opening electronic things on a boat that have O-ring seals in them if I can avoid it; comes from using cameras a lot and not (yet) having ruined one. For that reason I wanted a design that I could count on to be "live" for a full diving day without having to be opened up, and I hate the idea of expensive disposable batteries.

The head has a small (also 2.5 x 1.9") board in it which has signal conditioning for the sensors (3 O2, 1 pressure - consisting of signal amplifiers and the A/D converter) and the solenoid drive circuit on it. The latter board will be 100% potted and is a "throwaway" if damaged - its roughly $50 to replace it, so in terms of the "aw %$@$" factor it puts the "hurt" on you less than an O2 sensor. It talks to the CPU using a digital signal - it either works or it doesn't - and the A/D has internal "integrity" checks available (in the form of dedicated pseudo-channels that read zero, full-scale, and half-scale all the time) so the CPU can check on its health. Having the solenoid firing on that board also means that the system can check battery voltage during a solenoid firing cycle, detecting the "dip" that comes from batteries that are getting weak before it causes a CPU reset, and thus give you an alarm and solenoid lockout rather than a surprise. Power draw of the head board is surprisingly small - I measured it at just over 3ma.

The design calibrates in air. You must validate high PO2 readings (anything over 0.5) before you can use them. At depths under 20' you may perform an O2 flush (including on the surface) and then select "Validate" - the unit will permit a setpoint of 0.1 less than the maximum validated PO2 which you've experienced. This should prevent a current-limited cell situation from turning into inappropriate injection and a tox hit. Of course you can always manually inject rather than "trusting" the CPU to fly it for you. Validation, once done, expires one week later - so if you validate at least weekly on deco it will never expire on you, but if not, you will have to do it again before hyperbaric PO2s will be permitted.

Calibration is forced daily; when the unit is powered up and a date boundary has been crossed since the last calibrate it will refuse to go to standby until you perform a calibration. You cannot calibrate unless the head is physically open (checked with an "open lid" sensor) and the depth is zero (on the surface.) The unit also rejects a sensor with more than 13mv or less than 8mv of output in air during calibration.

Basic bottom timer functionality is included, including a seconds counter for both dive and surface modes, so timing stops is easy. No attempt to provide deco information is made. I intend to use a 4th cell tied to my (existing) VR3 for that purpose, with tables and the bottom timer in the unit as backup.

There are also alarms which fall into several categories (critical and non-critical, latching and non-latching.) Latched alarms are reserved for power-related conditions (e.g. no solenoid drain detected or low battery) and cannot be cleared. The handset has an "audible/vibratory" output that activates during alarms along with the backlight being flashed - I'm not yet decided on whether I'm going to put a small pizeo buzzer inside the 1ATA space or will use a cellphone "vibrate alert" shaker motor....

Genesis

Some info on the "crash log" that's in the controller....

I'm not implementing a "dive log" per-se. The controller I'm using has 32kb of EEPROM, half of which can be used for program code (the rest is data-only, although you can put data in the "low" pages if you don't need the entire program space.) It is organized into 2kb "pages", 16 in total.

I also have available 56 bytes of battery-backed SRAM on the Dallas 1307 chip that also holds the RTC. The SRAM has the advantage of being indefinitely re-writeable, while EEPROM has a fixed maximum "service life" (write cycles), after which it is toast.

I'm using most of the bottom 8 pages for code, so have reserved the entire low block for that purpose.

The top page (15) of EEPROM is dedicated to holding non-volatile parameters. This is radically more than I actually need, but since I never access that page space except when retrieving parameters it reduces the risk of a program bug corrupting the saved space. NV parameters include things like the calibration divisors (for the O2 cells), backlight timeout, setpoint, injection interval (time between injection events), and the depth sensor calibration constants.

Now this isn't a huge amount of memory, so some efficiency trade-offs are called for. I've decided to log in 8-byte increments as fixed-size records - some may argue this is inefficient, but we'll see.....

The total space available is therefore 256 8-byte samples per page for 7 pages, or 1,792 samples in total. If we log once every 10 seconds, this gives us almost 5 hours of active logging - enough for a "crash log."

I next turned to the problem of overwriting the log once the "bad thing" happens. This is a major problem with any computer that can run for a long time without exhausting the battery. In this case, the battery life, with no injection and backlight off, is expected to be in the neighborhood of 60-80 hours on a full charge - way, way longer than the log duration. Not so good.

So to address this I've decided to log only on status changes.

I'm logging the sensor levels for all 3 O2 cells (individually), a short-form timestamp (minutes/seconds), the V+ battery state, depth and the alarm mask (a bit-mask containing low PO2, high PO2, low Bat, no O2 sense, system fault and sensor fault.) PO2s are down to the hundredths (as displayed), voltage to the tenth, and depth is bit-shifted one position right (so each "count" represents 2 feet, giving a maximum possible indicated depth of 511' with resolution of 2' per increment.) At most, we will log one sample per 10 seconds - but if no changes are detected from the last sample, then the log entry is not written. Exceptions are that we log one entry per hour as a timestamp with the full date and time, and we also write a timestamp as a "validity check" on EEPROM page switches.

This means that for a crash analysis logging should cease when the "event" occurs and the wearer stops moving/consuming oxygen. As such when found, the data in the controller SHOULD be valid up to the time of the incident.

The SRAM on the Dallas Chip is used to maintain the EEPROM pointers, so they remain valid even across a battery change on the controller. Only removing the lithium coin cell on the Dallas Chip resets them (doing so resets the log; it will be re-initialized when next used.) Expected battery life with the coin cell I'm using is upwards of 2 years in standby.

There will be a menu option (selectable on the surface only) which will dump the contents of the "dive log", should anyone want it. It will be emitted as ASCII records to the programming port, and easily capturable with any standard serial terminal program.

The unit also shuts off if its out of water for more than 30 minutes, going to "sleep", so when removed from the water it SHOULD turn itself off long before the incident's log can be overwritten even if the batter is not removed. During "sleep" no log entries are written.

If I reimplement the board on higher-density components (e.g. SMT .vs. through-hole) I will likely add a much larger EEPROM to the board, enabling the keeping of much more dive log data. That will permit me to store things like the temperature stick status (which may not make it in to the first cut of the controller due to space issues on the head board.)

Genesis

CPU board, built and running burn-in.....

The DB-9 connector gives a pretty good indication of "actual size".... the coin cell for RTC battery backup (the DS1307) is on the back of the board.

(BTW, this same board also supports the ZX-24 with one hard jumper change for the power inlet which you can see just under the DB9 marked as "Vsel". That chip is something else - it is truly multitasking, is an order of magnitude or better faster than the Parallax stuff, has floating point on chip, has more program memory and is vastly more efficient, has interrupts, etc. Oh, and that chip is cheaper too. The downside is that the ZX-24 uses a bit more power than the Parallax stuff and it does not have nearly as nice an onboard regulator, so you can't use a split supply scheme where the processor can power down the peripherals when it goes to sleep. As the board is set up right now it will run either the Parallax or the ZX chips, but does not have the powerdown capability for the 5V rail to the peripherals enabled. If you move the wire jumper then it does, but it will only work with the Parallax chips unless your unregulated battery supply voltage is over 7V.)

Attached Images

DSC02015.JPG (155.0 KB, 339 views)

Stephane

Genesis,

Will you consider giving your project to the community? With a FSF like license (copyleft)?

Genesis

The 2Pe software and board design, quite possibly yes.

The ZX software, if I decide to code for that, or something else, probably not.

The major limitation with the Parallax stuff is that when you're on a menu the solenoid does not fire since the system is not multi-tasking. There are all kinds of hoochey ways around this with their chipset, but I'm not comfortable with them - a missed "end of injection" event would lock the solenoid OPEN - very, very bad!

Seriously, the code didn't take long to write. About a man-week's worth of effort, all-up, for the software itself. Getting the hardware right took some time too, but not terribly long either.

There are some limitations in the existing software and hardware design. None of them are fatal, but all of them require attention. These are things that anyone who intends to actually use this thing for what I intend to use it for would have to address and solve.

The mechanicals are going to be a bit of fun, and I may also be willing to sell handset boxes and maybe even scrubber head/tail pieces. For example, I've found that hall effect switches, even when you use fairly expensive (read: powerful) magnets, still need to be quite close to the magnet before they "trigger." I'm working the issue of whether I want to do reed switches or hall effect for the buttons - hall has the benefit of being "no moving parts" but getting it to work at the requisite distance through the casing is proving a bit of a challenge. That and some integration and testing work and you know what you have.....

The "hard parts" appear to be:

1. Controller/monitor. Lots of people simply can't do the electronics. I don't find them difficult at all.
2. Scrubber "lid". Mechanically complicated and while it can be done on a hand lathe and milling machine, its VERY time consuming. This is a place where CAM brings down cost BIGTIME if you have any sort of volume.
3. Pieces to fit whatever you're going to use for counterlungs. The counterlungs THEMSELVES are simple and cheap - look at what Gordon did and you'll figure it out right quick.

DSVs are commercially available and so are hoses.

Since I don't own a machine shop I'm looking at this from a perspective of sending pieces out to be made. Its not nearly as bad as some people would have you believe. This leads me to wonder if either (1) those currently manufacturing these things are RADICALLY overstating their costs in a bid to keep competition out, or (2) they're doing things in-house at a cost which radically exceeds that which they'd pay if they farmed them out.

Here's where I am with the head design right now - its NOT DONE or dimensioned in full yet, but this is the basic layout.... The big holes are M16x1 threaded which are the correct size for the sensor(s); I have to work on keying and mounting for the head components yet..... as I said - this is just a "pull" from the CAD software "as it sits" in the assembly right now..... The outlet for gas back to the loop (towards the diver's lungs) will come off the side; the intent is for an axial-flow cannister transversely mounted behind the head, ala the O2ptima. Originally the cannister is intended to accept the Micropore cartridges, but there is no particular reason you couldn't build one to take rocks.

My intent with this project is to prove that:

1. I can build one of these.
2. It can be done as a "one off" for equal or less money than you can buy a competitive model with the same basic capabilities.
3. I will not kill myself doing so, despite many people's claims to the contrary.

What I intend to do once goals 1-3 are achieved is not yet decided. I don't believe there's much uncertainty left in any of these three items, by the way.... I've seen nothing thus far that suggests that I'm going to run up against a brick wall somewhere.

If I can find a way to make a political point that "rocks the industry" as well once I've managed the above, however, its a good bet I'll do it.

Attached Images

Head.jpg (22.3 KB, 275 views)