Using APRS for Space Communications


APRS experimentation was authorized via SAREX on STS-78 in June 1996. Ham Radio activity was reported on 15 days of the mission with 20 voice passes, 25 packet passes and 11 school passes, or 75% of all passes. A great effort on the part of the STS-78 crew!

Eighteen APRS stations successfully digipeated their position via SAREX and 2 others relayed STATUS, but no POSIT. A total of 65 APRS packets were received. Thirty Nine APRS stations attempted transmissions but indications are that only about 10 APRS stations were making a serious effort and trying every pass. This compares favorably with statistics for conventional SAREX ROBOT activity of 561 stations being heard a total of 1350 times with only 146 getting a successful QSO number. It is estimated that thousands tried...

SEE ALSO: TRAKNET.HTM for a proposal to use the 1200 baud PACSATS for a worldwide amateur mobile status/position reporting network.


APRS is an ideal solution to the congestion normaly found on any narrowband Amateur Satellite uplink channel. Especially the high visibility missions where many of the 2 million world wide amateurs want to make a brief contact in a short period of time such as SAREX.

The problem with SAREX is the total saturation on the uplink channel which makes the use of a normal CONNECTED protocol impractical. For the SAREX robot QSO mode, a total of five successive and successful packet transmissions are required to constitute a successful contact. Of an estimated tens of thousands of uplink stations, only a few hundred are successful. Recognizing the stringent requirements for success using the CONNECTED protocol, provision is also made to recognize those stations which were successful in getting only one packet heard onboard the shuttle. Almost three times as many stations are heard (one successful packet) as are successful in the full two-way connected protocol.

APRS takes advantage of this unconnected, one packet, mode to demonstrate successful uplinks to the shuttle. In addition, however, it capitalizes on the most fascinating aspect of the amateur radio hobby, and that is the display on a map of the location of those stations. Historically, almost every aspect of HAM radio communications has as its root, the interest in the location of other stations. Look at DX maps, countries worked, counties worked, grid squares, mobile chatter; everyone is quite interested in where other stations are.

If, instead of every station attempting to CONNECT with the SAREX on the Shuttle, all stations simply inserted his/her 6 digit gridsquare into their TNC TO callsign via the SAREX callsign, then, everyone within the satellite footprint would not only see when he made a successful uplink, but also where he was. It takes a total of 128 bytes for a successful SAREX QSO plus 92 bytes for every retry. The APRS GridSquare packlet only takes 26. This alone could provide an order of magnitude improvement in the number of successful SAREX contacts.

Since the shuttle is a rapidly moving object, the locations of successful uplink stations will move progressively along the ground track. The weakest successful stations will almost certainly be immediately below the spacecraft. Stronger and more viable groundstations can show up further to the side of the ground track. If there is a skew in the spacecraft antenna pattern, the pattern of successful uplink stations on the map will clearly make that evident.

