       ASTARS, an APRS SATELLITE TRACKING AND REPORTING SYSTEM
                       Bob Bruninga, WB4APR

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 and SAREX.  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 paper will describe 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 
distriubte 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 2 minutes 
      or less of an overhead pass on an omni mobile whip.

  3)  Longer pass times are possible with a cumbersome 4 ele beam.

  3)  Such overhead passes only occur once or twice in the morning 
      and the evening 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 2 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 the satellite is a 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.


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.

   To this end have an excellent way to send special PASS INFO 
to all D700'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
 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..

