Controller pics..... :)

Genesis

Here's the head board (with the cable between it and the controller board)

Built up and working. I'm not yet able to run the full controller code suite on the controller card, as my capacitors that I'm missing aren't here yet, so the clock won't start - and without that the code refuses to run.

Some diagnostic software that I have though DOES run, and is seeing all the inputs, so that's good - electrically the board looks fantastic. Haven't had to do anything other than solder up the parts - I'm (pleasantly) surprised...

The other surprise is that it doesn't appear that I need the main bypass caps on the +5V rail - the individual bypass caps on the chips and inputs appear to be sufficient for stability. I had originally planned on a couple of tantalums (the pads are there for them) on the head, but the PC version of this is running MUCH quieter electrically than the breadboard was.... its VERY stable from what I can see thus far - although I'm not yet done testing everything on the card.

Controller board is on the left (with the ZX chip in it - not the Parallax part), the head board is on the right. The three leftmost 2-pin connectors are for O2 sensors, the cable in the center goes to the head, the next 6-pin connector is for the depth sensor and the right right connector (2 pin) drives the solenoid. The head board will ultimately get potted to reduce the risk of "smoke events" in the breathing loop.

The two pads at the center bottom of the card are for the wires to go to the "wet contact" sensors (just two bolts through the head to the water.)

BTW the "gotcha" with the ZX chip is that the controller and head boards draw 40ma - that's a lot more than the Parallax board requires (the head board itself - aka the pair without the processor inserted - draws roughly 9ma, including regulator losses off the controller card.) That's considerably more than the Parallax chip draws - the price of speed and increased capability is current drain!

More testing results soon.... and maybe some schematic, board files (for the folks over at ExpressPCB - means you can order up three of each for $59!), a bill of materials for each and the Parallax code..... I'm seriously considering Copylefting ALL of it (with the intent of the GNU "Virus" attaching to any use of it, of course )

Genesis

Ok, here's the latest status...

Both the CPU and head boards are working. The clock issue turned out to be some VERY twitchy crystals from Citizen; its working fine now without any additional external capacitance. I'm going to get some different supplier crystals and play with a few to find some that aren't quite as twitchy, and then make a slight modification to the board to accommodate whichever one is most stable..

The head board is on the left, CPU on the right. The DB-9 cable is for programming, diagnostics and data dump - it is perfectly fine to run with it disconnected of course.

The head board has proven out fine with no changes required thus far.

The only issue my torture testing has revealed thus far is that there's a fair bit of electrical noise picked up on the leads from the sensors if you have a flourescent lamp in close proximity (within a foot or so) which of course is dutifully amplified and causes some bounce in the least-significant-digits of the ADC. Its enough to cause the unit to fail a calibrate due to sensor output bounce during the settling time. This was discovered when I left my soldering worklight (with a magnifier) on during some early testing and couldn't figure out where the bounce was coming from. Attempting to bypass this is likely to be fruitless unless you're willing to deal with substantially longer response times on the sensors - additional bypass on both the inputs and outputs of the op amp does help, but even getting really insane with them doesn't totally eliminate it. A ground-planed board would likely also help - may do that for production boards - but noise coupled in that can't be damped entirely ain't gonna go away....

Some experimentation with hall effect sensors has shown that while they definitely work and are "contactless" their operating range is too short for my taste. Reed switches work at ranges of 1/2" or so, which allows me to mount them inside the case with plenty of "meat" between the bore of the switch cavity and the switch itself. So I've decided that the handsets will use reeds, at least for now. This will allow me to finalize the mechanical for the handsets in the next few working days and get them out for quote. The buttons will be on the sides much like the VR3s are.

The only thing left on a breadboard is the reed switches and interconnect for the handset. Everything else is running on real boards now and has proven to be very stable.

The below image is the CPU and head boards; note the Ancor cable. That's the stuff I was referring to earlier - the coil is the length I anticipate using between the cannister and head (so as to iron out any capacitance or other issues); the O2 sensor wires are also using Ancor marine cable as well.

