HAM Radio 1/HamRadio.cdr/swl/swlguid2/sarex2.txt

Text File | 1990-08-21 | 4.0 KB | 66 lines

SAREX Packet Hints

You learn very quickly when venturing into the world of Packet Radio that
unless you use the correct call sign when attempting to connect to another
packet station, you won't get too far.  Such is the case with the packet
operation on SAREX.  A number of publications reported earlier this year that
the SSID for the SAREX packet ROBOT would be = 1 (ie: WA4SIR-1).  Tom Clark,
W3IWI, reports that both the HK21 ROBOT TNC and the operational software for
the GRID laptop computer have the calls defaulted to WA4SIR (SSID = 0) and
that call should be used unless, for some unanticipated reason, the defaults
are over-ridden.  Tom continues, the best advice is for you to MONITOR the
downlink signals from STS-35 and use whatever call you see on the downlink.
The ROBOT TNC code uses only one SSID at a time.

Because the WA4SIR SAREX ROBOT will be bombarded with signals from tens or
hundreds of ground-based users when STS-35 is flying over populated areas, it
is not possible for the ROBOT TNC and radio to use normal half-duplex packet
procedures -- the CD (carrier detect) signal will simply never drop!  The ROBOT
will be running in a modified full-duplex mode.  When the ROBOT copies a valid
packet frame (or when it is time to send a beacon), the data to be sent is put
into a buffer and a timer (which is called the FUDtimer) is started.  The ROBOT
firmware then queues all other outgoing transmissions in the buffer until
FUDtimer expires (3 seconds later), and all downlink frames in the queue are
sent in one long transmission.  You may discover that the response time while
running in this mode is sluggish when compared to normal packet operation.

Since the SAREX handheld radio cannot receive when it is transmitting, users
should insure that they remain silent and listen when the shuttle is
transmitting.  In other words, DO NOT RUN FULL DUPLEX ON THE GROUND!  Leave
your TNC in half-duplex mode (FULLDUP OFF) with CD active just like you do for
normal VHF packet operations.

You should be careful with the setting of two of your TNC's timers: DWAIT and
FRACK.  DWAIT is the time interval after your Carrier Detect light goes out and
before your transmitter turns on.  You want to make sure your connects requests
and acks are contained in the 3 second FUDtimer window.  If everybody runs the
same DWAIT (like the typical 0.1 - 0.5 second values used for terrestrial
packet), then everybody will be transmitting at the same time. Part of the key
to your success when uplink QRM is heavy is to pick a DWAIT that nobody else is
using! (sort of like picking a lottery number!)

FRACK sets the time interval between your transmissions.  After you send a
frame, your TNC waits for the FRACK time, and then waits for the Carrier Detect
signal to drop, then waits DWAIT, and then tries again.  You should make sure
your FRACK is at least 3 seconds so that you are not transmitting when the
ROBOT's FUDtimer decides it is time for it to transmit -- if you are
transmitting at the same time, you will miss any packets the shuttle is
addressing to you and you won't have a successful QSO.

Note that your DWAIT (how soon do I transmit?) and FRACK (then how long do I
wait?) parameters and the need to stop transmitting so you can hear a reply are
just like you encounter when working a DXpedition pileup on HF.  If the DX
station has a pattern of listening for a few seconds (=FUDtimer) before
transmitting, you may have better luck being the LAST station they hear, after
the din dies down.  The differences are that (1) the ROBOT is a computer and is
very predictable and (2) the ROBOT can be working several stations at one time.

       [ANS thanks W3IWI for compiling the information for this bulletin]

Note:  As of press time, STS-35 is scheduled for launch around September 1st.
(... but to paraphrase Yogi Berra  "... in ain't orbiting 'til its orbiting".
ANS will provide additional news on the STS-35 Astro-1 Mission as it becomes
available.