OPS.TXT           APRS OPERATIONS NOTES
Document version: 8.6.7 1 Dec 2003 Previous was 8.3.4 of 7 Mar 99
Author(s):        Bob Bruninga, WB4APR
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

FOR a general APRS overview see APRS.txt.
FOR MOBILE Operations, see MOBILE.txt
For operations with ALiases or MARS see ALIASES.TXT or MARS.TXT
FOR HF Operations, see HF.txt
FOR an APRS command summary see HELP.txt
FOR multi-PC operations on a piece of ZIP cord, see ZIP-LAN.txt

OVERVIEW:  This OPERATIONS file may help you to understand the finer
points of operating an APRS net both ROUTINE and SPECIAL EVENT.  Since
APRS was designed to facilitate real-time tactical communications,
operating APRS on a routine basis is sometimes like watching the grass
grow!  The reason for building a routine APRS net is primarily for
operator training and familiarity.  If your operators are not familiar
with APRS in a benign environment, then they will not be able to use it
under stress!

Although APRS is desiged for local real-time operations under stress, 
it does extend worldwide via the IGate system.  Using APRS on-line
lets you see any of the 30 thousand or so other stations.  On RF,
although you only see your local RF area, you can still keyboard with
anyone on the globe because of teh automatic linking of the IGates.
And if you are in message QSO with a distant station, the local IGate
will send you a courtesy position report of the distant station.

Again, the worldwide aspect of APRS is only there to give you something
to practice with.  This is not the design objective.  SImilarly, GPS is
a powerful tool linked to APRS.  But, do not think that you need GPS for 
tracking special events.  It is so easy to update your vehicle's position 
just by moving the cursor on your map and hitting the INPUT-MY command, 
that the only stations that need GPS are the ones that are lost!

Use APRSmax for routine FIXED station operations to see more stations.

Use APRSdos when all commands are needed and fewer stations are needed.

DIGIPEATER RULES:  APRS typically uses a fixed general path such as WIDE2-2
to cover a large local area with redundancy and repetition to assure that
all stations can see everything.  But this is not efficient for point to
point messages because it floods packets everywhere.  For messages it is
best to CHOOSE a SPECIFIC PATH TO THAT ONE STATION.  Your messages will
go faster and will be less QRM to others.  Watch the DIGI page, and if
you can work him direct, DO SO!

DIGIPEATERS AND MOBILES:  The greatest advantage of APRS is in the use of
generic alias digipeater paths so that mobiles do not have to change
their paths as they move from area to area.  In the 7 high density
areas in the USA, WIDE2-2 is recommended to cut congestion.  WIDE3-3
should only be used far away from these metro areas.

FILL-IN DIGIS:  Occassionally, a mobile needs some help getting out of
an area and so he can use the path of WIDE1-1,WIDE2-1 to digipeat via
a local home station set to WIDE1-1.  ANy TNC can serve as a WIDE1-1
digi.  See PATHS.TXT and DIGIs.txt.  FIXED stations should NOT use
WIDE1-1 to avoid QRM.

See DIGIS.TXT and PATHS.TXT.

THE NEW-N PARADIGM:  A great effort was made starting in 2004 to
get rid of old legacy paths of RELAY, WIDE and TRACE.  Now only WIDEn-N
is supported since it is much more efficient at eliminating dupes.
It is important to keep digipeaters well separated to minimize
duplicate repeats.

ALTERNATE PATHS:  In APRSdos prior to version 860, you could store up to
12 different, frequently used DIGI paths using the OPS-DIGI command for
instant recall to tailor your DIGI path for the exact calls and path for
effeciency each QSO.  But under the new N-N Paradigm of 2003, and use
of WIDEn-N and SSn-N, multiple paths are not required.

The following paths are reasonable under the circumstances shown:

   WIDE2-2       - Default.  Good starting place to see whats out there
   WIDE3-3       - in rural areas
   WIDE1-1,WIDE2-2 - May be needed in some remote areas for mobiles.


