The purpose of technical documentation is to precisely convey information to other people who possess the technical skills needed to apply it.  It is not to pass along technical skills, although reading technical documentation on a system designed by someone more experienced often will.  It is not to explain a system to management to enable their decision-making processes, that need is properly met by the inclusion of executive summaries and project plans in software specifications alongside the technical design.  And it is decidedly not to make the spelling and grammar check in your word processor happy.

Of course, documentation must include explanations in a human language such as English, and as such, broken rules of English grammar and style are distracting and doing so gratuitously should be avoided.  But the potential for conflict with accuracy should not be ignored.  In order to be clear when documenting code, it is necessary to follow the rules established by the programming language for identifying particular components.  Only where the programming language makes no restriction (such as in comments, or the English prose surrounding references to the software system) should literary rules reign.

Joseph Newcomer has a great anecdote of a programmer who tried to write C++ code using English grammar.  But documentation can become complicit in such foolishness if it disregards the rules of the language, as does the Apple Developer Documentation.  Here is an excerpt taken from Apple's man page for select on 1 August 2009:

First, the prototype, which has been correctly preserved:

int select(int nfds, fd_set *restrict readfds, fd_set *restrict writefds, fd_set *restrict errorfds, struct timeval *restrict timeout);

Next, the explanatory content, in which accuracy has been sacrificed on the altar of English grammar:

DESCRIPTION Select() examines the I/O descriptor sets...

RETURN VALUES Select() returns the number of ready descriptors...

BUGS Select() should probably have been designed to...

I'm truly at a loss for why Apple should be describing the Select() function in a document dedicated to select().  No C compiler accepts the altered capitalization, and neither should programmers.  Oh wait, Apple was just following the example of FreeBSD who messed up a decade earlier.  Of course, FreeBSD is free, while Apple is selling their OS and therefore should be held to a higher standard.  For reference, the normative specification of select (and updated version) are case-correct while also managing to obey English capitalization rules.  This is the ideal.

