OPS.txt 6.3c                APRS OPERATIONS NOTES

Version 6.0:  See the alt-IGNORE command description under the SPECIAL EVENT
section below.  It allows special events to IGNORE all other APRS traffic on
frequency to keep their screens clear for the special event stations only.


   This OPERATIONS file may help you to understand the finer points of
operating an APRS net.  It covers the two categories of operations.  ROUTINE
and SPECIAL EVENT.  Also read the section on OBJECTS since the information
there applies to both cases.  Since APRS was designed to facilitate real-
time tactical communications, operating APRS on a routine basis is sometimes
about as exciting as 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 in a crisis!

do NOT think that you need GPS for tracking special events.  With version 5.7,
it is so easy to update your vehicle's position just by moving the cursor
and hitting the INPUT MyPOS command (I M)., that the only stations that need
GPS are the ones that are lost!

BULLETINS:  To send a bulletin to all stations, simply SEND a message to 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 eventaully
settle out at once every 15 minutes.  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 bulletins by using the ALT-E command.



GATEWAY RULES:  I have interjected this paragraph because of the large number
of APRS HF to VHF gateways now in operation.  First, it is very important that
users understand that GATEWAYS ARE ONLY INTENDED TO LINK HF ACTIVITY INTO
LOCAL VHF NETS.  IT IS INNEFFICIENT, DISCOURTEOUS, AND OFTEN ILLEGAL TO LINK
from VHF to HF.  The illegality comes about if the GATEWAY is unattended.
With current hardware, a gateway sysop cannot selectively restrict the VHF
input, so it is incumbent on users to respect this deficiency and NOT put the
sysop of the gateway at risk.  Linking HF operations 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 100% BLOCK
ALL HF OPERATIONS NATIONWIDE!  The capability is there for linking special
events on VHF out for the entertainment of all HF listeners, but DO NOT ABUSE
IT, OR WE WILL LOOSE IT!  See HF.txt for suggested frequencies.


DIGIPEATER RULES:  The advantages of APRS are many, but there is a price.
Since APRS uses a fixed digipeater path sometimes different for different
stations depending on geographic location, there is a duplication of on the
air packets.  This assures that all stations in the net are maintained up to
date, but also proves to be less efficient during intense operator-to-operator
QSO's where this point-to-point traffic is still being unnecessarily broadcast
to all stations in the net.  In such cases ALWAYS CHOOSE THE MINIMUM PATH TO
THAT ONE STATION.  You will be amazed at the improvement in throughput!
Watch the DIGI page, and if you can work him direct, DO SO! 

WIDES AND COMMUTERS:  The greatest contribution of APRS is the use of generic
alias callsigns for digipeaters so that mobiles do not have to change their
paths as they move from area to area.  With all wide area digipeaters running
as WIDE, the mobile only has to digipeate via WIDE to be heard.  However,
for a guy who lives on the fringe, there is a temptation to make his home
station a WIDE also, so that as he commutes to and from home, his mobile will
use his home station as a digi.  THis solves his problem (of lack of WIDE area
coverage in his home area), but adds problems to the network.  A better
solution is to leave his home station runing as RELAY, and then to be sure
that there are RELAY stations at the other end of his commute.  THis way,
he can use the path of RELAY,WIDE.  The wide will assure wide area
distribution, but the relay will allow him to be picked up in the area of his
home base.  Ideally, TNC manufacturers should allow two ALIASES in their
digipeaters.  THen as APRS digi's, they could respond to both RELAY AND WIDE!
See DIGIs.txt.

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 be transmitted
for 6 minutes and then 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 (which I see a lot on HF),
APRS now 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!


SHORT MESSAGES:  As with any packet, especially on HF, the shorter the packet
the better the chance of getting through.  Since a packet often has about
25 characters of overhead, however, there is not much sense of making the
message part much shorter than a half line (40 characters).  The chance of
a 40 character line getting clobbered compared to a 75 character line is
65%.  On HF (under poor conditions), keep 'em short.  A neat 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 "stby".  THen I type my lengthy several line message and walk
away.  This way, only the very short "stby" line is transmitted (often
for hours on HF) until the band opens, and then once the station ACKs that
line, my remaining lines are transmitted.

     One last suggestion on HF and other poor paths that will make messages