I'm out-of-pocket for the next week or so on this due to my boat coming out to have bottom work done which means there probably won't be much in the way of updates during that time.

The only other significant development in the last few days is that the ZX processor works great with the hardware - that's the ATMEL chip with radically higher speed, floating point, multitasking, etc. I've got all the I/O routines done on that processor to talk to the hardware, and will start porting the base code from the 2Pe while I wait for the enclosures. I intend to give both an honest shot in real use and figure out which I prefer "in real life" - the only "downside" the ZX has is significantly shorter battery life since as I noted before its on-chip regulator doesn't permit using the power management circuitry on the processor card effectively. I think I can live with it (runtime "idle" is about 40 hours on one set of batteries), but I'm not sure yet......


Anyway, enjoy - and feel free to ask anything that comes to mind!

dive2dive2000

How do you plan to correct the noise generated from the florescent lighting? Diving with an HID will most likely cause the same problem.

__________________
Safe Diving,
Martin

Genesis

It doesn't. HIDs have a high enough frequency for their radiated energy that the bypass caps are extremely effective in presenting what looks like a dead short to that interference. Even with the ballast of a burning 21W HID directly laying on the cables to the sensors I get no jitter in the least-significant digit on one of the cells. The flourescent lamp produces a several-count jitter in the ADC outputs. This would likely not show up with 8-bit DACs but is really obvious with the 12-bit one I'm using - and its more than enough to fail the sensors on a calibrate as the values coming back fail the requisite stability check.

Each input channel is bypassed with a 0.1uf capacitor now, which presents what looks like a dead short to high-frequency energy. In addition the chips themselves on the board are also bypassed, as is the card's power inlet; the CPU board has a fairly large filter cap on it as well (required by the regulator to insure it remains stable.)

The exisiting bypass, however, is insufficient to short out 60hz and some of the lower harmonics which are produced in spades by the cheap flourescent desk lamp that I have.

"Correcting" the flourescent jitter would require shielding the cable from the sensors to the head card and using fairly large-value capacitors (e.g. electrolytics or larger tantalums) because the problem is not coming from the card itself, but rather is being conducted in by the leads from the sensors and, I suspect, from the boards in the sensors themselves! Thus shielding the cable alone won't do it - you have to short out the interference because you can't do anything to stop it getting coupled in from the sensor boards. I may order 4-layer (ground and power planed) boards when I actually go to get production quantities (e.g. if I ever decide to order these things in 100s), but I suspect that won't do anything in terms of this issue - at least what I see from my testing indicates it won't.

I suspect that every Rebreather on the market that uses a galvanic cell for O2 sense is succeptable to this sort of jitter problem, as I'm not aware of any that use shielded cable from the sensors and there's no way to shield the sensor boards themselves. A number of units are doing the instrumentation amplification in the handsets on top of it, which means you've got a looooong wire for an "antenna". Bypass caps for low frequency energy must be of quite-high value to be effective - that spells big and either tantalum or electrolytic - the latter are completely unsuitable in anything that gets pressurized and the both can have some nasty failure modes, especially if reverse-polarity is ever applied to them - not something you want to have happen in a breathing loop.

I don't see this as being a real-world problem but I'm going to keep my eye on it and do some testing with my camera strobes to see if I can induce any sort of misbehavior with them, as their charge-pump circuits tend to run at fairly low frequencies.....

sven

Hi!

This may be a stupid question - please be considerate, as I am an absolute beginner when it comes to electronics ...

Has anyone ever considered some sort of wireless transmission between the controller and the handsets? BlueTooth comes to mind. Would that be something to experiment with, i.e. could it possibly work (power drain, signal underwater, ???)

At the moment, I am working on a HUD for my Inspiration. I am playing with optical fibre rather than electric connections from the controller to the display, in order to avoid any sealing problems with the cables as well as any corrosion. The design is based on http://www.atlimp.com/Repthud1.htm
Once I have all the parts I'll play around with it. One problem I will have to solve is, that I need to split the signal from the O2 sensors to two different circuits/controllers - the original Inspiration one as well as my home made. Does anyone have a schematic for this wort of wiring?