The following paths are NOT considered good practice and should not
normally be used... and if you do, some Do-gooder will fuss at you...

   xxxx,WIDE1-1,...- Never putWIDE1-1 anywhere other than the first hop!
                     You may key up every station in hundreds of miles!

   WIDEn-N,GATE    - QRMs the HF net which you cannot hear!

   ...GATE,GATE,WIDEn-N - QRMs every APRS net in the country!


HOW ACKS WORK (or dont work):  Users must understand that they are
responsible for setting their outgoing VIA path so that their packets
hit the intended area of interest.  APRS is an unconnected broadcast
protocol only and each station's packets will only go via the outgoing
path set up by that station.  If your station receives a duplicate APRS
MSG packet more than twice, it gives you a beep and an alert that your
ACK's are probably not being heard by the other station and that you
should check your outgoing VIA path to make sure it gets to the sender.

APRS helps you determine the best path between stations using the Power-
Height-Gain data in each position report that plots range contours around
all stations. Of course, Height here is height above AVERAGE TERRAIN,
not above sealevel or tower height!  If you do not understand the
difference, ASK!     See DIGIs.txt for the format.

CAUTIONS ABOUT APRS MESSAGES:  Remember that multiple digipeater hops has
long been condemned in the packet community because the probability of
success for CONNECTED packets goes down drastically because all ACKS must
be successfully returned or packets get re-tried over and over.

This is generally NOT a problem with APRS operations which use UI
frames without acks.  HOWEVER, APRS one-line MSGS are ACKED, and the
inefficiency of multi-hops DOES APPLY!  If you do a lot of one-line
messages between operators, you will experience the same hopeless
probabilities of success as with conventional packet.  But, in general,
NEVER expect an APRS MSG to be successful beyond 2 digi's except if
everyone else is off the air!  Operator messages are a secondary
function of APRS, and should not be used as a primary means of passing
traffic!

One further caution, since APRS suspends all packet processing while
waiting for the operator with a BOXED prompt, never linger in a prompt.
The SEND command is a BOXED prompt and should not be left un-completed!

ACKS THAT DONT MAKE IT:  Just like connected packet, the chance of a
message packet getting through is usually the same as the chance that
the ACK will get back.  If the radio path is only 50%, that means that
the receiver will probably get the message by the second transmission,
but that the sender may not get an ACK until after his 4th!  This is
because the sender had to send 4 packets to get two through and the
receiver then ACKed twice in order to get one through.  You see this
effect frequently on APRS, when you are talking with a station over a
long poor path.  You will notice that the person at the other end has
already responded to your message even before you get an ack from your
outgoing message.  BUT your next line will never go out UNTIL it gets
that ACK.  The reason that you will probably get his response message
before your ack, is because his response message is being repeated over
and over in the usual APRS decayed algorithm, but his ACK is ONLY
transmitted once each time he gets a dupe of your message line to him.

What this means is that whenever it is obvious that the other station
has responded to your message line, you should ERASE it so that APRS
will move on to the next line.  Sometimes if you know that the other
station is probably hearing the digi better than the digi is hearing
him, and you are not getting ACKS, then simply send him messages in
the blind.  Let each line will be transmitted for 6 minutes and then
you can erase it.  APRS will then move on to the next line.  Remember
that APRS will have transmitted 6 times in the first 6 minutes, but
that it will then be over 3 minutes, then 6 and then 12 minutes for
further transmissions.

To improve on this effect of lost ACK responses, APRSdos recognizes a
duplicate message, and not only sends out the usual ACK, but stores a
copy for transmisssion in the blind 30 seconds later.  The 30 second
delay is to avoid cluttering up the frequency if the path is good, since
the sending station will have sent the message at least twice in the
first 30 seconds.  After the third transmission, it is clear that the
ACKs are getting lost and it is time to double up. This algorithm has
the potential of doubling throughput on a poor channel!

