Now that the Texas Instruments MSP430F1232 microcontroller is available, I have started thinking about my altimeter design again.

The altimeter will run off of a single lithium battery which should be good for many flights. The goal is to last a year. Maybe not realistic, but a goal anyway. In order to operate correctly over the entire range of the battery voltage, a charge pump (schematic) is included to boost the battery voltage and provide a regulated 3.3V for the electronics.

Going with a 3.3V system posed some additional challenges for the sensors. All of the pressure sensors that have integrated electronics that I am aware of operate only at 5 volts. None at 3.3V. So I use a raw sensor and add an instrumentation amplifier.

3.3V operation is also a problem for the accelerometer. All of the usual suspects will not work at 3.3V. The only option I can find is the ADXL210. This provides digital PWM outputs but is limited to a +/- 10G range. By tapping the analog signal I can increase this to +/- 25G. Not enough for some flights but because I will be using the Kalman filter this will work even if the range is exceeded. The data will be clipped but apogee deployment will be on time.

For data storage I will include a connector to a MultiMediaCard. These are cheap ($30), provide large storage (16 MB and up), and have a simple SPI interface. I purchased a 64MB card and I expect to be able to store 4 hours of data at 128 samples per second. That is a lot of data!

(June 2006 note: I noticed that things have changed and you can get similar devices in an even smaller form factor. I just ordered a couple of 128MB Micro-SD cards from The Flash Memory Store for $15 each. I will follow up with an order to Sparkfun for a socket and a tiny lithium battery I noticed. This should be a better solution than the big battery I started with and mounting the memory card on the altimeter board should now be a snap.)

The most unusual aspect of this design is the safe and arm system.

The safe and arm system kills two birds with one circuit. (see schematic) The altimeter is designed to run off of a single 3V lithium cell (EL123 or equivalent). While the battery might be able to fire an electric match, it will not maintain sufficient voltage to operate the altimeter. So I want to charge a capacitor which will provide all of the current required.

The energy stored on a capacitor is proportional to the square of the voltage while the size is linearly proportional to capacity and voltage. So if a higher voltage can be used, the physical size of the capacitor can be decreased.

The RDAS Compact charges a 2200uF capacitor to a nominal 9 volts. To store the same energy at 3 volts requires 3*3 times the capacitance or about 20,000uF. This is going to be large.

At 40 volts a 100uF capacitor stores the same energy as a 2200uF capacitor does at 9 volts. The only trick is in getting 40 volts out of a 3 volt battery.

This requires a DC to DC converter. My starting point was the MAX845 transformer driver. With the appropriate transformer, this would easily generate the required voltage. But I decided not to use this part and use the microcontroller to switch the drive transistors. The MAX845 has its own internal oscillator and is controlled by a single signal line. This is a problem because a single failure could result in the capacitor being charged. Instead, I will control the transistor drive to the transformer with the microcontroller.

The safe and arm system then is under software control. While the main power switch is off, bleed resistors make sure that there is no energy stored on the firing capacitor. When power is turned on, there is no energy on the firing capacitor so any glitches on the output transistors are not a problem. Until the firing capacitor is charged, the altimeter is completely safe.

The firing capacitor can only be charged under active control of the microcontroller software. The signals DYNAMIC1 and DYNAMIC2 must be switched with the correct timing repeatedly in order to transfer enough energy across the transformer to charge the firing capacitor to the required voltage. A failure that results in either signal being on will not charge the capacitor.

