This project has been idle for a while but I am working on it again. There are a few changes.

The ADXL210 accelerometer has gone obsolete. Fortunately the ADXL321 is almost an exact replacement in functionality if not package. There is still no high-G accelerometer available that runs off of 3.3V. So I will still be counting on the Kalman filter to correct for any over range errors so that the apogee event will be on time.

I didn't like the big clunky lithium battery holder and the new design meant that it had to go. I am going to replace it with a rechargeable lithium cell hard mounted and soldered to the circuit card. Either a 100mAh cell that is about 15mmX30mm or a 200mAh cell that is 20mmX30mm.

The connector for the MMC flash memory card will go and be replaced with a socket. With the smaller lithium cell there is plenty of space. Especially since the new micro-SD cards are so small that if you sneeze you might lose it. Up to 1GB in a package smaller than a fingernail and about as thick.

Because the RAM on the MSP430F1232 was limited to 256 bytes, I was planning on resorting to nasty tricks to read and write to the MMC card as it is limited to doing it in 512 byte chunks. Doable but not pretty. So I was thinking about switching to an MSP430 variant that had more memory. The MSP430F149 has 2K of RAM which should do the trick. That and code for a FAT16 file system handler on it was published. I will hack on that code to make some optimizations. The main one being to limit thrashing of the FAT. I think I will start by creating a directory entry and find the first available FAT entry. I will assume that no one else has or will write to this file system so all subsequent clusters should be free. So I will just write merrily along. Once the flight is over and the rocket is back on the ground, I will go back and write all of the FAT entries and update the file length in the directory.

The MSP430F149 has way more i/o pins that I could possibly use on its 64 pin package. But one resource that is calling to me is the second serial controller. It is just begging for a GPS engine. Since there is a tiny (20mm x28mm)surface mount SiRF III engine available, I am thinking about mounting one on the altimeter card. There may not be space but who knows.

Another change is that I am starting to use a different CAD package for schematic capture and PCB layout. The gEDA set of tools looks interesting and it will output real Gerber files so I am not held captive to a single board shop.

Preliminary schematics here:

power supply



safe and arm


Something else which I am thinking about is the code organization. While I could write all of the code as I did the PIC version, it isn't very elegant and I think it will have its problems trying to manage the flash memory. So I have been considering using an RTOS to organize things. I have been looking at a few and the freeRTOS (TM) looks interesting. It also has a nice price. :-)

With an RTOS I think that the basic organization will be something like:

1024 Hz Interrupt service routine - this handles all of the ADC conversions. It will sample the longitudinal axis accelerometer at 1024 Hz and buffer the results. Every 16 samples it will also grab the other channels and then throw a semaphore to another task to handle everything.

The main task. It waits around for a semaphore from the ISR. When it does it swings into action. It runs the Kalman filter, sends data off to be written to flash memory, and anything else I can think of.

The "idle task". This runs when nothing else does. Its primary job will be to write data into the micro-SD card (if installed).

I still have a lot more reading to do before I have even a basic understanding of the RTOS. So it could be slow going for a while. I have an Olimex MSP430F139 header board so at least I have something I can dump code into to see if it works.

I spent some time working on the FAT16 code. In the end I didn't hack up the code published in the Circuit Cellar but just rolled my own. About the only thing that carried over was some of the code to read the file system parameters. Although even that was changed considerably because it didn't determine the file system type correctly. I was able to do a lot of testing under Linux to verify that it is working. The mkfs program can build a FAT file system and you can tell it to write the file system to a file. So I cobbled up a replacement for the MMC/SD code using the usual Linux open(), read(), and write() functions and tested the file system part. I found a few errors but it is now working. I haven't done exhaustive testing but I have done enough so that I am pretty sure that it works. By restricting the functionality to what is strictly needed and making various simplification, the code has become surprisingly simple. Compiled for the MSP430 it is about 2,200 bytes of code space. RAM requirements are a single 512 byte buffer, 50 odd bytes of local storage, and of course stuff allocated on the stack.

The next step is to integrate it with the SD/MMC code and try it on a real MSP430F149.

23 July 2006

