ASTARS, an APRS SATELLITE TRACKING AND REPORTING SYSTEM Bob Bruninga, WB4APR For up-to-date info, see: www.ew.usna.edu/~bruninga/astars ASTARS grew out of TRAKNET which was presented at the 1998 and 99 AMSAT conferences as an early 1200 baud APRS satellite mobile experiment with AO16,LO19 and IO26. The ASTARS concept was validated on several tests with MIR, SAREX and ISS. But ASTARS was really born when Kenwood introduced the 9600 baud capable APRS data mobile called the TM-D700. This dual band data radio with built-in 1200 and 9600 baud TNC's and front panel APRS displays made it possible to send and receive the very short APRS style comunications via any of the 9600 Baud PACSATS. Unlike the 1200 baud PACSATS which required special PSK modems, the 9600 baud PACSATS use FM radios and FSK. Thus, the D700 radio is an off-the-shelf satellite data terminal ready for ASTARS! Secondly, the presence of the Internet that makes possible the linking together of multiple disparate downlink sites allows a tremendous gain in reliability through space and time diversity reception. These stations, called P-Gates (PACSAT IGATES) combine all packets heard into the existing worldwide APRS infrastructre (APRServe) to any compatible APRS station in the network. This file describes ASTARS beginning with its Limitations, expected Operations scenario, the D700 set up for mobile operation, Linking traffic to/from the worldwide APRServe system via P-Gates, how the P-Gates operate, and how the terrestrial APRS system can distribute satellite access times to the mobiles with minimum bandwidth. EXAMPLE: The APRS Mic-E format used by the kenwood radios transmits all of the following information in only 9 bytes except for the STATUS text which adds 1-for-1 to the length of the packet. Thus, a lot of infomation can be transmitted in less than 0.5 second per mobile. Here is an example pass as received on a Mobile: CALL STATUS ICON GRID DIST CSE/SPD COMMENT -------- --------------- ---- ------ --------- ------- -------- WB4APR-9 Bob at work HT FM19sa 101mi N parked Off duty WS4Z ws4z@amsat.org car EM43uh 847mi SW fixed Special KB8GVQ-8 Testing D700 Jeep EN91dk 320mi NW 000/000 Off duty K2SAT Using APRStk Dish EM62bw 763mi SW fixed Committed KA1RRT QRZ Boat EL87nw 849mi SW 043/008 Enroute N5SUB Lookin for Tfc Van EL29FX 1251mi SW 075/000 CUSTOM 3 KB2WQM-7 At da beach! AMSAT FM29PE 96mi NE 000/000 Off DUty K5WH-14 @amsat.org Truck EL29fx 1252mi SW 178/000 In Service LIMITATIONS: The 9600 baud UPLINK is trivial to do and works fine from any mobile omni antenna. But the overall system has several limitations that drive the operational scenario: 1) Due to multiple use of these satellites, un-necessary congestion on the uplink is to be avoided. 2) The weak downlink can only be received for the central 3 minutes or less of an overhead pass on an omni mobile whip. 3) Longer pass times are possible with a cumbersome 4 ele beam. 4) Such overhead passes only occur once or twice per day per satellite. OPERATIONS SCENARIO: To develop a viable satellite communications system between mobiles and to/from the P-Gates to the worldwide APRServe system within these limitations, the following operating scenario is recommended. 1) To more easily recognize satellite mobile stations, stations should use the SSID of -3 and save this in a PROGRAM MEMORY only used while operating via the satellites. This is so the P-Gate can distinguish traffic for your satellite station separately from terrestrial traffic pending. 2) Due to the widely sparsed access periods, the mobile uplink objective should only be to get ONE posit reliably relayed per pass. It appears that a 1 minute rate per mobile can guarantee such success... without overkill. 3) During a pass, mobiles can uplink any outgoing messages. The fixed once-per-minute message rate and 5-times-timeout of the TMD700, is just about right. 4) If the P-Gate has any return traffic for you, it will transmit that traffic only during the central 3 minutes when the satellite is nearly overhead your station. 5) If you are using a beam antenna and can copy more of the pass, then you can signal the P-Gate to try longer in the pass by including "QRZ" in your STATUS, or by sending CUSTOM MSG 3 P-GATE OPERATIONS: Mobile-to-mobile communications works without any special considerations on the satellite or on the ground. But the more useful application is sending and receiving messages to any other APRS station via P-GATES that are monitoring the satellite downlink and serving as gateways into the world wide APRServe system. These P-GATES perform the following functions: * Monitor the downlink and capture all calls-SSID's * Monitor APRServe and capture all MESSAGES for these calls\SSIDs * Monitor the downlink and deliver the above messages at a "fair" rate under these conditions: 1) The satellite is within 1400 km (above 30 deg) to mobile 2) It sees "QRZ" in the Mobile's STATUS text 3) It sees CUSTOM-3 comment. (Easier to turn on/off) * Transmits these pending messages redundantly until it has seen at least two sucessful digipeats while the mobile is in view. BASE STATION OPERATIONS: Since UO22 and ISS are shared asset with many existing amateurs using the PACSAT protocol and File/BBS system we only want to encourage this message system for use by mobiles who have no other means to communicate from distant locations. For this reason and to minimize uplink loading, we do not encourage any base station operations other than P-GATES or for direct contact with a mobile if needed. A Mic-E style packet from the D700 is only 9 bytes long, compared to a WinAPRS station's typical 80 byte position report. These are strongly discouraged. Stations using software other than the D700, should only operate in APRS compressed mode (not yet working in WinAPRS) and minimize their STATUS text. Beams on the uplink for this applicaton are NOT desired. To use this mode, we must keep our ERP to 50 watts to an omni... or equivalent. SATELLITES: There are many 9600 baud PACSATS in orbit and on the drawing boards. These all use the PACSAT protocol which is very effecient for delivering large files to many users. Our presence on the uplink is in direct competition with others uploading to the bird. Thus, The IDEAL satellites for us are the Imaging satellites which may have megabytes on the downlink, but the uplink is relativly empty except over command and uplink stations. These command stations typically run 100 watts to 13 dBi antennas and thus have a 16dB margin over any mobile. Due to this power differential, we think the satelite assets can be reasonably shared between the two applications. Thus, UO22 has bee enabled for APRS since Nov 1999. PASS PREDICTIONS: The worst thing that can happen is if APRS mobiles choose to just park on the uplink frequency all day long. We must insure through user education that the uplink is shared by all of AMSAT for many satellite uplink and donwlinks and that uplink ONLY during a pass is acceptible. TO this end, we must distribute via the terrestrial network sufficient pass information so that travelers are aware of pass times. We have an excellent way to send special PASS INFO to all D700's and D7's that will be ignored by most other software and which will not use up precious MESSAGE memory! We do this by transmitting in the APRS RESOURCE format which will be captured in the THD7 and D700 DX LIST. Thus, our mobile satellite users can get the PASS info they need in a consistent place. THe DX spot info will display on the THD7 as a 5 field display. 4 of these fields are 10 bytes long and the 5th is 5 bytes long (It is for the ZULU time usually). Thus the format for a PASS BULLETIN (transmitted periodically all day long terrestrially might be for example: UO22 PASS SE to NW ATLANTA TUE PM @1427 UO22 PASS SE to NW DALLAS TUE PM @1603 UO22 PASS SE to NW RENO TUE PM @1735 This shows the AOS and LOS for a city that is closest to an overhead pass. Users can infer their pass times and directions from that at one minute for every 300 miles. TM-D700 SETTINGS: Here is a list of the minimum setups for the new Kenwood TM-D700 data radio for front-panel-to-Satellite mobile communications via a digipeating PACSAT, using my data as an example: APRS-MYCALL - WB4APR-3 APRS-MYPOS - 3859.11N 07629.11W APRS-STATUS TEXT - @amsat.org (My email address) APRS-STATUS RATE - 1/1 APRS-PACKET PATH - UOSAT5 <=== for UO22. Or NOCALL for ISS APRS-PACKET TX - AUTO APRS-TRANSMIT-RATE - 1 min APRS-DATA BAND - A:TX B:RX APRS-PACKET-SPEED - 9600 APRS-MSG-GROUP - Add "SATTEST" to the list so we can share msgs APRS-POSIT-LIMIT - 0 (so you dont filter out DX stations!) TNC-DISP-KEY MODE - MODE3 (so you have APRS functions handy) Tune band A to 145.900 and band B to 435.130 (doppler down to 435.110) Then SAVE as PROGRAM MEMORY #N, so you can instantly go to it next time. TRANSMITTING: In APRS mode, the Kewnood radios do not set the internal TNC to FULLDUPLEX THus, while your band B is receiveing data the radio will not transmit. Understanding this problem will be your key to success. Here are some ways to force a transmit: 1) Set to AUTO and then QSY the downlink long enough to silence rcvr 2) Set to PTT and kerchunk UHF xmtr when Posit BECN is ready... 3) Set to auto and ignore downlink. 4) Operate in PACKET mode with a laptop doing APRS (With FULLDUP ON) and operating in compressed mode. 5) Use APRStk.EXE which is a modifed version of APRSdos that tracks the satellites and only uses the APRS compressed formats for brevity.. PCSAT: Hopefully by the time you read this, PCsat will be in orbit and will be there first dedicated APRS satellite. ALl of the operations concepts above will apply. FOr info go to: http://www.ew.usna.edu/pcsat de WB4APR