more sensible to the receiving station is to indicate to the receiver of a
multiple line message that there are more lines to follow.  Without this, and
by sending short lines, often it is not clear to the receiver that more is
comming.  Often he tries to respond to my half sentences and then we spend
twice as much time clarifying what in the world I am trying to say!  Another
way to do it if you know how many lines you will be sending about the same
subject is to indicate what line number it is out of the total.  For example,
in a four line message, end the each line with >1/4, >2/4, >3/4, .4/4.


ROUTINE OPERATIONS:  The APRS default digipeater path of RELAY is ok for a few
users starting up an APRS net, but you will soon need to focus on a few good
stations to serve as WIDE area digipeaters.  The reason for this is obvious.
As soon as you get 3 or more local stations on APRS, any station living equi-
distant (RF wise) from two other stations will ALWAYS hear a collision of
EVERY packet digipeated by both of those stations.  That is why, once your
network begins to grow, you need to designate your path by specific callsign
and designate certain high stations as permanent digipeaters.  If you put up
a few good wide area digipeaters with the generic ALIAS of WIDE, the coverage
of the network can be extended significantly.  It is important to keep generic
WIDEs well separated (40 miles or more over smooth terrain) to minimize
duplicate repeats (or you end up with the same collison problem but on a larger
scale).  Most users should be able to hit at least one of these WIDEs.  Just
like with the RELAY's, however, users should use the specific digipeater call
instead of the generic WIDE in routine cases to minimize collisions.  You may
store up to 13 different, frequently used DIGI paths for instant recall to
tailor your DIGI path for the exact calls and path for each QSO.  Proper use
of this capability can significantly improve APRS effeciency and reduce the
use of the WIDE,WIDE generic path!

   All users must understand that they are responsible for setting their
outgoing VIA path so that their packets hit the intended area of interest.
Unlike normal CONNECTED protocols which automatically return ACKS via the
reverse path of incomming packets, 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.


    APRS has a very useful feature for determining the best path between
stations.  The Power-Height-Gain reporting capability lets APRS plot range
contours around all stations that have included the P-H-G data in their
position reports.  For maximum effectiveness, every station should use the
INPUT-PWR command to enter his transmitter power, antenna height, and antenna
gain.  Also APRS permanent digipeaters should include this info in their
position beacons.  See DIGIs.txt for the exact formats.

    Those stations between WIDE area digipeaters only need to use the single
hop of WIDE and their packets will go in both directions.  Stations that can
only hit one WIDE area station may set the path of WIDE,WIDE without any
conflicts.  Paths of WIDE,WIDE,WIDE should be avoided for routine operations
because it folds back on itself.  The same area can be covered by using
WIDE,WIDE,W3XYZ where the unique call of the third digipeater is specifically
specified.  If you think about it, stations at the end of an area can specify
a pretty long string of digipeaters since the path is linear.  Stations in
the middle can only specify a symetrical double hop with WIDE,WIDE before
they have to begin favoring one direction or another with unique calls.

CAUTIONS ABOUT APRS MESSAGES:  Remember that the general condemnation of
multiple digipeater hops in the packet community applies only to connected
protocols.  This is because the probability of success goes down drastically
because all ACKS must be successfully returned or all packets are repeated.
This is generally NOT a problem with most APRS operations since only UI frames
are used, and there are no acks.  HOWEVER, APRS one-line MSGS are ACKED, and
the inefficiency of digipeaters 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.  (As noted above, in version 503a,
APRS doubles up on ACKS on a poor channel and helps this situation somewhat.)
But, in general, NEVER expect an APRS MSG to be successful beyond 2 digi's
except if everyone else is DEAD.  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 BLUE-BOXED prompt, never linger in a blue-box prompt.
The SEND command is a BLUE-BOXED prompt and should not be left un-completed!

