The ZX-24 microcontroller makes an excellent basis for a high-altitude balloon mission's flight computer. Unlike a Basic Stamp, it has no trouble with signal timing on async serial connections, it has plenty of memory for bufferring incoming data streams, and it executes programs MUCH faster than any of the BS2 series. In addition, the ZX-24 has the ability to run processes in the background - this makes it easy to kick off processes to manage the GPS and TNC data streams, while keeping the high-level logic running continuously in a separate code block.
Having started my foray into microcontrollers with the Radio Shack BOEbot kit, I have used the Parallax "Board of Education" (BOE, get it?) as the breakout and prototyping board for the ZX-24. This pin-compatible platform has made it extremely easy to test various circuit designs.
In an actual high-altitude balloon mission, the ZX-24 and BOE carrier will be accompanied by a TNC-X to serve as the packet engine. If the entire TNC-X is included (for better shielding), the two will communicate via the main serial connector of the TNC-X. If only the circuit board from the TNC-X is flown, the BOE will more likely connect to the TNC-X's 8-pin expansion bus using pin header jumpers. The TNC-X's audio and PTT lines will then connect to the primary radio's headset jack.
The flight computer will also connect to a GPS receiver. This part is a little tricky - the secondary radio is also APRS-capable, so it can benefit from a GPS feed as well. The best way to feed GPS data to both devices might be to build a Y-cable to physically connect the GPS receiver's serial output to both circuits, and use a transistor buffer on the BOE to minimize the current drain on the serial line. I have not experimented with this approach yet, but it seems feasible.
Rounding out the flight computer's design are a number of single-purpose loose wire connections, using the bOE as a breakout board. I intend to have both internal and external temperature sensors, and relay connections to a digital camera and one or more electrothermal (or possibly electro-pyrotechnic) cutdown devices.
Note that none of these connections use the built-in DB-9 serial port on the BOE. That connection is reserved for pre-flight monitoring and launch site debugging.
The flight computer code (attached below) is a working copy from May 2007. Though it has never undergone a full systems integration test in the field, it has performed very well in a workbench setting. I consider it to be of beta quality, though some of the oddball sensor routines are more like pre-alpha (reading the temperature as a function of resistance across a diode, for example, or the very flaky supply voltage measurement routine).
The structure of the program is simple enough. First it defines some constants and global variables, then it starts the main routine, which kicks off the background tasks and settles into an endless loop. Scrolling downward are the background routines (wihch are also endless loops), then the regular subroutines and functions.
The real meat of the program is in the background tasks, which are the GPS and TNC handlers referred to above. They parse the incoming streams, look for key values that indicate something interesting is coming, then keep the good stuff and ignore everything else. For this specific application, I have chosen to use the GPS "GPGGA" and "GPVTG" sentences. These two sentences provide all of the location, course, speed, and altitude data that are critical for tracking and recovering the payload.
The TNC handler has an even easier job - it just listens to the incoming APRS data stream, looking for its own callsign. If it hears a particular message addressed to that callsign, it will send down an acknowledgment and trigger the cutdown mechanism. For such a simple parsing task, a full decode of incoming KISS frames is not required. The flight computer can ignore the special KISS encoding of the APRS path string, for example, and simply scan the plain-text frame data.
One early challenge in the design of this program was to figure out how to speak the KISS protocol to the TNC for outbound APRS and telemetry packets. This turned out to be easier than I had expected. Outbound KISS frames can be assembled for transmission as follows:
1. Start the frame with an ASCII 192 and an ASCII 0.
2. Append the "path" string, with each byte left-shifted one bit (that is, each ASCII value is multiplied by 2).
3. Toggle the LSB "on" for the last byte of the path (add 1 to its doubled ASCII value).
4. Append an ASCII 3 and an ASCII 240.
5. Append the packet data (all in "printable" 7-bit ASCII).
6. Append an ASCII 13 and an ASCII 192.
Once the TNC hears the final 192, it should listen for a clear frequency, then send the packet over the air.
My normal testing configuration is:
* BOE 9-pin serial port to laptop
* Random wires to connect BOE to serial-to-USB adaptor, to laptop
* Two 4-wire jumpers to connect the BOE to 8-pin TNC-X expansion port
* TNC-X 1/8" audio out to desktop audio line in
* TNC-X 1/8" audio in to desktop audio line out
* Laptop runs ZBasic IDE (connected to BOE serial port)
* Laptop also runs Hyperterminal (connected to serial-to-USB adaptor)
* Desktop runs AGWPE soundcard packet engine
* Desktop also runs WinAPRS or AGW Tracker, connected to AGPWE packet engine
In actual use, the GPS input will come in about 5 different sentence types, 40 to 60 characters per sentence, at 4 sets of sentences per second. This yields a duty cycle of about 25% on the 4800 bps channel. In order to test the parsing algorithm, I normally take a one-hour capture of GPS data from a highway drive a couple of years back, and replay it as a text dump to Hyperterminal on my laptop. This pumps the data into the flight computer at about 4x normal speed. The ZX-24 has never had any trouble keeping up.
The TNC-X -to-desktop audio connections allow me to simulate ideal reception of the TNC-X's radio transmissions. This in turn allows me to simulate tracking the flight computer in WinAPRS or AGW Tracker, as if the flight computer were really travelling the route specified in the GPS data described above. I can also use the APRS software on the desktop to simulate sending messages to the flight computer over APRS, to test the message parsing and remote cutdown routines.
Last update - May 27, 2007