Larry & Margie's Rockets

Well, OK, Margie's more into demonstrating Newton's laws then 'rockets' in general, but Larry has fallen hard. Look for Pictures of our rockets, and details of Larry's ongoing Flight Computer work below. Larry is now involved theICANO project, one of the groups trying for the CATS (Cheap Access To Space) prize, sponsered by the Space Frontier Foundation. Wish us luck!

Last Modified: 7 July 98

Commercial Links:

Pictures, More Pictures, other sites and Organizations:

Other

Fiber Arts

Brewing

Astronomy

Rockets

Personal

Family

Larry's Flight Computer Stuff

I've been playing with Paul Campbell's 'Taniwha' flight computer. This is a small computer suitable for flying in HPR rockets, recording flight data, and maybe someday staging, and ejecting parachutes at appropriate times. This is a very flexible computer, with hardware details like what sensors to use left up to the builder (yes, it's a kit). Software is also in a rather primitive stage. Paul has supplied a ROM based monitor, BASIC, Forth, and some code for dealing with a 10bit ADC and such. He has also supplied cross assemblers for major host machines. Take a look! good stuff.

I've done a lot with this system. You can browse through all the boring details, or skip to what you might be interested in:

Also, Doug Steinfeld has made some interesting modification on my latest version (especially nice, as I have been working on another project so haven't added anything here recently. I will though, promise!). Look at Doug's chages!.


Taniwha Computer #1 hardware:

My first Taniwha Flight Computer was set up a little differently then most. I replaced the suggested ADC1034 (10 bit, 4 channel ADC) with a MAX186 12 bit, 8 channel ADC. This chip uses the same I/O control lines as the previous ADC (the protocol is a little different, though), and measures 0 to 4.095vdc. I have a ADXL50 Accelerometer on channel 7 of the ADC. The circuit for this has been modified a bit from that supplied by Paul to allow me to calibrate the output signal. This signal has been calibrated for a 0g output of 2v, with a +/- 2v swing (ie: 0-4v for -50g to +50g). I also have a MPX4115A barometric sensor on channel 6 of the ADC. This sensor puts out from .204v to 5v for the range of 15kPa to 115kPa (about 2.25 to 17.25 psi). I've not modified this, as I don't expect to need to go to 17psi. I also put a 'shorting wire' on port 1, bit 7 for on-the-pad arming, and a little beeper on port 1, bit 5. The board has room for a single 24lc164 2k byte NVRAM. Instead of installing this, I put in a socket on the 'wrong' side of the board. Into this, I plug a little daughter card with 2 or 4 of these NVRAMS, giving me 4k-8k bytes of storage. My software (see below) samples both sensors 16 times a second, and stores their 12bit values. This means I can record 160 seconds of flight data. I also have two cards with 2 chips each, giving 80 seconds of flight data. I have schematics of my ADC / Sensors changes, Beeper Hookup, and NVRAM card.

Taniwha Computer #2 hardware:

My second Taniwha FC is set up different also. For an ADC, I am using an LTC1298 2-channel, 12bit ADC. For Acceleration sensing, I am using a new ADXL150 sensor. This should be shipping soon, has improved noise and resolution, and connects straight to the ADC - no extra parts (OK, a bypass cap...). I also will be moving to the new 24LC64 NVRAMs, but I will still make them field changeable. I am keeping the beeper, but loosing the P1.7 arming input. Why? I'm convinced I don't need it. I have convinced myself that any rocket using a FC should have a power on plug in the BT of the rocket - no screwing on of nose cones! If ejection is to be done by the FC, there should also be shorting plugs. Initial testing of this setup shows a noticeably less noise then before.

This unit, with version 2.0 of my software (below) successfully controlled duel deployment at BALLS '97!!!

Flight Computer Software

Disclaimer: I make no promises about any of this software, so please, do your own tests, and take responsibility for your own decisions. I refuse to take any responsibility for any damage that may occur from use of my software. It is provided for example purposes only!

For those of you with Java capable browsers, I have a page with a little Java applet that will graph the data I've collected from various flights. Take a look!

Source for reading a MAX186 12bit, 8 channel ADC.

Source for reading an LTC1298 12bit, 2 channel ADC.

Source for reading and writing NVRAM. The write/read routines now return with carry set if the memory is not present (or responding). This source now also has a simple test program.

Source for a quick, accurate baro-output to altitude routine. This code assumes a MPX4115A and a 12bit ADC, but there should be enough information given in the comments to modify the code/data for other configurations. Basically, the routine works by using a table of pre-calculated altitude values at selected intervals, and uses linear interpolation to calculate the values in between. The altitudes generated by this code will generally be within a foot of the normally calculated value, but rarely more then 2 feet off (those at the higher altitudes). Of course, this code should be used to generate altitude by taking the difference in altitude between a given sample, and pre-liftoff. When using with a 10 bit ADC, the baro reading should be multiplied by 1.2 before passing to this routine. The SRAM data logger mentioned below does this.

Source for an integrated Monitor / Flight computer (v2.0), And ROM image, or both, zipped. This contains complete sources for launch detection, data logging into NVRAM, stores multiple flights in NVRAM, burnout, apogee, and low-altitude detection, end-of-flight maximum altitude beep-out, and optional triggering of pyro ports. Also has monitor commands for getting NVRAM information. This has been used to fire a pyro ports at apogee and low altitude! The data dump does show when it thinks it fires a pyro port. This code does assume my hardware config (LDC1298 ADC, accel, baro, beeper), but the source can be assembled to work with the ADC1034 or MAX186.

Source code for data logging and event handling and Memory image. This code is designed to run in SRAM. It should be loaded as a code block in NVRAM, and the FC configured to autoload it at power up. This is a new feature in Paul's monitor source version 2.20. This code will record acceleration and baro data 16 times per second, detect burnout, apogee, and return to low altitude (255 feet), and can trigger pyro charges upon detection of those events. It will also beep out maximum altitude if a beeper is connected to p1.5. This code does not yet deal with multiple data blocks per NVRAM, so it will overwrite its own image in NVRAM.

I haven't yet updated this code to v2.0 because of a bug in the ROM monitor (which I fixed in my version). My software needs to figure out how big the NVRAM is for the multiple data set feature, and the code that detects timeouts during NVRAM access will hang in v2.3. I have sent Paul a message about this, but I haven't seen an update yet.

Source code for functions to read and display flight data in NVRAM as recorded by the above autolog code. Also RAM Image. This code can display the header information (base altitude and acceleration readings, configuration, etc.) and dump acceleration, baro, and state data in decimal, as comma separated values. This dump can be captured to a file and graphed by my Java program or imported to spreadsheets like Excel.

A data dump of NVRAM looks like this:

:-) dn 0
 Acc, Baro, state
0041, 4020 
0281, 4016 
0244, 4017 
0230, 4023 
0244, 4018, 0007 
0232, 4018 
0219, 4018 
0211, 4015 
0204, 4015 
0195, 4013, 0015 

The output data format is: 1st (Acceleration) column: ADC units of acceleration, normalized so that a reading of 0 is sitting on the pad, ready for lift off (ie 1 gee). This number is in units of 1/40 G (for 12bit data, 1/28.57G for 10bit data). 2nd (Baro) column: ADC Units, barometric sensor output. This will be a number in the range 204 to 4095. The 3rd (state) column shows where the computer thinks it is in the flight profile. This is an 8 bit number that will show in the range 7-255. Here is what the bits mean:

1 Warmed Up
2 Armed
3 Possibly Launched
4 Launched
5 Burnout
6 Apogee
7 Low Altitude
8 Pyro Change Firing

The state byte is only written once per nvram page (each 5 ADC entries).


Calculations

There are many things that affect how you convert from 'ADC Units' to something more understandable, like feet per second, or altitude. The first thing to be aware of is the 'full scale span' of your ADC. This can be just about anything, but for use on the flight computer, we would like it to be in the range of 5v. Look in the datasheet! For some devices I have worked with, these are:

ADC1034 - 5v
MAX186 - 4.096v
LTC1298 - 5v

This span. when divided by the numeric range will give the 'ADU', i.e., the value of the 'analog-digital unit' in volts. So, for the above devices:

ADC1034, 10bit ADC.  5v / 1024 = 4.88mV = 1 ADU
MAX186, 12bit ADC.  4.096v / 4096 = 1mV = 1 ADU
LTC1298, 12bit ADC. 5v / 4096 = 1.22mV = 1 ADU

The next thing to look at is the datasheet for the sensor. It will also have a 'full scale span', which is the range of voltage it will put out, as well as an offset. The offset is the lowest voltage it puts out, and corresponds to the bottom of its measurement range. The datasheet will also state what voltage output corresponds to what more conventional units the data can be read in, as well as the measurement range of the device. Again, for some devices that I have on hand, here is the relevant data:

Sensor                 Full Scale Span   Offset     Units   Measurement range
MPX4115 Pressure Sensor.  4.5v           .204v    45.9mv/kPa  15-115kPa
MPX4100 Pressure Sensor.  4.7v           .252v    54 mv/kPa   20-105kPa
ADXL50 Accelerometer.     1.9v           .85v     19 mv/G     -50 to +50 G
ADXL50, w/amp, gain 2.11*  4v		       .5v	     40 mv/G     -50 to +50 G

* This is how the accelerometer is configured in Paul's FC.

As you can see, none of the sensors exactly fits the ADC range. That means that we will be 'wasting' some bits. They are close enough though. Also, these are nominal values! Don't trust them! They will be close to correct, but you shouldn't make assumptions like: "Gee, based on this, 0g should be 2.5v, which on my ADC1034 would read as 512. I'll use that as a base value". Just don't do it. You do need base values, but do them as measurements. Hold the board sideways for 0g, or read it on the pad for 1g. It will give much more accurate results.

We now have all the information we need except for conversion from the conventional units given in the datasheet to the conventional units we want. Below, there is a table of conversion values for different units or pressure. For acceleration, 1G = 32.2 ft/sec/sec = 9 m/sec/sec. To convert from an acceleration reading to ft/sec/sec, this is what we do:

As = Acceleration sensor reading
Ab = Base acceleration reading (from pad).  This is needed because we want to
     remove acceleration due to gravity.
A = Acceleration in ft/sec/sec.

A = (As - Ab) * ADU / Sensor units * conversion factor

for the ADC1034 and ADXL50 that would be:
A = (As - Ab) * .00488 / .04 * 32.2

Altitude is similar, though taking a base reading on the pad is even more important, because barometric pressure is affected by weather as well as altitude. Unlike with acceleration though, we need to calculate altitude based on measured pressure, then subtract base altitude to get the altitude difference from pad to rocket. So, to get altitude in feet:

Pkp = Pressure in KPa.
Pp = Pressure in PSI.
B = Barometric sensor reading.
Ap = Pressure Altitude.

Pkp = ((B * ADU) - sensor offset) / Sensor units + Sensor Range Minimum
Pp = Pkp * .14504  (from table below)
Ap = ((Pp / 14.696)^(1/5.255876)-1) * -145442

For the ADC1034 with the MPX4100:
Pkp = ((B * .00488) - .252) / .054 + 20

Not so hard at all! Now, the altitude code I actually use in my logging software doesn't actually do all this. Instead, I've used the above equation to generate a table of altitudes for 64 equally spaced ADC readouts, as well as some interpolation coefficients. So to calculate altitude, I just do a table lookup, and some simple interpolation.

Another shortcut I make is to treat the 10bit data from the 1034 as 12bit data. Notice that the ADU is .00488, which is exactly 4 * .00122, the ADU for a 5v, 12bit device. As the reading is 0 filled, it will look like a 12bit ADC that always seems to change in units of 4ADU. 12 bits is also easier to manipulate.

If anyone sends me an appropriate EPROM + return postage, I will be happy to burn in Pauls' current monitor version with my latest data logger version. Be sure to specify what size NVRAM, and what type ADC you are using. Send to:

Larry Lynch-Freshner
865 Middleton Drive
Boulder Creek, CA  95006

Coming:

Table 1. Pressure Unit Conversion Constants

(Most Commonly Used - Per International Conventions)

 
PSI(1)
in. H2O(2)
in. Hg(3)
K Pascal
millibar
cm H2O(4)
mm Hg(5)
PSI(1)

1.000

27.681

2.036

6.8948

68.948

70.309

51.715

in. H2O(2)

3.6126 x 10-2

1.000

7.3554 x 10-2

0.2491

2.491

2.5400

1.8683

in. Hg(3)

0.4912

13.595

1.000

3.3864

33.864

34.532

25.400

K Pascal

0.14504

4.0147

0.2953

1.000

10.000

10.1973

7.5006

millibar

0.01450

0.40147

0.02953

0.100

1.000

1.01973

0.75006

cm H2O(4)

1.4223 x 10-2

0.3937

2.8958 x 10-2

0.09806

0.9806

1.000

0.7355

mm Hg(5)

1.9337 x 10-2

0.53525

3.9370 x 10-2

0.13332

1.3332

1.3595

1.000

NOTES: 1. PSI - pounds per square inch; 2. at 39°F; 3. at 32°F; 4. at 4°C; 5. at 0°C

Go Back