OBJECTS:  As noted previously, anyone may place an object on the map and all
other stations will see it.  In their systems, on their P-list, the object's
position report will be marked with the last three letters of the station
that is currently uplinking that position to the net.  A neat feature of APRS
is that any station that has more current information on the location of that
object can update its position by hooking, moving the cursor, and then
hitting the insert key.  Now this new station begins uplinking the new posit,
and all stations, will update their P-list entry for that object INCLUDING
THE ORIGINAL UPLINK STATION!  The new position overwrites the old one so that
the original station will now no longer uplink it.  This came in handy during
hurricane tracking.  Who ever had information on the latest NWS EMILY
position, uplinked it and everyone then always saw the latest storm track
without anyone in the net being dependent on any one station for updates!

     Once objects are transmitted on to other station map screens, they will
remain there until that operator deletes them.  Even if the original station
stops sending the object position, it will remain there forever.  Once the
object or station has not been heard from for 2 hours, it will fade to gray
so that you know it is an old contact.  In version 4.01 a feature was added
so that you can suppress the callsigns of old contacts.  Just press the J
command, and select LATEST instead of selecting any specific object type.
The result will be to redraw the map showing ALL symbols, but only the calls
of the recent ACITVE stations less than 2 hours old.   Another feature added
recently is the KILL function.  This permits the uplinker of an OBJECT to
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 4 minutes to be sure everyone has received the KILL indicator;
then he can delete it from his list.


SPECIAL EVENT OPERATIONS:
   
    The alt-IGNORE command sets up an APRS station to send via the UNPROTO
address of SPCL... vice APRS...  It also sets up that station to IGNORE all
other packets.  This allows the event participants to keep their screens
(P/L lists, etc) clear of unwanted other APRS stations on frequency, while
tracking the event normally.  All other stations watching the event will still
receive all SPCL event posits on their screens, and they will be automatically
marked with the # for special display using the # key vice SPACE bar.

SPECIAL EVENTS:  Let me use the Cycle Across Maryland (CAM) bike tour as an
example of a special event which took a lot of daily APRS coordination.  We
had two of three relief vehicles configured with GPS packet transponders.
These were assembled in cake pan enclosures for duct-taping to the roof of
any vehicle.  The uside down cake pans are reasonably aerodynamic and support
both the GPS antenna and a 19 inch 2 meter whip.  A single power cable
extended down the windshield and was clipped directly to the vehicle battery.
The package could be moved to another vehicle in about five minutes.  The
cake pan included only a walkie talkie transmitter at about the one watt
level.  Other packet mobiles running APRS did not even need their GPS units
since with the map on their laptop, they can just use the INPUT-MyPOS command
at any time to update their positions to the network.  In this manner, my
normal APRS/GPS combo can be split into TWO separate tracked vehicles for an
event.  THe GPS/TNC combo as a stand-alone tracker, and my laptop and another
TNC only for showing people where I am.

    Since we only have two WIDE area APRS digipeaters in the state, and the
CAM tour never went near them, we were dependent on home stations all across
the state to serve as digipeaters for the event.  The GPS packages were set
to digipeat via the WIDE,WIDE path.  By setting the alias of all home
stations along the route to be WIDE, the vehicles were never beyond range of
at least one WIDE station.  Since the outgoing GPS packets were set up for
WIDE,WIDE, the second digipeat was always picked up by one of the existing
permanent WIDE digipeaters so that stations throughout the state could see
the position of the one watt GPS units!  We were looking for home stations
about every 10 miles.  Of course, as soon as a station was passed and was no
longer in direct contact with the GPS units, it was IMPORTANT to remove the
WIDE alias to minimize duplicative repeats.  For this seven day event, home
stations were organized on a nightly basis.  Assigned stations would be WIDE
for a whole day so that operators did not have to be home during working
hours.

     As an added technique, we also set up both GPS units with the alias