Maybe next, in the interests of using a larger vocabulary to avoid boring repetition, the cat man page can be rewritten using words such as "feline".  head and tail likewise have perfectly good synonyms (in English only, /bin/sh isn't accepting substitutes).  Just don't ask me to build products on a foundation that plays such tricks with documentation.

Strictly speaking, the EPCS main function of toggling valves at set intervals doesn't require any user input, and it's likely to be quite some time before an algorithm is embedded to provide real-time results, so a display is also not necessary, but a device without a user interface is an inflexible one. The development and debugging process will also be greatly eased by an integrated display.

I did some looking around on Digi-Key for a small inexpensive LCD panel, but what impressed me most about all of them is that the documentation was utter garbage. Then I stumbled across an entire front panel on fire sale. Ok, it isn't perfect, I could have wished for 20 characters across and a backlight, more pushbuttons, or a green LED, but it's more than adequate and the price was ideal. The seller's comment "I can't begin to make such an item for this price." is, if anything, an understatement.

Experience has taught me that electronics tend to fail during development (most circuits deal in at least a few votlages that are higher-than-absolute-maximum-rating for something else and with loose wires, incorrect cable pinouts, or short circuits induced by multimeter probes... use a little imagination) and I've learned the value of immediately-available spares, so I've been accumulating enough of each component to build two units  Actually I would much have preferred two complete units plus a spare of each component, but with free samples (often necessary to get around minimum quantity requirements) you take what you can get, which is usually two. For the front panel I ordered yet two extra for a total of four; this price point doesn't cause me much pain and I'm sure I'll find a home for them before too long).

Anyway, the supporting circuitry for this front panel module turns out to be really minimal, but that wasn't immediately evident. Here are the issues I considered, addressed in order of fewest dependencies:

• LEDs: The front panel has them wired in a common cathode configuration which is not my preference and the discussion is too long to fit here comfortable.
• Momentary Pushbuttons: The front panel has four, with one contact of each grounded and the other floating, the perfect configuration for small numbers of buttons. Add a pull-up resistor and the floating contact becomes a nice logic-level signal, ready to feed logic. The ADuC7025 GPIO pins have internal 100k pull-up resistors so we could wire up the buttons directly and be done with it. I've chosen instead to use the MAX6818 de-bouncer IC, not so much for the de-bouncing which can be provided easily in software, but for the 15kV ESD protection and overvoltage protection, which can't. The Change-of-State output is nice for generating an interrupt, even if the active state is wrong for direct use as an ADuC7025 external interrupt request line. I see two ways to overcome this: one of the unused channels of the hex inverter used for LED current sourcing, or the method I've chosen, the interrupt-generation capability of the ADuC7025's integrated Programmable Logic Array. This is the more complex route, but enables tricks like automatic inhibition of the button-press interrupt while the shared data bus is in use talking to another peripheral. For this reason any output-enable signals will be placed on PLA input pins.
• Character LCD: This has been just a tad frustrating. The front panel uses an original Hitachi HD44780 requiring a 5V supply, but the internet seems to only have the datasheet for the newer HD44780U which supports 3.3V supply as well. That's ok for getting data back to the ADuC7025, which has 5V-tolerant GPIOs, but raises a question about whether the 2.4V high output voltage of the ADuC7025 (probably nearer 3V when run with a 3.3V supply, still less than 0.7V_CC) will be considered logic high or an intermediate unstable high-current level. Anything above 2.2V is clearly ok for the HD44780U when run from a 5V supply, but what about the older model? Luckily someone posted the relevant parts of the datasheet and its threshold is also 2.2V. This means there is no need to increase the voltage with either common-drain configured GPIO and power-wasting pull-up resistors, or a bidirectional level translator such as the CD74ACT623 or SN74LVC4245A (another translator would have been needed for the control signals).
• Shared data bus: We save pins by using the same data bus for the pushbuttons and LCD, but a compatibility check is in order. The bus has three devices, the ADuC7025, MAX6818, and HD44780. Do all have tri-state outputs? Yes. Are all tolerant of 5V signals from the HD44780? ADuC7025: Yes. It's tempting to ignore the MAX6818 because it will be tri-stated, but this would be a mistake because the absolute maximum ratings would have been exceeded unless a 5V supply is chosen. The pushbuttons are fine at 5V, and 2.4V on the EN pin is still sufficient to be considered high. Alles ist in Ordnung.

Phew.

Or sink. Whatever. No matter which word you use, there's a need for the logic to source a current of 25mA (or reasonably close).

I definitely prefer LED banks with anodes tied to the positive power rail. NPN and NFET transistors are more efficient per unit area than their PNP or PFET counterparts, so interfacing LEDs usually can be done using microcontroller GPIO pins to sink the current (but be sure to check the rated sink current, the ADuC7025 makes no promises of more than 1.6mA), and a series resistor to make up the voltage difference. Open-drain logic outputs preferred but not necessary, the LED becomes high impedance as the cathode voltage goes high. Even when the microcontroller can't sink enough current, NFET or NPN transistors are available in quad-packs (or more) with high current gain.

With common cathode, this is not so easy. Furthermore, the common cathode is already hard-wired to ground, but that's the most reasonable thing to do with common cathode anyway. Since we need external components, my preference would be to go for a current-controlling LED driver. If we were using LEDs with the usual common anode/switched cathode arrangement, there'd be lots of options including programmable dimmers and so forth. But all hope is not lost, Exar makes "high-side" LED drivers with a controlled output current (PWM for dimming) with either two or three channels on a single chip. Problem: one shared enable for all channels. Huh, how's that multi-channel then? Well, these chips are designed to match current (and hence intensity) between multiple LEDs. There's no options for separate control or even single-channels, and if you only connect one LED the logic promises to be so kind as to detect a fault and turn off your good channel. There used to be a quad driver chip made by TI and National Semiconductor designed as the high side of a matrix scan system, the SN75491, that would have been perfect for this, but it is no longer sold. Abandon hope all ye who enter here.

So we're left with using transistors for voltage control, combined with series resistors to intersect the 3V @ 25mA spec of the LEDs. Since there don't seem to be any triple- or quad-pack PNP (or PFET) transistors, one option would be discrete transistors like the 2SB1694 or FDN338P. PFET is better, because the low current gain of PNP causes a respectable load remaining on the microcontroller. But I'm a proponent of low part count anyway, so a multi-channel inverter will be an even better option as long as it has appropriate supply voltage and current source capability. Several alternatives are TI's SN74LVC3G04 and ON Semi's MC74AC04. Neither option recognizes 3.3V as logic high, and the hex inverter has lower input and supply current requirements, so I'll use it. The restrictive lower limit on logic high won't be a problem, since the ADuC7025 is 5V-tolerant and bidirectional GPIOs can always simulate open-drain outputs by setting the data directionality bits while keeping the logic level low. A pull-up resistor to 5V completes the circuit.

As previously mentioned, the EPCS will take advantage of the FTDI FT2232H USB-serial converter and its integrated multi-protocol synchronous serial engine (MPSSE) support for JTAG for programming and debugging the ADuC7025 firmware. The second serial port provided by the FT2232H will be used in UART mode to provide a link for streaming data back to a PC. I envision two uses of this UART:

1. The UART communicates via a RS-232 level converter and standard DB-9 connector to act as a generic USB-serial adapter attaching any RS-232 device to the PC. Simultaneously, the ADuC7025 snoops the streaming traffic, transparent to both endpoints. This enables aggregating the serial data with local ADC measurements using a single time source, streamlining later time alignment of different sensors.
2. The UART may alternatively be used for bidirectional communication between the ADuC7025 and PC at high speed.

Since the FT2232H has two ports, creative use of tri-state buffers could allow both these modes of operation simultaneously when not debugging, but I do not feel this would be worth the added complexity. Instead we will focus on preventing leakage currents from flowing through the ground connection established by the USB cable.

To prevent leakage currents it is desirable to keep the EPCS main circuitry isolated from ordinary electronics (anything connected to the power grid without a medical grade power supply). The UART is straightforward to isolate -- it has only two unidirectional data lines and moderate baud rate. I simply interposed an ADUM2201 "IEC60601-1 compliant digital isolator" and voilà, problem solved.

JTAG presents a little more severe problem for isolation, as there are both more pins and higher frequency signals, so that inclusion of a digital isolator would have a significant detrimental impact on the debugging experience. At the same time, firmware loading and debugging is not part of the intended use of the finished product; it is quite acceptable to debug using test data or during animal experiments and remove the JTAG capability before use with human patients. Therefore all that is needed it to provide a way to disconnect JTAG while retaining the UART link which is useful when deployed, and a removable resistor array à la SCSI terminator resistors solves the problem neatly.

Or does it? One lurking issue here is that with two power sources, and the almost certainty of cycling power to the EPCS while connected to its debugger, these JTAG signals could be energized while their receiver is not. Such a situation threatens latch-up, as parasitic P-N junctions in the receiver IC provide a path to ground with very low incremental resistance and a low turn-on voltage on the order of 0.7V. The 3.3V which the FT2232H would drive onto the JTAG bus would be plenty high to induce latch-up in many chips. Using a resistor array with non-zero values, such as the 47-ohm SIP selected, helps mitigate the problem by limiting the maximum current. Ordinarily protection diodes would be added to the circuit as well to assure that any current passes through a safer route than the parasitic P-N junctions, but the ADuC702x datasheet indicates that these microcontrollers tolerate up to +5.3V on input pins irrespective of supplied power, and likewise with the FT2232H, so it seems this is a non-issue. (Note how other pins on both chips are rated with respect to V_CC or V_DD, but the digital inputs are not restricted.)

Here then is the completed circuit:

Admittedly a higher part count than just plunking down a 20-pin ARM-standard JTAG connector as shown in the ADUM702x datasheet example application circuit, but much more capable. In addition USB 2.0 high-speed capability used to make quite a statement, but now USB super-speed is preparing for debut and promises to quickly become the logo du jour.

Having a microcontroller in an embedded project doesn't do much good until you are able to program it, because in contrast to fixed-function ICs or configurable ICs with reasonable defaults, microcontrollers have little to no useful behavior from the factory. Some families of microcontroller, like the Z-World Rabbit or Microchip PIC, have unique programming circuits so your choice of programmer is essentially made for you -- you buy the adapter available from the IC vendor for several hundred dollars. Most ARM cores use the industry-standard JTAG serial port for programming, debugging, and (for other devices such as FPGAs) boundary scan test. That means a lot more options more adapters, but not necessarily much money saved. For example, For example, you can easily spend over $1000 on the Segger J-Link (pricelist in Euros) which is recommended by IAR who make the Embedded Workbench compiler/development environment. There's a free limited version of the software and the J-Link is available for non-commercial use at a more palatable price, but still quite expensive and development of a product is forbidden, so apparently the lower price isn't intended for open-source designers. Anyway, since I am developing a proprietary product, that isn't for me.

However, further digging around on the Internet produced first hope and then a budget-friendly solution. There's an open-source programming environment for JTAG named Open On-Chip Debugger, and some of the participants have put together designs for JTAG adapters along with lists of reasonably-priced commercial adapters. The DIY designs are mainly based on FTDI's USB/serial adapter ICs, which I've run into on previous projects and, interestingly enough, fought to eradicate from those designs. The reason was that the Windows drivers were buggy and caused occasional blue screens of death (ok, in some versions, which even passed WHQL certification, the BSOD came fast and frequent) which was totally unacceptable for the intended use. For programming, reliability isn't as important as the convenience, and while it's hard to prove absence of bugs, the latest drivers are improved and definitely not a hindrance, so I come to an opposite conclusion regarding using FTDI chips for JTAG.

I still probably would have chosen to go with one of the less expensive commercial models rather than FTDI though, because designing a board (with noise-sensitive USB traces!) isn't cost-effective by comparison, nor is placing a $6 chip on every board just to enable programming, but distributors sell not only the bare ICs but also ready-built modules which contain the USB connector, FTDI chip, EEPROM, crystal, all routed and assembled, for only $27 (Mouser gets the link because Digikey has none in stock at the time of this post). Including the connector for the mini-module is just as easy as the 2x10 connector used by the commercial adapters, the module can be moved around and reused between boards, this is the high-speed version, and to top it all off the second half of the FT2232H can be used as a UART to stream data to a PC in real-time. There's still a slight question about what magic incantation to program into the EEPROM so that the software recognizes it as a JTAG device, but I'm confident that can be overcome even if I have to read the OpenOCD source code.

I've now posted the schematic.

While writing the post on selection of the microcontroller, I got a little deeper into the capabilities of the integrated ADC peripheral. Initially I had just been relying on past experience with Analog Devices ICs for assurance that if the basic specs were sufficient then my needs would be met. But now I've discovered that the ADuC7025 ADC provides adjustable scaling and common-mode rejection, which are two functions currently delegated to the AD8227 instrumentation amps. Yet I have a number of reasons for keeping the front-end amplifiers:

• First, removing it wouldn't save much. The IC is inexpensive, and the part count for supporting circuitry is only a couple components more than would be needed anyway, since the charge-sampling design of the ADC requires external capacitance.
• The instrumentation amplifier presents a lower output impedance to the analog input pins, and its 400MΩ inputs also load the transducer less.
• The output of the AD8227 is single-ended and can thus be made available as an analog output for recording with any other data collection apparatus. It may or may not be have a strong enough driver to use directly, but I'd add an additional buffer amp to stop the effects of the external load from propagating back to the internally measured signal. For example, when the external equipment is turned off, its protection diodes will shunt incoming signals to ground clipping at about 0.7V. However even with a buffer there could still be ground leakage currents, so ideally any analog output would be produced using a discrete DAC updated via an isolated serial signal.
• Fewer pins of the ADuC7025 are needed, leaving more ADC channels available for other purposes (or use of the pins as GPIO).
• Providing gain by setting V_REF affects all channels equally, whereas with a separate amplifier a gain can be set individually for channels connected to pressure transducers, force transducers, current-sense resistors, or external analog signals, etc .
• The AD8227 input pins are very well protected against overvoltage and ESD. This won't help if somehow the input contacts experience the shock of defibrillation, but that wouldn't happen unless badly miswired (to a degree comparable to sticking a screwdriver into a wall socket).
• In case the maximum input voltage is exceeded, replacement of an IC with SOIC-8 footprint is far easier than the 64 lead quad flat pack of the ADuC7025.

So the instrumentation amplifiers stay.

A while back one of the embedded design newsletters I receive mentioned a kind of "super-ADC", barely more expensive than the usual ADC and about the same size but with a microcontroller embedded (for example, the ST7FOX, S08QD, AVR ATtiny25, and P89LPC90x are all 8 pins, while the AVR ATtiny10 has 4 ADC channels in only 6 pins), allowing for programmable digital filters right on the front end. Think 50/60Hz notch filters to take out noise caused by fluorescent lights (the power grid in Europe and much of the non-US world is 50 Hz, the US is 60, so many devices offer the user a choice). Of course that kind of filter doesn't need to be done on the front end, but many filters do, such as software radio and CDMA, because they require a sampling rate too high to push through an isolator. Doing the digital signal processing in the ADC then decimating before transmitting as a low-rate easily isolated serial stream solves the problem neatly.

Now, the newsletter, which I can no longer find, wasn't highlighting that small cheap microcontrollers have ADC, that's been true for a long time. Rather it was focusing on the availability of integrated ADCs with the same performance as dedicated ADC chips. So when I started the initial design work for the EPCS, I decided to go looking for a super-ADC to control it. For some reason Analog Devices and ARM stuck in my mind, so I went looking there. The ADuC series turns out not to be quite as small or low power as the article had spoken of, but they do have ADC performance as good as a dedicated IC. Also, as I further considered the project I decided I wanted to interface with more devices anyway, so the slightly larger size wasn't a disadvantage. Furthermore, the ARM7TDMI core is very power efficient for what it offers, the same core is used for cell phones and PDAs that run for days on a charge. In the past project I've been involved with have often used Analog Devices' analog-to-digital conversion chips with great success, so I expect similar good results ADC-wise from the ADuC. I wanted good ADC resolution, low cost, and a respectable number of I/O pins for LEDs and buttons, and those requirements intersected in the ADuC7025.

This processor has a lot of cool features and also presents a few challenges:

• Power – Expect an upcoming post with gory details on getting suitable power and ground connections to the microcontroller.
• JTAG – Supports programming the onboard code memory, but that's not all. We won't need an ICE (In-Circuit Emulator) or be reduced to printf debugging (or more usual for embedded systems, GPIO-attached LED debugging), because JTAG promises live debugging. Hooking up to a JTAG adapter, and then setting up the development environment will be topics for future posts.
• UART – Just one UART is included, but RX and TX are multiplexed to two sets of pins. I'll give more details on why that's good in a future post.
• GPIOs – Allows interacting with the real world in a myriad of ways. To start with, rather than just being a brick with tubes coming out, the EPCS will let its user know what's going on with LEDs and a character LCD panel. We'll even allow the care provider the illusion of control by accepting simple commands activated via push buttons. This will be described in -- you guessed it -- a future post.
• GPIOs redux – The purpose of the EPCS isn't pretty blinking lights and push buttons though, we want to actually control pneumatic flow. GPIOs provide the timing to the valve control circuit described here. (Wonder of wonders, already written)
• ADCs – Actuators are great, but adding sensors opens up a whole new world of feedback control. We'll start out with pressure transducers to monitor the fluid lines we're controlling. Since the ADuC7025 supports fully differential inputs with an external voltage reference, we could use it as the front-end, but there are advantages to using an instrumentation amplifier as described here. For insight into system health we have an integrated temperature monitor, and maybe battery voltage and solenoid currents. That leaves a number of ADC channels left over which can be used to capture analog data from other monitors.
• SPI – A future post will describe why and how I add a microSD card to the EPCS.

Well there's plenty more work to do, but this post is long enough. On to more specific points of design.

Since the whole purpose of the EPCS is to mitigate the need for a human to turn two stopcocks twice per minute, we need to replace the stopcocks with electric control and that means an solenoid pneumatic valve. The arrangement of the stopcocks was such that one port needed to communicate with either of two pressure reservoirs, thus a single 3-way valve is sufficient. I started googling for suitable valves and found lots of options in the $100 price range -- $100 to replace a 50¢ piece of plastic. This wouldn't have exceeded the budgetary constraints of the project, quite, but I knew that entire non-invasive blood pressure cuff systems (the kind for occasional personal use) sell for about $40 and during development work I'd rather have a spare than a really sturdy valve costing twice as much, so I kept looking and eventually found two models for about $16, call it $20 each once you factor in shipping. The catch is that the documentation available on the seller's website is sorely lacking.  I took one approach to solving that -- order the valves early enough to receive them in time for some simple testing before finalizing the design. Apparently if I had tried a little harder I would have found somewhat better documentation at the manufacturer's site, but although this lets me confirm the required wattage I'm still uncertain about the actual electrical connections, I figure there will either be a separate drive coil for each of the two energized positions, or else a single pair of contacts which receives either +12V or -12V to reach either position.

(At this point I find the real explanation, which isn't linked from the seller or even the manufacturer's product page, and finally understand. I should have asked my ME and ChE sisters, who with a combined total of 13 years in engineering school, certainly already knew these little details.)

Aarrgh! Yes, I'm an electrical engineer, and I clearly didn't know what 3-way normally closed (NC) valves were when I ordered them. Look, 2-way valves are easy, there are two ports and two positions, open and closed. If the valve is normally closed, then it's closed when not powered, and open when energized. And if normally open (NO), it's closed when energized and open when not. So far so good. But apparently things get complicated when you get to 3-way valves. There are three ports comprising one "inlet" capable of connecting to either of two "outlets", and presumably permitting flow in either direction despite the naming. That's what I expected. I ordered a normally closed valve, because I thought that like the 2-way NC valve, there would be no flow unless energized. But no, although there are NO and NC variants for 3-way valves, there are still only two positions and both variants have exactly the same behavior, one outlet is open when energized and closed at rest, while the other outlet is closed when energized and open at rest. The only difference between the NO and NC valves is which of the two outlets is in the body and which is, well, elsewhere.

Well, the good news is that having only two positions, the valve is driven completely using a single solenoid coil either energized to +12V or off, no -12V required and no complicated (and power-hungry) voltage inverter. The other good news is that this valve will work. The bad news is that I have to keep the solenoid energized with about 5W for as long as I need pressure equal to the second reservoir, because as soon as the power stops the "normally open" reservoir becomes connected again. Oh, and yet one more piece of good news is that these valves, listed as "pneumatic" by the reseller, actually work with liquids as well, which is good because many of the lab's experiments involve starting and stopping IV fluids, and flexibility is good. On the other hand, 0.9% saline might not qualify as "inert".

If I want to be able to pressurize the system and then hold the pressure by stopping all flow (both fluid and power), which would be a significant savings in power and thus improvement in battery life, I can use a pair of normally closed two-way valves or the equivalent 3-position 4-way valve which is what I had been expecting to have gotten to begin with. Both would use two solenoid coils at 0 or +12V, still no need for inversion.

Anyway, these valves require 12V high current "digital" control. Digital only in the sense that the signal should be either on or off, no proportional control (they make fancier valves for that), but "discrete" would probably be a better word since they are definitely not compatible with digital logic which outputs 3.3V at up to typically 25mA. I found a boost regulator which sources up to 18V (adjustable) output, plenty of current, and has a 3.3V-compatible digital enable input. In addition the efficiency is nearly 90% and quiescent current is very low at 75μA so this won't be hurting battery life. I'd feel better if the input voltage range extended a little beyond 6V, but the maximum ratings indicate it's safe up to 7V and it should be rare for a battery to be over its rated voltage. TI provides a very nice example circuit as well as detailed information on selecting the external components. I'll use as many of the example values as possible and just adjust the output voltage to 12V, while using the more efficient lower frequency option.

Here is the circuit for up to two valves:

Wow, that's a lot of components for something so simple.  I can't imagine how bad it would be without an IC doing the boost conversion, probably I would just use a 12V battery. I should ask my sisters that inertness question before I forget.

Power budget: 1mW continuous + 4.5W on 10% duty cycle. The duty cycle drops to 2% if I substitute the 2-way valves.

We now interrupt our regularly scheduled engineering to bring you an example of how NOT to lower expectations:

But they must not have thought they were winning the brag-on-your-product competition, because the reverse side of the box steps up to bat AGAIN:

I'm going to finish this post with my old keyboard just in case the new one refuses to process the word "HUMILITY".

Blood pressure is one of the better known vital signs, measured by just about everyone, often with a non-invasive blood pressure cuff. But the cuff is inaccurate, yields only one measurement per cycle (approximately 60 seconds) and causes tissue damage if inflated too often, so for critically ill patients and in animal experiments blood pressure is recorded continually using an invasive arterial line. This is simply a catheter placed into an accessible artery, such as the radial artery, and connected via rigid plastic tubing (filled with sterile water) to a pressure transducer. These pressure transducers are very nice and small, laser-trimmed for superb accuracy, compatible with most fluids, and inexpensive enough for disposal. When used in our EPCS the transducer will be reusable as it won't come into contact with bodily fluids as it would when monitoring blood pressure, but the size, accuracy, power, and range are all ideal for pneumatic pressure monitoring. In additional every potential user of the EPCS stocks these transducers in bulk.

Of course, it would be too easy if we could wire these sensors directly to our system. In the interests of interoperability with many medical monitors and to minimize the complexity of the disposable components, the transducer requires two wires for excitation and outputs the pressure as a differential analog voltage on a second pair of wires. The gain (proportional to excitation voltage) is standardized at 5 μV/V/mmHg. So with a typical 5V excitation source, a pressure of 100mmHg would be 2.5 mV, differential. Both output lines carry a common-mode offset which is approximately mid-scale. Since our microcontroller has an integrated 2.5V precision bandgap reference, and that falls within acceptable limits on excitation voltage, we'll use that. Actually the reference output doesn't have good fan-out so an op-amp will be used in a unity gain configuration to buffer the voltage. Thus 100mmHg would be only 1.25 mV in our system.

The nice thing about using the same voltage for both transducer excitation and the analog-to-digital converter reference is that the actual voltage for full-scale cancels out. But we still have full-scale = ±200000mmHg. To obtain a 2mmHg precision with a 400000mmHg range like that, our ADC would need to produce over 17.6 bits/sample. On the other hand if we scale by a factor of 400 and shift by +20% of full-scale, then our range becomes (-100, 400) mmHg which is more than ample for the EPCS. Plus, the 12-bit ADC integrated in our microcontroller gives 4096 distinct codewords, or 1 LSB = 500mmHg/4096 or 8 LSB < 500mmHg. A 10-bit ADC would add no additional error to the ±1mmHg/±2% accuracy of the transducer, but 12 bits is pretty standard so we end up with a little bit of headroom.

So how do you scale and shift a low strength signal like this? An instrumentation amplifier is just the ticket. It combines unity-gain op-amps for buffering on each input, so the non-negligible output impedance of the transducer won't skew the feedback, followed by a third op-amp configured as a gain stage. Analog Devices doesn't make any fixed gain instrumentation amps near a factor of 400, so I've chosen a the AD8227, a variable gain (controlled by an external resistor) ultra-low power instrumentation amplifier which is also protected against ESD and overvoltage. Analog Devices is also kind enough to point out (on page 23 of the datasheet) that when this amplifier is used with a charge-sampling ADC, an R-C filter is needed. The example values given by Analog Devices provide a corner frequency of about 16 kHz which is more than is needed in the EPCS, by increasing the resistor by a factor of 100 we cut down the instantaneous current demands.

The AD8227 also handles the shift requirement because the output voltage is referenced to an offset input. Making the correct value could be a little tricky though, because there are no 4:1 ratio standard resistors. I know a way to get around that though: an array of four resistors lets us build a 2R:R/2 divider which is exactly 4:1, and because the resistors are in a single package the manufacturing inaccuracy and thermal effects will tend to be equal. Analog Devices again comes to the rescue with a helpful hint in the datasheet that the offset voltage needs to be buffered, the voltage divider shouldn't be used directly.

So the EPCS pressure signal conditioning circuit will look like this (subject to change, most likely the individual op amps will be combined with others and replaced with a single multi-channel IC):

P.S. I seem to use a lot of Analog Devices chips, anyone care to guess why?

Yesterday I put you all on notice that this embedded pneumatic control system (henceforth EPCS) will be battery-powered, gave an bunch of reasons that are inapplicable to this system, and promised to reveal the true reason today.  I also hinted smugly that the decision involved safety somehow.  Readers of The Hitchhiker's Guide (nope, no commissions here) will suspect that since 42 is the answer to life, the universe, and everything it should be sufficient for this question as well, but in fact batteries have a reason all their own -- leakage current.

Not only is the available energy (and therefore the potential for harm) from a battery strictly limited, but the floating nature of a battery provides additional safety because electrical flow requires a circuit.  For grid-powered devices, earth ground frequently provides a connection between the device and the patient or operator, so any exposed voltage is capable of forming a circuit forcing current through the body.  But with a battery-powered device no return path exists through ground.  And while a pneumatic control system has no need for any electrical contact with the patient, nor would the operator commonly be touching a conductor, more layers of protection are better.  I've still got a lot left to learn about the other electrical safety tests, but at least by using a battery the device doesn't receive classification as either a grounded or double-insulated main-powered device which would incur the leakage tests.

Here are some resources I've identified on the role of leakage current testing in electrical safety:

• A series of white papers sponsored by the IEEE
• A chapter on electrical safety specifically from the operating room perspective
• A list of further electrical safety resources for all kinds of devices, including but not limited to medical

And most certainly I need to look for any information on how to design for safety in an oxygen-rich atmosphere, as happens in the ICU.  And just generally see how many of these hazards we can eliminate by design.  For example, a diode can prevent problems with reverse polarity.  Additional, a patent for an improved circuit which does so with minimal voltage drop has expired and the circuit is therefore freely available for general use.

Ok, this is what I was afraid of.  I'm spending so much time writing about design decisions that no progress is being made.  But documentation of rationale is important too.  C'est la vie.

Hey, the catchy title must have worked because you're reading this post.  It is a little misleading though.  This post is about compromises and safety, but it's the compromises made to achieve safety.  If you ever see any feature of this system that appears it might compromise safety, please let me know!

I feel a need to explain why the last post mentioned a requirement for long battery life.  I mean, of course everyone wants their battery-powered devices to last a long time, but why limit operating time by using a battery in the first place?

After all, the intended operating environment of this device is in pneumatic communication with a surface in contact with a motionless patient.  This patient is wired -- there are something like four physiological monitors co-located with our system, all connected to a redundant power grid.  Why would I choose to use a battery?

Well, a couple of good reasons come to mind, considering what other projects I've worked on:

• Working in the Space Life Sciences Directorate of NASA, I might consider that spacecraft don't use 120VAC power and therefore use a battery to avoid the necessity of interfacing with non-standard power grids.  But on closer inspection this is a really crummy argument for using a battery.  It is actually easier to interface to 28VDC power than AC, and NASA is concerned about things like off gassing (low pressure closed atmosphere) and explosion hazards so that use of batteries is a real obstacle to certification.  Not to mention the problem of getting replacements.
• Sitting in on design of medical systems for military use brings up the transport problem -- far forward infantry can't plug in, and neither is power readily available on most vehicles and aircraft used to move wounded warfighters to a safe location for medical intervention, and non-invasive sensors like this are exactly what is desirable during the grab-and-scoot of casualty evacuation.
• In a similar vein, wilderness types like hikers and mountain climbers face essentially the same transport-with-lack-of-electrical-infrastructure problem.  Also this particular device has potential application with non-injured climbers.
• Even in the hospital, patients are transported from room to room.

Yet the first iteration of the device will never end up in any of these situations so the above points are all moot.  So why did I elect to run battery-powered?

Think about it for a little while, I'll provide my explanation in the next post, tomorrow.

[Hint: If you're stuck, look at the title of this post again]

"Project?  Tell me about this project." you say?  Well I could, but then I'd have to kill you torture you until you signed a secrecy agreement.  No, seriously, this project is part of my PhD research but also an embodiment of an invention and I'm trying not to start the one-year-after-public-disclosure countdown just yet.  It wouldn't be the end of the world, but there's no reason to disclose any proprietary ideas here.  Trust me, there will be plenty left to write about.  [And if you have insider information on this, please refrain from revealing any additional information in your comments.]

Expect this series to be VERY technical.  I'll try not to let it get boring, maybe even add a little humor here and there (although you may be tempted to argue my definition of funny every now and then), but stay pretty focused and be quite prolific and maybe terse at times because I don't want my blog writing to set the timeline.

What's that I hear?  "Get to the project already!"  I did promise to tell you what all of this is about, didn't I?

Succinctly, the invention makes use of periodic step changes in the pressure of a pneumatic system.  Currently that means that the postdocs who work with me in the lab (an awesome couple from Brazil who have been extremely patient with me even though I'm very much their junior yet create a lot of extra work for them) have to turn several stopcocks by hand several time for each measurement.  [I'll briefly introduce the lab and the purpose of the research we do in a future post.]  There are quite a few advantages to automatic pressure control:

• The surgeons' time is a very limited resource which can't be increased because the surgery table is cramped.
• Our lab is blessed with postdocs who are way above average skill and intelligence and enthusiastic about research.  Eventually this method has to undergo broader testing among people who will require convincing just to let a fully automated system be used.
• People just aren't good at doing things on a sub-second schedule.  So there's a significant amount of variation in execution, which translates into additional uncertainty in the results.

For these reasons I intend to unleash the intense unerring attentions of Cylons The Borg an ARM7 microcontroller to relentlessly pursue accurate timing.  So the foreseeable future will see posts discussing how to build an embedded pneumatic control system with data collection capabilities in a small package with long battery life which is easy to use, accurate, and above all safe.  And for good measure, also try to be flexible enough to take care of some of the other highly repetitive timing critical tasks which are performed by hand in and around the lab today.

After much avoidance I've decided to start a blog.  Ok, maybe the fact that one of my mentors told me that applying for a Professional Engineer license requires submitting narratives about project design almost exactly like a blog had something to do with it.  But I'd never admit to something like that, doesn't it sound unlikely to you too?

I've formally been an Engineer-in-Training since passing the FE exam before receiving my BS in EE back in May 2002, but I haven't actually done much toward obtaining a license as a Professional Engineer.  Time for that to change, and right now I have a golden opportunity to start preparing -- a project of moderate scope on which I will be doing the lion's share of the work but undergo review by a PE.  So I asked this PE what steps he would recommend to make sure I can include this work in my portfolio and here we are.  So without further ado, let's introduce the project.