USAF Academy Falcon Gold

Mission Data and Telemetry Description


If you are unfamiliar with the Falcon Gold (FG) mission, consider reading the Increa Space web page or Dave Sipple's Falcon Gold web page first.  Falcon Gold launched aboard an Atlas rocket at 20:46 (EST) on 24 October 1997.  We use Amateur Radio volunteers around the world to log the telemetry stream and send us the data files via the internet. This document first gives a quick overview of what's involved with the telemetry, and then discusses details of three areas: The electrical characteristics of the 9600 bps downlink, the digital data framing (basically AX.25), and the format of the actual data in each field.

We sample 40 mSec snapshots of the GPS spectrum from behind the GPS constellation. After each snapshot, this data is transmitted to whoever listens. It takes 14-15 seconds  to download the data, then the satellite sleeps for approximately five minutes. It wakes up and does the same thing again. This continues until the batteries died.  [We predicted about a 2 week mission life, and managed to get about 16 days.]

The telemetry is in standard AX.25 format, modulated at 9600 bps using Direct Frequency Modulation (DFM) techniques standard in the Amateur Radio community. The only "catch" is that the data itself is binary values. You need a terminal program that won't get tripped up with random binary ASCII values -- and logs all the values accurately to disk.

Signal Electrical Characteristics

The downlink frequency for Health & Status and GPS data is 400.475 MHz.  This is accessible by most scanners and 70cm amateur radio gear. We're using slightly modified Tekk KS-960 transmitters to modulate the digital data stream from a Kantronics KPC-9612+ node controller onto the FM carrier with about 3.5 KHz deviation. This DFM is a Minimum Shift Keying technique that's standard with the amateur radio community to send 9600 bps data, as developed by G3RUH. If you have a scanner, use the "FM-narrow" setting (but see the caveat below). To your ear, it will sound like a rush of background noise.

Each bit of the the bit stream from the AX.25 protocol routine occupies 104 microseconds. But before sending to the radio, it's converted to an edge-oriented signal: a one is converted to a no-transition, and a zero is converted to a transition (either 0 to 1, or 1 to 0). This wavetrain, in turn, is XOR-ed with a psuedo random bit sequence agreed upon by all G3RUH modems. Finally, this signal is appropriately attenuated and fed to the radio as the actual "audio".

The highest fundamental frequency is 4800 Hz (from either the clock or the data stream, whichever you prefer), but this is a 'squarish'-wave, not a sine wave. The communication channel must preserve amplitude and phase information for signals significantly above 4800 Hz to preserve the proper waveshape. Typically as much as 3 times this much -- 12 to 14 KHz. Most scanners do not have this fidelity and many amateur radio transcievers older than a few years do not have this fidelity. You can use these radios, but the methods to do this are beyond the scope of this article.

Digital Data

We use the AX.25 packet protocol, which surrounds actual data bytes with 20 bytes of extra stuff. Unlike standard RS232-ish data, this is a synchronous format, so no start or stop bit is used. One byte of data immediately follows the previous byte of data. Sometimes you'll hear this called an octet to make the distinction. Similar to serial communication popular in the PC world, within a single octet, least significant bits are sent first. An AX.25 packet is described as follows (A single transmission may consist of multiple packets): Notice the 7E flag byte generates 6 consecutive 1 bits. One additional feature of AX.25 is that if the octet bit sequence (other than the flag) at any time provides five contiguous 1 bits, the sending station inserts a zero bit after the fifth 1 bit. The receiving station, of course, strips this extra 'stuffed' 0 bit before trying to interpret the data. This ensures there won't be any 7E hex values except as the first & last bytes of a packet.

Each of the 14 address octets is shifted one bit left. All address octets have a 0 in the LSB position, except the last address octet, which has a 1.

Data Content (the N bytes in the middle)

Falcon Gold will take 40 millisecond snapshots of the the GPS 1575.42 MHz L1 frequency. The RF signal will be downconverted and then sampled at a rate of 2 MHz. Since the C-code (course position code, not the C computing language!) is modulated onto the carrier at 1.023 MHz, FG will obtain a roughly 2x oversampled bit sequence. Remember, Nyquist theory doesn't apply here because we're not regenerating a waveform, but rather sampling individual bits. This process will yield 80,000 bits of data.

The spectrum sampler tacks on 52 bytes of header information before the actual data, yielding a 10052-byte sequence that needs to be downloaded to the ground station. A space-borne microcontroller will sample health and status information, collect the 10052 bytes of mission data, and send it all to a KPC-9612+ AX.25 TNC modem on-board the satellite.  If you're interested in doing post-mission analysis of the 10052 GPS bytes themselves, please e-mail me.  Finding the GPS satellites' psuedo-random fingerprints in this data is a fun programming challenge in its own right!  One hour, seven minutes, and 16 seconds after passing 45,000 feet, the first frame of data will be transmitted by the satellite, followed by additional frames every 5 minutes and 23 seconds.

At our ground station, a KPC modem decodes the data and provides a normal PC-ish serial byte stream to a computer, or a terminal, or a data logger, or whatever. I say 'normal', but be aware that the GPS data itself will be binary data, which could cause some terminal programs to do wierd things, or not log the data. This is the data format that we can most readily use here at the Air Force Academy. If possible, please e-mail us logs of data in this format.

FALCON>GROUND/2 [09/13/98 20:50:58]: <UI>:
01
Frame = 11
TT8_GPS_Time = 09/13/97 14:55:43
TNC_GPS_Time = 09/13/97 14:55:44
BusVoltage =+13.33 Volts
TempTop =+43.8øC
TempBottom =+37.9øC
FALCON>GROUND/2 [09/13/98 20:51:00]: <UI>:
02...244 bytes of binary followed by a CR/LF...
[Intermediate packets not shown]
FALCON>GROUND/2 [09/13/98 20:51:10]: <UI>:
42...244 bytes of binary followed by a CR/LF...
FALCON>GROUND/2 [09/13/98 20:51:10]: <UI>:
43...244 bytes of binary follwed by a CR/LF (but only the first 48 are meaningful)...
FALCON>GROUND/2 [09/13/98 20:51:11]: <UI>:
44
Frame = 11
TT8_GPS_Time = 09/13/97 14:55:43
TNC_GPS_Time = 09/13/97 14:55:44
BusVoltage =+12.89 Volts
TempTop =+43.8øC
TempBottom =+37.9øC

The Health & Status packets (#1 and #44) are normal, printable ASCII.  Each packet containing GPS data (#2 through #43) will start with 46 bytes of normal text, then the body will be 244 bytes of any binary value, then the packet will end with a CR/LF pair, which is added by the receive TNC.  Packets 2-42 each have 244 bytes of "keepable" data, giving 10004 bytes.  The last 48 bytes (making up 10052 total) come from the first 48 binary bytes of packet 43.

Notice the receiving station can change the headerline.  If possible, use your TNC's MSTAMP and DAYSTR commands (with a Kantronics TNC) to make your TNC generate headers of the same format as shown above, and please ensure your time is within a half second of UTC. Ensure neither your TNC nor your terminal program is inserting CR/LF into the data blocks (line wrapping for convenient terminal display) -- only a CR/LF pair at the end of each packet.

Every 5:23.1 minutes, another 44 packets of information (another frame) will be downlinked by the Falcon Gold payload. Combining multiple frames into one log file is fine.

Feedback on the descriptions above, or other inquiries are welcome. This page was last updated April 2021.  The best way to contact me is via e-mail.