of WIDE so that they would also help digipreat each other along the trail.
The disdavantage of this technique was evident as both vehicles returned to
the evenings command post (also WIDE) and you had three WIDE digipeaters in
100 yards of each other!  It was noisy within local simplex range of that
site, but stations all over the state still saw the packets via the permanent
WIDE digipeaters.  Eighty percent of the home stations used as WIDE
digipeaters had never even heard of APRS.  They simply heard about the need
for home packet stations and only had to change their ALIAS (and frequency)
as directed by local announcements posted on all area BBS's.

     The event was an exciting success!  Occasionaly there were not enough
HAM voice operators per day to have HAMS in all of the relief vehicles.  When
ever a shortage occurred, the HAMS were removed from the GPS vehicles and
assigned elsewhere.  The location of the GPS vehicles were always known by
net control via the APRS system so the need for a HAM rider was not necessary
and in fact, only took up valuable space.  Whenever voice communications were
needed with the GPS relief vehicle, a mobile HAM was directed to the location
indicated on the APRS screen.

SYMBOLS:  During the 94 MS Bikethon in Northern Virginia, KD4SJJ noticed that
with four GPS mobiles and several fixed stations along the route, that there
were so many callsigns that you could not see the map.  He suggested making
several numbered symbols so that all stations could be distinguished even
with CALLSIGNS off!  This was such a good idea, that not only did we make
lettered balls (A-J) for the mobiles, but we also made square boxes 0-9 for
the fixed stations!  With these tactical symbols, and callsigns off, the map
display is improved by an order of magnitude.  Also added in 5.03a were an
additional 7 different mobile symbols for various vehicle types!

EMISSION CONTROL:  If there are only a few APRS stations involved in an event
but there are lots of APRS observers on frequency, then the observers can set
their transmitter off using the CONTROLS-X command.  That way they minimize
QRM on channel.  While the transmit function is disabled, a one-time
transmission can be forced each time the X key is pressed.  The X key
enables one cycle of APRS transmission which may contain up to four packets
containing your Beacon, Position, Objects, or Messages.  You can send only
your MESSAGES by simply hitting the T (TRAFFIC) key once.

LOAD SHARING:  Since any station can take over reporting of any objects, one
approach is to let only one station hook 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!


MARINE CORPS MARATHON:  See the MARATHON.txt for details and lessons learned
using APRS at the Marine Corps Marathon on 24 October in Washington DC.


RACES AND EMERGENCY OPERATIONS CENTERS:  Dont overlook the fact, that a
handful of separate PC computers can ALL BE CONNECTED TO A SINGLE TNC AND
RADIO!  This fact can be used to create quite an impressive multi-station
tactcal communications system that will rival some 911 consoles!  For now
(im working on a slave mode in version 6.4) just designate one console as the
APRS operator connected to the TNC in the normal fashion.  Then connect all
other consoles to just ground and RXD comming out of the TNC.  THis way ALL
consoles see the tactical picture, and these SLAVE 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 any 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.

     So just prepare your serial cable between the main APRS PC and the TNC
to have several RCV only cables attached, and string them out throughout the
EOC to any spare PC's in the building.  That way, anyone at those PC's has
INDEPENDENT access to all of the APRS info without bothering the APRS
operator who is currsoring around like mad just trying to keep up with the
traffic.  Remember that these RCV only cables can be simply 2 conductor
radio shack miniature zip cord.  You can carry hundreds of feet of this stuff
inthe briefcase with your portable laptop!

NOTE, that only the APRS operator can introduce information into the APRS
network (on the air) and that the slaves are just info access terminals to
give other personnel access to that info.  To make a true multiple console
system, I need to define a SLAVE mode that does the following.
   1) It turns off the automatic rejection of MY packets, so that all
      consoles can use the same EOC callsign, but still monitor what other
      consoles under the same call are doing.
   2) I have to implement a RTS/CTS hardware handshaking BUSY signal, so that
      only one CONSOLE is sending to the TNC at a time.
Until I do these, however, the multiple console concept is a very powerful
tool for allowing all of the EOC operators instant access to APRS displays.

