My Flight Computer's First Flight

by Chuck McConaghy, LUNAR #359

Photo 1. Flight computer in payload carrier.
(photo by Chuck McConaghy, image processing by Lynn Kissel)

A number of club members bought the Taniwha Flight Computer kit last summer. I assembled mine in August but it took a while to figure out the software and just what I wanted to try with the computer. Besides assembling the computer, an interface box which interfaces a host computer such as a PC or a Mac must also be built. The interface box isn't complex and the only thing I found to be critical was to get the right wires to the receive and transmit lines that go both between the flight computer and the interface box as well as the lines that go between the PC and the interface box. (There are only four lines here but it is amazing how one can get them hooked up wrong.) When every thing is done correctly and power is applied to the flight computer, a sign on message that mentions the PROM (programmable read-only memory) version comes up on the host computer. The PROMPT also comes up and you can run through things like looking at the memory locations on the flight computer. The monitor also allows the host computer to download programs directly into the onboard RAM.

I originally hoped to make use of the high level languages contained in the PROM. I even went to the extent to read some books on Forth and was able to write a few things in that cryptic language. Although I was able to get into both BASIC and FORTH and even write programs that talked to the IO ports, I found there was one serious limitation with the high level languages. The limitation was the ability to save your program. I couldn't envision getting to the launch site and typing in a number of lines of code in either BASIC or FORTH. I made attempts at downloading programs in both languages from my PC but found the download operation for the high level languages to be less than reliable. This only left one option as far as programming the flight computer and that was machine language (sometimes called assembly language). I also noticed that others who were experimenting with the computer wrote everything in machine language. For those of you unfamiliar with the machine language route, here is how it works. You write your program in assembly language using your favorite editor or word processing program on your PC (or Mac). Once the program is written you run a program called an ASSEMBLER which converts the assembly language to 1's and 0's which can be directly loaded to the flight computer. One of the difficulties I experienced is that the assemblers both for the PC and the Mac that are on Paul Campbell's web site can't even be executed (and I tried both the Mac version on a Mac and the PC version on a PC). I don't know what the problem is here but I ended up using another assembler which recognizes the 8051 mnemonics. As you can see there were a number of considerations before I could even think about getting the computer "off the bench" and in the rocket. If anyone else builds their kit, I am willing to help them work through all these "small details." Now onto what I decided to do on the first flight. Since there are many details involved in using the computer such as writing the software, assembling the software, downloading it into the flight computer, launching the computer, hopefully retrieving the rocket and computer, (and hopefully with the battery still connected since I didn't add any EEPROM - electrically-erasable PROM, a type of memory that retains its information when the power is removed), and finally downloading any data, I decided the first flight would be one of logistics in how all these operations are done rather than any great instrumentation feat such as an altimeter.

Photo 2. Flight computer being fitted to payload compartment -- shown with ground support equipment (long-line computer interface).
(photo by Chuck McConaghy, image processing by Lynn Kissel)

The first flight was designed to measure the length of time from liftoff to ejection. In addition I designed an "Apogee Sensor" which was designed (but not well designed) to measure the time at which the rocket arced over. The I/O devices consisted basically of three switches. One switch was a magnetic switch used for liftoff detection, the second switch was a small microswitch located at the base of the payload section of the rocket which could tell when ejection occurred, and the third switch was an optoelectronic device which opened when a ball bearing blocked its path. The latter was part of the "apogee sensor" which had a ball bearing in a six inch long piece of clear plastic tubing. The sensor was at the top of the tube (or bottom of the tube if the rocket was pointing at the ground). Prior to liftoff the ball bearing was at the base or opposite end of the tube from the sensor. One other thing that was a little different was the use of the magnet switch for launch detection. To make this work a magnet was located on the outside of the rocket and held in place on the side of the rocket with a very small amount of adhesive. The magnet was tied to a fishing line which in turn was anchored to the launch pad. The objective was to keep the magnet on the ground and not impede the rocket takeoff. As it turns out this worked OK but proved to be a pain as far as aligning the external magnet with the internal switch. I might in the future go for some type of acceleration activated switch such as those used in Adept altimeters. The software was written to record the takeoff time. The takeoff time was measured in milliseconds from the time the program was executed. I intentionally set my watch so I could confirm the takeoff time (but then neglected to look at my watch in all the excitement). The software was also written to recyle and start over if for some reason the magnet had to pulled off and repositioned prior to launch. The main function of the software was to look at the state of all three switches every 100 ms. and to record that state in a memory location. The total length of time for storage was 25.5 seconds or 255 memory locations which I read out after the rocket was recovered.

How did it all work? Well I had everything together by the December launch. That launch was rained out. I tried again for January. January was too windy and foggy for G engines. Finally on February 15th 1997, "we had a go" I put the computer in my PML Phobos. By the way, the computer only weighs in at about 4 ounces with battery and some wooden supporting hardware. I felt safe launching with a G75 engine after running some simulations. The Phobos with an empty payload had previously been up a few times on G75's. I brought the computer to the launch site with a fresh battery but unpowered. At the pad I powered up. I connected the interface box to a portable computer. I downloaded the program and hit execute. I disconnected the interface box and the portable computer. I put the rocket in the payload and with a lot of effort to align the previously mentioned magnet. Then I stood by and waited what seemed like hours. (In actuality it was 1001287 ms. or 16.688 minutes) I didn't realize that there was a whole rack of rockets to be launched before my Phobos. As it turned out the battery held up, the rocket took off, the magnet came loose, the parachute ejected, the rocket landed near the rodeo grounds and scratched a little paint. I pulled the computer and did a hard reset (the only way to break out of my program) and found data both in the data slot for take off time as well as data in the 25.5 seconds of memory. I saved all the data on my portable computer and powered down the flight computer. I took everything home and analyzed it all afternoon.

Fig 1. Plot showing time history of signals recorded by the flight computer.
(graphics by Chuck McConaghy, image processing by Lynn Kissel)

The following is the data summary. The liftoff or 0 time was 1001287 milliseconds after execution of the program. Data was taken every 100 ms after liftoff and recorded in the table below is where significant changes occurred. In between times were the same as the previous event.

Table 1. Flight computer data summary.

Time	Ball Position	Magnet Switch	Ejection Switch
0	out of sensor	open	closed
2.6 s.	in sensor	open	closed
9.9 s.	out of sensor	open	open (ejection)
10.1 s.	in sensor	open	open
10.9 s.	out of sensor	open	open
12.0 s.	in sensor	open	open

To summarize all this the flight was 9.9 seconds from liftoff to ejection (or separation). The apogee switch ended up sensing some event at 2.6 seconds which implies the ball rose 6 inches in the plastic tube and stayed in that position all the way to ejection. I think all this says is the ball was traveling faster than the rocket. The 2.6 seconds is in the ballpark of engine shutdown for a G75 (around 2 second burn time). My speculation is that drag reduced the speed of the rocket after shutdown but did not reduce the speed of the ball. A theoretical physicist had commented something like this would probably happen and I think he was right. I thought the ball and the rocket would eventually be the same prior to apogee but surprisingly the ball stayed put at the top of tube all the way until ejection. As far as ball movement after ejection this was probably the effects of ejection and parachute deployment. I visually had observed the rocket arc over so I had a long enough delay on the engine to achieve ejection as the rocket was falling as opposed to rising. It is back to the drawing boards on apogee sensors. If anybody has a good idea other than pressure or acceleration sensors (those have already been done), I am open to suggestions. All in all the logistics went well and I still have both the rocket and the computer to fly again another day.

Information date: Mar. 8, 1997 lk