__________________
Regards,
Sven

The Sydney Project website: http://www.sydneyproject.com
My Blog: http://sven.rebreatherworld.com

"Whenever you find yourself on the side of the majority, it's time to pause and reflect." Mark Twain

Genesis

The problem with wireless is that you need to use a very low frequency signal for it to penetrate well underwater, and you also then need power in each part of the device. Bluetooth is a high-frequency (2.4ghz) signal and will travel only millimeters underwater.

Fiber is also a possibility - its not hard to use a fiber channel, and it has some advantages as you noted - but since you cannot pass power down it, you still need power in each location OR you have to use the fiber only as a "light pipe". The latter could be attractive for a HUD.....

O2 sensors typically must run into a 10K ohm load resistor, which is on the device that they connect to. If you wish to "split" them off to something else (e.g. a hud) one strategy is to use an op-amp (they have a very high input resistance) for the second channel and either use unity gain (use it as a buffer) or whatever is appropriate to what you're doing with the second channel. This leaves the original signal undisturbed to wherever it normally goes.

So, if you're using a similar circuit to the one in that article, then just leave the load resistor off - the Inspiration already provides one. Where do you intend to put the circuitry?

One thing to be aware of - electronics have magic smoke inside them They stop working if you let that out, but the more serious issue with a breathing loop is that if they let it out into the loop you'll inhale it, and you won't like that. In a circumstance where the FO2 at the time is elevated (e.g. on shallow deco) you might REALLY not like what happens. If you're new to electronics pay close attention to this risk......

divetheworld

For the CE standard, an RF signal would have to be induced into the conductors with a field strength of 10v/M. Sweep that sine from 1hz to 230kHz and if you have no changes then it would pass. You might even find some advantage with injecting some transients too. If you want to simulate such testing (without the £20K rig we use) then give me a mail and i will detail you a cheap and inaccurate alternative.

Brent.

__________________

Genesis

That's rather imprecise.....

The reason I say that is that an impressed signal across the "conductors" leaves quite a bit out..... if you can run with just the wiring (e.g. no sensors) then the sensor's contribution to the problem is of course ignored, etc.....

I'd have to see the actual specification - I'm not able to reproduce this glitch with any of the other sources of "noise" that I have available, but it is readily reproduceable with this one individual flourescent desk lamp. What I've been able to trace thus far suggests that the noise is coming into the system through something in the sensor's temperature compensation board that has a resonant frequency near or at one of the harmonics being emitted.

I need to spend more time with my 'scope isolating this, obviously, but if its coming down the leads from the sensors and proves out to be a low enough frequency then there is likely NO unit that uses the Teledyne R22D that's immune to this. If you're only displaying two digits beyond the decimal on PO2 you may or may not see it depending on how many bits of actual internal resolution the system is using. For the millivolt display (raw) though you should be able to see it if you display tenths.....

That lamp also makes an AM radio in the vicinity go batshit across the entire band..... (that's not surprising!)

I'm still investigating this..... it definitely surprised me given the immunity that I've seen thus far to misbehavior due to potential coupled-in noise sources.

aknelson

The amplifier and analog inputs must be protected with 10nf or 100nf to ground this gives a good signal path for RF transients.RC combinations in the signal path are useful RF protections too.
At least this is how it is done in EMV compatible commercial circuitry.

Andy

Genesis

The capacitance you use depends on the frequency of interest. Larger capacitors reduce desireable transient response but appear as a short to lower frequencies.

All the op-amp inputs currently are bypassed with 0.1uf caps to the ground, as are all power leads to the ICs on the board. The "undriven" ADC inputs (that is, those which are not prescaled by an op-amp to a volt-level signal - both the positive reference and the voltage divider for V+ sense) are also bypassed to prevent coupling of noise into those pins.

Bypassing the driven inputs has proven to be of no material effect as the potential coupling path is extremely short. The driven ADC inputs are, however, pulled down to ground to insure that an open-circuit condition does not result in a floating input with undesireable characteristics (e.g. oscillation back through the op-amp), as the ADC itself has a very high input impedance.