I checked out my fat and SD code using an Olimex MSP430F149 header card and a 128MB micro-SD card. I had to squish a few bugs but it appears to be working just fine.

Because my needs for file i/o are very limited, the code has severe limitations. First is that it only understands FAT16 file systems. Reading of files is limited to returning the first 512 bytes of a calibration/configuration file. The remainder of the code allows me to create a file for writing, write a bunch of data to it, and close it. The file close routine does most of the work as it has to create the FAT chain and update the file length.

It doesn't do a lot and expects the free space to be continuous, but this is an embedded application so some sacrifices are to be expected. I probably ought to go over the code and clean it up some and add some more error checks to make sure that if it runs into trouble, it will be handled in a reasonable way.

The next step will be to return to my existing MSP430F1232 hardware and see if I can get the FreeRTOS system running on it. Hopefully it will fit into the 256 bytes of RAM. Integrating that with the file system will have to wait until, perhaps even if, I get PCB's made for the new version.

Simplified DC/DC converter circuit

I was reading the latest issue of Nuts & Volts when I suddenly realized that the circuit being discussed was nearly perfect for this altimeter. It was a simple boost type DC/DC converter. I am not sure why I didn't think of this on my own as this is an old technology. Probably my lack of experience with DC/DC converters in general. Here is the schematic showing the new converter section.

The only downside is that it is not transformer isolated so I will have to be very careful about layout or the high output current pulse could cause trouble. But other than that it is perfect. It is simpler and uses fewer parts. best of all is that it uses a generic inductor in place of the specialized, and single sourced, transformer. There are some catches of course.

The output voltage of the transformer circuit was limited by the turns ratio. The boost circuit has no such limit. A software bug during code development could cause the voltage to go way beyond the ratings of the parts involved. This could cause the drive FET to sacrifice itself. The voltage rating of the IRF 7103 part is a bit low for my tastes anyway so I will switch to a 100V rated device in a SOT-23 package.

One of the nice features of the boost circuit is that the output voltage can go very high. So if for some reason I decide that 40V just isn't getting the job done, I can boost it to whatever I want. Assuming that I don't exceed the ratings of the other parts involved.

The Nuts & Volts article covered the theory pretty well but didn't really address this application. The article assumed a constant load and a constant PWM drive of the converter. Here I will be charging the capacitor and the only load will be parasitic resistances. At least until it is fired.

But it is really quite simple. When the FET is on, the current through the inductor gradually increases to some value, Ipeak. Then the transistor is turned off. Because inductors just hate it when you do that, the voltage across it will increase and the energy stored in it will get dumped into the firing capacitor.

The energy stored in an inductor is given by 1/2(LI^2). So assuming a 100uH inductor and a peak current of 1 ampere that gives 50 uJ of stored energy. When the firing capacitor is fully charged to 40V it will have 80 mJ stored (1/2 CV^2). If there were no losses, and there always are, it would require 80mJ/50uJ or 1,600 cycles to charge the capacitor. Since my goal is to charge the capacitor in less than two seconds, that translates to about 13 cycles per sampling period (64SPS). So that is very workable. In fact I can probably get away with a much lower inductance which is good because it will reduce its size.

Picking an inductor will be tricky as there are several things to consider. Because the energy storage is heavily dependent on current, the higher the current the better. There are two things that limit the maximum current: wire size and saturation. Inductors that are of a reasonable size for the altimeter will have pretty small diameter wire. As a result it will be pretty easy to melt the wire. Fortunately, this is a low duty cycle pulsed application so the average power is low and melting of the inductor wire is really a small concern. Unless the drive FET should stay on for more than a few tens of microseconds.

Besides determining how much energy can be stored the inductance also controls just how fact the current will rise while the FET is on. Too small an inductance and the inductor might as well be a short circuit. Based on an equation in one of the application notes referenced in the Nuts & Volts article, a 100uH inductor will take about 30 uS for the current to rise to 1 ampere with a 3.3 V drive.

The last concern is the saturation current of the inductor. Since most of these parts have ferrite cores, the magnetic field will saturate at some point and not increase with more current. Obviously if you exceed this current you are just wasting power. This turns out to be a tighter constraint than wire size limits.