GRID SQUARE POSITION REPORTING: To convey more information than just seeing station callsigns plotted via grid square on the map, provision is made for stations to also include a special Station SYMBOL character in their packet as well. The format is ]$[ at the start of the packet and will cause APRS to use $ as the symbol character ($ can be any of the 94 APRS symbols, see SYMBOLS.HTM). This format will also force APRS to interpret the TO address as a grid square, even if it is not in SPACE or MScatter mode.

FORMATS: APRS and APRtrak respond to both the conventional LAT/LONG APRS POSITION reports and to other packets with included Grid-Squares. The exact format of a minimum APRS GridSquare packet is as follows. Obviously the GRID-IN-TO format is the shortest and preferred. These formats convey both your POSIT and your STATUS comments in your

     GRID-IN-TO FORMAT:         WB4APR>FM19SX,W5RRR:Hi!...
                                                    ^^^ Symbol indicator
                                                        See SYMBOLS.HTM

To implement this experiment on any shuttle mission, the SAREX TNC only needs to have DIGI ON and the word needs to get out to everyone to insert their Grid Square in their UNPROTO or BText command. No changes onboard the shuttle or other spacecraft TNC would be required.

Those stations that had APRS or APRtrak could then watch successful uplink stations plotted in real time. Even without real time APRS, a replay of a captured text file containing all the successful uplink packets would still give an excellent map display after the fact. Analysis of antenna pointing anomolies on every orbit could be accomplished with ease. On future missions, the UI beacon frame might completely replace the current CONNECTED robot mode. Without all of the connect requests, acks, and retries, a many fold increase in the number of successful uplinks might be realized, and the data exchanged would be more meaningful by a similar factor.

SPRE EXPERIMENT: The first APRS experiment was during the Uiversity of Maryland SPRE mission on STS-72. During 3 midnight and later passes, over 66 stations successfully uplinked position reports. You can replay this file using the FILE-REPLAY command and select the SPRE file.

DEMONSTRATION: To demonstrate the expected results of a SAREX flight, replay the SHUTTLE.HST file and watch the contacts appear as the shuttle moves across the country. You may enhance the demonstration by selecting to see only the Shuttle, STS-99, or by turning off CALLS to reduce the clutter of callsigns on the display. Obviously, in this SHUTTLE.hst file, I assumed that the Shuttle had its TNC connected to a GPS navigation receiver so that it was also beaconing its position once per minute in the APRS format.

This capability also demonstrates the practicality of using a space AX.25 digipeater for routine position and status reporting. Imagine a constellation of three AX.25 digipeater satellites all on one FM channel. It would not matter what satellite was in view, or when. Mobile and portable stations could beacon their position once every 5 minutes and be tracked nationwide! Just using 1200 baud AFSK, up to 1000 stations could probably be supported just in the US and have a reasonable chance of getting a position report through at least once every 3 hours! Going to 9600 baud FSK would support almost 8000 users. See the TRAKNET.HTM file.

APRS and APRtrak use a special SPACE FORMAT which also configures them for sending their GRID SQUARE Status beacon via a space digipeater:


To have a good chance of being seen via the SPACE digipeater and to minimize unnecessary QRM, use the following procedures. Even under worst case scenarios, APRS stations will still generate fewer packets than other stations attempting to CONNECT to SAREX.

Use UNPROTO to set your VIA path to the Space DIgipeater (W5RRR-1)

AUTOMATIC OPERATION: In AUTOspace mode, your station will transmit your normal packets about once every 15 minutes. This is less than one-half of one percent (0.5%) of the number of packets generated by other stations trying to connect to the spacecraft. If you have set AUTOspace MODE, then APRS will listen for the DIGIpeater shown in your UNPROTO path. Once it hears it, it will reset your STATUS timer to minimum and also set a random number of seconds up to 12 before your first packet is transmitted. As long as you continue to hear the digipeater callsign, your STATUS timer will stay at minimum and your starting time to the first packet will continuously be reset to a random number under 12. Since APRS is on a 5 second timing cycle, you have a 5/12 or 42% chance of transmitting in each window as long as the digipeater is being heard. This gives you an average of about 1 packet per 10 seconds which is still less than what a connected station would be doing...

If this idea catches on, then maybe all of those other stations will STOP trying to CONNECT to the spacecraft and join us! That would be a net REDUCTION in QRM to on the uplink!

Imagine the fun that the cosmonauts and astronauts will have if they carry a lap-top computer so they can see everyone on their maps!

I hope that other users of SAREX will try APRtrak and realize the reward of a successful digipeated position report. The net effect would be FEWER packets on the uplink, and more meaningful packets on the downlink!

APRS POSITION REPORTING VIA THE 1200 BAUD PACSATS! Although any of the PACSATS can operate in digipeater mode, only the WO-18 ground team has officially invited APRS position reports. Other PacSats with DIGI on could be used as well (AO-16 and ITAMSAT), if there were no objection and digipeater remains on. There are several items that make these satellites very attractive to APRS:

  1. They can use ANY 10 watt or better FM XMTR on the uplink!
  2. Uplink only requires an OMNI antenna with no pointing (mobile!)
  3. ANY TAPR-2 compatible TNC (with an 89 cent mod) can be used on the UPLINK. (see TRAKNET.HTM). The mod is a 7400 chip wired as an XOR between the XMT clock and the data.
  4. For vehicle tracking, only a few downlink stations are needed, since they can digipeat the packets onto HF and VHF nets or be linked into live WEB pages...

Receiving the BPSK downlink takes a separate BPSK satellite modem, but many hams already have these...

APRTRAK AND APRS: Since APRS has great potential in the effective use of orbiting packet radio digipeaters in the amateur satellite program, a special version of ARS called APRtrak has been donated to AMSAT for use in the amateur satellite program. It is a stripped down version of APRS with added Spacecraft tracking capabilities. See APRTRAK.HTM. APRS still retains a minimum SPACE mode too.

Return to Table Of Contents

Mail comments/corrections on content to Bob Bruninga and on HTML formatting to Steve Dimse