Charging will only be done after launch detect and probably (I haven't decided yet) not until just before it is needed. One of my concerns with this circuit is that it does not meet the letter of the NAR level 3 requirements: "The capability must exist to externally disarm all pyrotechnic devices in the rocket. In this context, disarm means the ability to physically break the connection between a pyrotechnic device and the power source to its igniter. Simply turning off the device controlling the pyrotechnic(s) is not sufficient."

The hardware design controls the problem of a hardware fault causing an uncommanded event pretty well but there is still the problem of the software and sensors. So I think that I will add some power up checks of the sensors. I have connected the self test pin on the accelerometer to the microcontroller so that it will be easy to check and see if the accelerometer is working OK. The pressure sensor is more of a problem. The only checks possible are to make sure it is within some predetermined range (this limits the locations where you can launch rockets) and to see if there is any noise present.

The only other check is to make sure that a few seconds after power up that the velocity output from the Kalman filter is zero (or very close). This would make sure that a flaw doesn't cause the altimeter to arm the outputs as soon as it is turned on.

I have completed entering the schematic and I am ready to start on the PWB design. I am using the new schematic entry software from ExpressPCB to help with the process of designing the PWB. I suppose I could build a prototype by hand but it seems easier to build it on a PWB.

June 2004 Update

I finalized the PWB design and ordered some boards made. I also ordered the parts required to assemble everything. Alas, the PWB had a major design defect that put a stop to everything. The pad pattern I used for the power supply chip was wrong. As soon as I set this tiny little chip down to get ready to solder it, I knew I was in trouble. I don't know how I ended up with the wrong pin spacing but I did. I could see no good way to salvage the boards so I fixed the problem and ordered new cards.

7 July

New cards in hand I assembled the very first card.

The pin pitch on the microcontroller (0.025") and power supply chip (0.5mm!) present a problem when soldering. It is nearly impossible not to make solder bridges between pins. I read a tip on one site that said that by putting liquid flux on the pins you could then roll a ball of solder over them. I tried that and all I did was bridge every pin together. So I fell back on a slightly different technique.

I just glop the solder on with the intent of getting every pin soldered and ignore the bridges. Then I reheat the solder and suck the excess away with a spring loaded solder sucker. This usually pulls all the excess but leaves just enough between the pin and pad. I can then go back and touch the soldering iron tip to each pin a reflow the solder for any touch-ups. Since I am not adding more solder the chances of creating a solder bridge at this point are minimal.

With the card assembled it is time to start writing software. I am using the GNU tools for the MSP430. This includes code to interface the usual GNU debugger to the TI "Flash Emulation Tool" which is just a JTAG interface that plugs into a printer port. Because these tools are looking for a version of the C library on Linux that I don't have (it might be time to upgrade) I am doing this under Windows 98. A nifty program is provided to interface the debugger to the JTAG port is included. An interesting feature of this tool is that it connects to the debug hardware using standard TCP/IP prototcol. That doesn't seem like a big deal but it means that you can be running the debugger at home and the hardware could be anywhere in the world with an internet connection. Cool.

My first code was the equivalent of the classic "Hello World" program. It just flashes the status LED. But that verifies the tool chain and that the hardware is working. I then progressed to playing with the timer and interrupts. I set the timer to produce an interrupt at 1024Hz. The main program puts the CPU into low power mode (very nearly off) when it is done with its work. The interrupt routine wakes it up 64 times a second.

Code development is proceeding at a much faster pace than it did on the PIC. There are two reasons for this. First is that C is a much better fit to the MSP430 and all of my code is in C where all of the PIC code is in assembly. Second is that the JTAG interface makes debugging a lot easier. With the PIC, I could download code and then see what it did. With the JTAG interface I can download the code, run it, single step it, and look at register and memory contents. All without disconnecting the JTAG connector.

Learning new hardware is always interesting and the ADC has proven to be the most interesting so far. After some stumbling about, the code is reading the Y (rocket longitudinal axis) accelerometer 1024 times a second and filtering it. It is also reading the remaining stuff at 64Hz.

A quick check of the accel shows that the sensitivity is right where I expected giving a nominal range of +/-25G. The pressure sensor on the other hand is not right. I am reading 390 counts when it should be much closer to 900. There are a couple of possible causes for this. I could have computed the required gain set resistor wrong. Or the offset is messing things up. Both are easily fixed but I need to figure out which one to fix first. Which is hard without a pressure chamber.

I checked out the safe/arm circuit and found some minor problems. The first was that the resistor I put in to limit the DC current to the transformer also limited the output voltage. Obvious now. So that resistor is now a 0R0. A handy part. Looks like a resistor but acts like a wire.

I also discovered that the 1K resistor that connects the ground of the high voltage side of the safe/arm system doesn't have a trace connecting it to the rest of the circuit. I kind of need this so that the analog measurements work and the output FETs can be fired. A jumper fixes this for now.

After getting the safe/arm system up and regulating itself at 40 volts I checked to see how much of an additional load the igniters would be. When an igniter is installed there is an additional leakage path for the 100uF capacitor through 200K. It turned out to be much worse than I thought. The problem again was very obvious. Now.

There is a 10K resistor in series with the analog input pin of the microcontroller. When the 100uF capacitor is charged and an igniter is in place, there is 40V on one side of this resistor and the input pin on the other. The input clamp diodes in the microcontroller clamp the input to the 3.3V power rail and I end up sucking a lot of current. Yuck.

The solution is to replace the 10K resistor with a 1M resistor. I am still putting too much voltage on the input pin but this limits the current. The 10K resistor was large enough to prevent any damage but the 1M will limit the leakage current to a level where I can maintain 40V on the capacitor without excessive effort.

This might be a problem for the ADC as it has to charge an internal capacitor in its sample and hold circuit. 1M is way too much to charge this capacitor in any reasonable time. But that is why I have a 10nF capacitor on this input. Now the sample and hold capacitor charges from the stock of electrons in the 10nF capacitor. 10nF is much larger than the sample and hold capacitor so after the electrons have redistributed themselves the voltage hasn't changed very much. I use this same technique for monitoring the capacitor voltage.

So all of the hardware seems to be working (I haven't started on the SPI interface to the MMC card yet) so it is time to roll some Kalman filter code. Which goes very quick.

On a lark, I decided to code this up using floating point numbers. I have no idea if this will execute fast enough. It does fit although it drags in a lot of code from the library. The code bloated from a few hundred bytes to 4K instantly. Good thing this chip has 8K of code space.

The main reason for experimenting with floating point numbers is that I don't have a suitable fixed point multiply routine at hand. I need code that multiplies a 16 bit number by a 32 bit number and leaves a 48 bit result. The compiler provides at best a 32X32 multiply giving a 32 bit result. I really only use 32 bits of the 48 bit result but I need to be able to grab the right 32 bits. When I multiply 16.16 by 0.16 fixed point numbers I end up with a 16.32 result. What I need is in the 32 most significant bits. I suppose I could truncate the 16.16 number to just 16. but I think I will try floating point first.

4 Sep.

I ran across a web page for what appears to be a replacement for the Daveyfire electric match a while back. The interesting thing about this web site is besides the usual all fire and no fire current ratings, they also listed pulsed all fire and no fire energy. The all fire energy was stated as 3mJ (milli Joule) per ohm. I assume that is per ohm of igniter resistance. Or perhaps circuit resistance.

Using 2 ohms results in an all fire energy of 6 mJ. It is simple to compute the energy stored in a capacitor using: E = 1/2 * C * V^2 (capacitance in Farads, voltage in Volts, energy in Joules).

So at 40V, my 100uF capacitor stores 1/2 * 0.0001 * 40^2 = 80 mJ. Which is more than enough to get the job done.

Keep in mind that all fire and no fire current (and energy) ratings are probabilities. They are determined by estimating the average firing current and standard deviation. The all fire current is then the average plus three times the standard deviation. An occasional igniter will still fail to function at this current. So provide some margin.

The same goes for no fire current ratings. Just because the no fire current is specified as 10mA does not mean that applying 10mA will never result in an igniter firing.

I am having to reconsider the battery I want to use. I purchased a battery holder some time ago for the lithium battery in a size 2/3A package that looked reasonable. As part of this project I purchased some new holders and discovered that the design of the battery contacts had changed for the worse. They are fine for something that doesn't move but any force on the battery will cause it to move around enough to break contact. Really bad news.

I am thinking about maybe using a cute little rechargeble lithium cell instead. I purchased a 2 cell battery to power a GWiz LC Deluxe and this just might be what I need. The downside is that mounting is an issue with no battery holders available to purchase. Another problem is that the capacity is a lot lower. I had hoped to build an altimeter that could last for a very long time on one battery. Now I may just have something that lasts for a long time.

I am reconsidering the MMC card interface. The code development so far has been a pain and I haven't made much progress. The first roadblock turned out to be the result of my own laziness. I had gotten used to C compilers complaining when function arguement types didn't match so I got lazy about function prototypes. For some reason the GNU compiler for the MSP430 didn't complain when I passed an int and the function was expecting a long int. After I finally figured this one out, I managed to get the MMC card initialized in the SPI interface mode.

But I am seriously considering deleting the MMC interface and instead using a serial interface to the Rogue Robotics uMMC product. $70 buys a card that handles all of the MMC interface junk. As a bonus it can manage a FAT16 or FAT32 file system. Which is a non trivial process.

28 Nov.

I took the plunge and ordered a uMMC. I had some concerns because the specifications say that it runs on 5V. But after it arrived I looked at the parts and I think that it will work just fine on 3.3V

The MMC card requires 3.3V and there is a regulator on board to provide that. The AVR microcontroller being used will run on either 5V or 3.3V so that isn't a problem. The voltage regulator appears to be a very low dropout type so I don't think I will even have to bypass it. I can just feed the uMMC 3.3V instead of the 5V it is expecting and I think it will be fine.

In order to make this work I first need to hack on the altimeter board a bit. I was planning on using the SPI port to talk with the MMC card but now I need the UART port. These share the same hardware internally but use different pins. The TX and RX pins for the USART are currently driving the high voltage transformer. So I will have to cut and patch the traces to bring the TX and RX pins over to the connector and bring the high voltage drive signals over to the SPI port pins.

It is beginning to look like I will need a third batch of boards to make a truely flight worthy altimeter. I should be able to do some testing with what I have now but it will not be pretty.