DP Tool Club 24/CD_ASCQ_24_0995.iso/vrac/aprs72a.zip/README/OPS.TXT

Text File | 1995-07-22 | 22KB | 345 lines

OPS.txt 6.7b                APRS OPERATIONS NOTES

Version 6.7b: Includes a SLAVE mode for operating several different APRS PC's
all from the same TNC/radio.  This permits multiple operators in an EOC or
other command post, to each have his OWN display, while sharing only one
radio /TNC.  See SLAVE paragraph at end.


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 in a crisis!

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 and hitting
the INPUT-MY command, 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 20 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
old 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
MAYBE ILLEGAL TO LINK from VHF to HF.  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 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.


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 also 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!

WIDE-RELAYS 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.  Since WIDES are widely
separated and are made for WIDE area and LONGHAUL comms, many mobiles cannot
hit them reliably.  The ultimate solution was discovered at Dayton 1995
where it was pointed out that many TNC's have alternate callsign functions
that will also digipeat.  By making all WIDE digipeaters ALSO have an alias
of RELAY as well as WIDE, the mobiles only need to set their initial digi
path to RELAY,WIDE,... and they will be digipeated no matter whether they
are near a WIDE or out in the boonies near any other APRS station (all APRS
stations have the defualt alias of RELAY)  Ideally, other TNC manufacturers
should allow TWO aliases in their digipeaters.   See DIGIs.txt.  FIXED
stations should NOT use generic paths if they can avoid it.

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 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.  With 25 characters of overhead,
however, there is not much sense in 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 keep 'em short.
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.


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 any 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 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 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 and PROTOCOL.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 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, 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 BOXED prompt, never linger in a prompt.  The SEND
command is a 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.  On their P-list, the object will be 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 hooking, 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.  This comes in handy during
hurricane tracking.  Who ever has information on the latest HURICANE posit
uplinks it and everyone then always sees 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 originator stops
transmitting them.  It will, however, fade to dark gray after 2 hours to
show it as an old report.  You can 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.


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:  The Cycle Across Maryland (CAM) bike tour is a good example
of a special event using APRS.  We had two of three relief vehicles with
GPS trackers.  These were assembled in cake pan enclosures duct-taped to
the roof with a small power cable extended down the windshield and clipped
directly to the battery.  These packages could be moved among vehicles in
about five minutes.  Some other packet mobiles ran APRS without GPS units
by just using the INPUT-MyPOS command to update their positions.  In this
manner, my normal APRS/GPS combo can be split into TWO separate tracked
vehicles for an event.  The GPS/TNC combo acts as a stand-alone tracker,
and my laptop and another TNC keep my vehicle on the map manually.

    Since we only have two WIDE-RELAY 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 RELAY,WIDE path.  By setting the alias of home
stations along the route to RELAY as the event came near, the vehicles
were never beyond range of at least one RELAY station.  These home stations
then digipeated the positions on to the established WIDE digipeaters.  Due
to the short range of our simple 1 watt units, we needed home stations
about every 10 miles.  This combination of RELAYS and WIDEs shows how
valuable these generic callsigns are.

     As an added technique, we also set up both GPS units with the alias
of RELAY 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 RELAY) and you had three RELAYS 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.

     The event was an exciting success!  Even when there were no HAMS in the
GPS vehicles, their locations were always known by net control.  If comms
were needed with the GPS relief vehicle, a mobile HAM was directed to the
location indicated on the APRS screen.

SYMBOLS:  During a 1994 MS Bikethon, KD4SJJ noticed that the map got to
cluttered with four GPS mobiles and several fixed stations along the route.
As a result, APRS now has several lettered ball symbols and numbered boxes
in addition of a dozen other mobile symbols that can be distinguished even
with CALLSIGNS off!  With these tactical symbols, and callsigns off, the
map display is significantly improved under congested conditions.

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.  They can still transmit under manual control by using the
X key.  The X key now prompts you for which packet you want to transmit,
Beacon, Position, Objects, Messages or all.


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.


SLAVE MODE 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!  By having
each PC operating under the SAME callsign, the TNC will not know or care
which PC is sending data, and all monitored data will be fed in parallel
to all consoles at the same time!  The slave consoles will see the MASTER
console data after it is digipeated.  To make this work, you must set the
PC's in the MASTER and SLAVE modes using the alt-SETUP-MODES commands.
In these modes, APRS will accept digipeated packets from
itself (in this case, other PCs sharing the same TNC) and will see any
objects, posted by the other SLAVE consoles.  The MASTER remains fully
functional, but the slaves act as follows:
   Slaves do NOT send BEACONS or POSITS (would be dupes of master)
   Slaves do NOT send MESSAGES (the ACKs wouldnt work due to same calls)
   Slaves CAN send BULLETINS (since no ACKS are required)
   Slaves CAN send OBJECTS (assign each operator to track different objs
   Slaves will see the MASTER messages on the READ-MAIL screen

   To connect all the PC's to the TNC, use 3 conductor cable with only
RXD, TXD and ground.  Connect all grounds and all RXD's to the TNC.
Then DIODE-OR all of the TXD's together to the TXD line of the TNC via
a diode with a 15K or more bypass resistor.  You may want to include a
switch in the TXD line so that the MASTER station has control of who
can enter OBJECTS into the system.  So that all these PC's see the same
data, there MUST be a digipeater on the net.  (AEA TNC's have a command
called MXmit which can be turned on to echo all transmitted packets as
if they were digipeated from a digipeater).

   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 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.

     At the master APRS PC, you may want to have ON/OFF switches for each
of the SLAVE PC TXD lines so that you can control who is permitted to
enter OBJECTS into the net.  Even without TXD, all SLAVE APRS PC's still
provide each individual operator the full APRS tactical picture!  If you
only need one console for entering data, then 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 the 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.