REPLY ACK:  In the year 2000 time frame, APRS added embedded ACKS
in reply messages so that for only 2 more bytes in a message in a dialog
between 2 users, an extra ACK gets a free ride.  This vastly improves
the reliability of ACKS in a dialog.  Only APRSdos and a few other
versions have implemented this, but between those stations, combined
with the APRSdos decaying retry algorithm results in an ORDER OF
MAGNITUDE faster message dialog than other client software that does
not use these two fundamental communications techniques.

SHORT MESSAGES:  Especially on HF, the shorter the packet the better.
With 25 characters of overhead, however, there is not much sense in
making the message part much shorter than a half line (40 characters).
A trick that I frequently use whenever I know that
a station is not currently on the air, or the path is not currently good,
is to send the first message line with only the word "test" followed by
additional lines with the body of the message.  This way, only the very
short "test" line is transmitted (often for hours on HF) until the band
opens, and then once the station ACKs that line, the remaining lines
are transmitted.

BULLETINS:  Bulletins are sent to the callsign of BLN# where # is a
line number from 1 to 9.  Like any other message, these
BULLETIN lines will be transmitted on the decaying time period and will
soon fade out of the system.  If you want the bulletin to remain at about
a 15 minute rate, then instead of using numerals in the BLN# mesage, use
a LETTER.  This way, new stations joining the net will quickly pick up
the BULLETINS.  Since lines are sorted onto the receiver's BULLETIN page,
a new BLNx line will overwrite any previous BLNx at all stations making
changes and corrections easy.  If your bulletin is time sensitive, be
sure to include the TIME in the text, since BULLETINS are not time-
stamped.  When your BULLETIN is no longer needed, simply ERASE your
outgoing BLN#.  This will stop your transmission of the BULLETIN lines.
Receiving stations can erase all old bulletins by using the ALT-E command.


GATEWAY RULES:  It is very important that users understand that HF
GATEWAYS ARE ONLY INTENDED TO LINK HF ACTIVITY INTO LOCAL VHF NETS.
NOT THE REVERSE!

IT IS INNEFFICIENT, DISCOURTEOUS, AND MAYBE ILLEGAL TO LINK from VHF to HF.
Linking HF into every local VHF APRS net in the country is not a problem,
because the slow 300 baud data rate could never saturate ANY 1200 baud
local net.  HOWEVER, linking just ONE active VHF net ANYWHERE in the
country out onto HF WOULD CERTAINLY BLOCK ALL HF OPERATIONS NATIONWIDE!
DO NOT ABUSE IT, OR WE WILL LOOSE IT!  See HF.txt.

GATE SUMMARY:  On HF, use the path of GATE,WIDE2-1 and everyone in the
country within one hop of a GATE will likely see you.  *Never*
use GATE,WIDE2-2 or greater because your packets will now go 2 or more
hops on VHF and be seen MULTIPLE times from multiple gates!  No one can
tell where the GATE is and it is just a BIG MESS.  Believe me!

Second, never routinely go through a GATE on VHF to HF.


USING THE OPS-COMM-TNC dumb terminal mode.  Learn to use your TNC
in conventional connected mode and use that mode for point-toppoint
messaging and files and on a different frequency.

OBJECTS:  Anyone may place an object on the map for all to see and on
the P-List the packet is marked with the last three letters of the
originating station.  Any other station that has more current
information on that object can also update its position by SELECTing,
moving the cursor, and then hitting the insert key.  His station will
begin uplinking the new posit, and all stations, will update their
P-list entry for that object INCLUDING THE ORIGINAL UPLINK STATION!
Since the new position overwrites the old one, the original originating
station will now no longer uplink it.  Thus we are not dependent on
the original station for future updates.

Old objects no longer being uplinked by anyone will fade to dark gray
after 80 minutes to show they are old.  Use the CONTROLS-FADE command
to bring them back to bright colors, or use the J command to see JUST-
the-LATEST symbols.  The KILL function permits the originator of an
OBJECT KILL it from all displays on the net.  His station will continue
to uplink the object, but tagged with a special KILL flag to suppress
its display on all screens.  It remains in everyone's P-lists, though,
so they can refer back to it if needed.  They must still manually DELete
it from their P-list as needed.  Once the originator has KILLED an object,
he should let it remain on his P-list for at least 6 minutes to be sure
everyone has received the KILL indicator; then he can delete it from his
list.


NEAT OPERATOR FEATURES:

CONTROLS MENU:  Set filters and how you want packets displayed.
MAPS:           Turn on or off map features plus overlay data files
                on the maps such as DIGIS, Radio Shacks, etc
RADAR ALARMS:   Use INPUT-MY-RADAR to set your"airspace".
POSIT ALARMS:   Set ALARMS on any mobile which will alarm if he moves.
WX ALARMS:      Set Weather alarms on temps, winds or rain...
TRACK MODE:     Lock on to one station and keep map centered
SPECIAL MARKS:  Mark any station on the P-LIST for SPECIAL highlighting
                Then you can see only those stations with JUST-S



SPECIAL EVENT OPERATIONS:

    The alt-SETUP-MODES-SPECIAL command sets up an APRS station to send
TO the UNPROTO address of SPCL... and to ignore all other packets NOT
addressed to SPCL.  This allows the event participants to keep their
screens and lists clear of unwanted data while tracking the event
normally.  But all other stations watching the event will still receive
all SPCL event packets normally.  But they will also be marked with
the # for special display using the JUST-SPECIAL command or SPACE bar.

SYMBOLS:  APRS now permits HUNDREDS of different mobile symbols by using 
the NUMERIC OVERLAY capability.  This makes it easy to distinguish
mobiles even with CALLSIGNS-OFF to reduce clutter!

EMISSION CONTROL:  Observers of an event can set their transmitter off
using the CONTROLS-X command to minimize QRM on channel.  They can still
transmit under manual control by using the X key.


LOAD SHARING:  Since any station can take over reporting of any objects,
one approach is to let only one station SELECT every symbol that comes in
and then he becomes the reporting repsonsibility.  The original station
that uplinked the report in the first place will fall silent when it sees
the report comming from the designated Net Control station.  This way all
positions are reported by only one station on frequency, although all
other stations can still update the positions as needed.  Remember that
the last station to report the position of an object will be the one
that continues to report it!  APRSdos has a NET-CONTROL feature for
OBJECTS that automates this process.


MARINE CORPS MARATHON:  See MARATHON.txt for the lessons learned.


ZIP_LAN MODE AND EMERGENCY OPERATIONS CENTERS:  Dont overlook, that a
handful of separate PC computers can ALL BE CONNECTED TO A SINGLE TNC AND
RADIO!  The ZIP-LAN can be used to create quite an impressive multi-station
tactcal communications system that will rival some 911 consoles! No
special LAN hardware is required other than a serial port and as much
two conductor zip cord as you need.  See ZIP-LAN.txt

This ZIP-LAN capability is not backwards compatible to any
software prior to APRS800, Mac/Win prior to 2.09 and APRSa4 ver 0408.

With a ZIP-LAN, ALL consoles see the tactical picture, and these PC's
are at the individual operator's disposal to zoom in, and hop from screen
to screen to give them access to what ever info they need!  Do not think
that a big screen display is better.  A single big screen is impressive,
but actually useless.  Only the person at the KEYBOARD of an APRS system
can actually get useful info from APRS.  In our county, you need to be
below the 8 mile scale to get an idea of what is going on at a crisis,
and while you are zoomed in there, others need to be focusing on other
parts of the county, or different screens.

You can wire every PC in the building using cheap 2 conductor speaker
ZIP cord!  You can carry hundreds of feet of this stuff in your briefcase
with your portable laptop!

This is a TREMENDOUS capability, since these days PC's are much more
plentiful than TNC's and all available assets can be brought into the
picture.  Every SLAVE operator has his own INDEPENDENT access to all
of the APRS info without bothering the APRS operator.

See ZIP-LAN.TXT

de WB4APR, Bob
