[aprssig] APRS as a Situational Awareness tool

[Robert Bruninga]

> APRS is billed as a situational awareness service, 
> yet the map is largely barren of situational 
> awareness information.  I ask myself "why?" 

My opinion why APRS is not used for real situations:

1) APRS has been presented incorrectly by far too many people as
a vehicle tracking system (transmit) as opposed to an
information resource.

2) The 5% of a club that does APRS has not fully realized that
their job is INFORMATION INPUT (objects, messages, and
bulletins)

3) The poor implementation of objects in some clients kills the
channel when used for inputing lots of objects, defeating the
primary mission of APRS.

APRS was designed around the assumption that APRS would not be
used by very many members of a club, and very few devices could
actually report their own position.  The design assumption was
that manual entry of large numbers of objects would be a major
function of APRS inorder to fully represent the situation.  

Fundamental to this plan was that New objects, moved objects, or
deleted objects were re-tried in 8, then 16, then 32 seconds,
then 1 minute, 2  minutes, 4, 8 and so on down to a final 10
minutes if it was a local event or 30 minutes if it was a long
term regional event.  This made the map very reliable and up-to
date whenever any object was added, moved, changed or deleted.
The map had basically 3 retries at being current up to the
MINUTE!

The idea was that APRS users would respond to an emergency if
they have the time and are in the right situation.  

A) As steve points out, if an APRS operator is in the middle of
it he has too much else to do.  But if he can, he should put out
a packet showing where he is, his status or needs, and his
operating voice frequency for contact.  Then attend to other
things.

B) Those APRS volunteers that are out of area but can monitor
the situation, should put on headphones and LISTEN to nets or
other data sources.  Every fact, operator, station, location,
position, object, situation, fire, wreck, that is overheard ONCE
should be put on the APRS map.  THIS is what APRS was designed
to do.  It was supposed to be EVERYONE contributing all their
small bits of the pie onto the ONE area situational APRS display
resource that can be viewed by everyone at their own needed and
focused scale. (Think: a zoomable APRS situational display in
front of every EOC operating position).

C) What killed (B) however is the very poor implementation of
objects in most follow-on clients.  Uiview transmits all objects
(Old, and new) at exactly the same rate and all at the same time
in one huge block.  This generates an order of magnitude too
many packets for the need, clobbers the network for a full 30
seconds at a time for 30 objects, blocks most digipeats of those
objects, and either has too much time lag or too much QRM to be
of real value.

It is self defeating to use APRS as intended (managing dozens
and dozens of objects) using Uiview as the data entry station.
HOWEVER, there are work arounds as long as everyone is mindful
of these limitations.

1) Establish only a properly implemented APRS client as the
OBJECT manager.  This station rapidly refreshs new info, decays
old info, and randomizes the transmission of each object
independently so that none are transmitted in big wall-to-wall
blocks that self-distruct their own digipeats and block other
users for long periods.

2) Have operators trained on this system to take-over any object
posted by a Uiview station.  If this station has good ears or a
high location, it has another advantage of better use of CSMA in
the situation area to minimize collisions too because it can
hear more.

3) If #1 and #2 are implemented, then Uiview can be used freely
and purposefully by everyone to input any objects that are
needed.  This works because the #1 OBJECT-station takes them
over as soon as they appear.  This usurps these objects from
Uiview and eliminates all of the channel problems caused by it. 

Because taking-over-objects was fundamental to the APRS design,
all of the above can occur transparently to the Uiview users.
He does not even know that the object has been taken over,
because it remains on his screen (and does not display the
ownership attribute).  If this original station wants to move
the object, he can do so, and again, the network will respond to
this new entry, but again, the centeral OBJECT operator will
take over the new position as sooon as it sees it.

In fact, the original APRSdos was designed with a NETCONTROL
function.  With this switched on, that station would take over
all objects as soon as they appeared. (though anyone can move
them at any time).  This is why in APRSdos, objects have the two
color atributes for OWN object and OTHERS object.  So at a
glance, you can see ownership of each object as it might be
changing back and forth.

Another way that Uiview can be used for objects is if the load
is spread out.  Say each operator only inputs and manages a few
objects.  Say no
more than 5 or so.  This prevents the big-block-transmission
problem and fratricide problem (most TNC's will drop the carrier
after each seven packets and check the channel for channel
sharing).  But this lets the digi start transmitting which then
collides with the next seven.  This is why Uiview simply cannot
be used for more than a few objects for anything except DIRECT
simplex operations.

In this case, since all objects both old and new are always
transmistted on the same schedule by UIview, these schedules
have to be well spread out.  Probably it is best to use a 10
minute rate.  But this then reduces the original APRS timeleness
by an order of magnitude (from under 1 minute to over 10
minutes) and is another reason why people do not see APRS as a
real time tool anymore.  But keeping the channel QRM down is
probably more important since new objects do become old objects
pretty quickly...

The only problem is that either of these solutions requires a a
lot of skilled labor, and attention and planning.  Exactly what
APRS was supposed to avoid!

> ... as I listen to the on-air traffic, I hear 
> a high degree of professionalism, focus and 
> dedication. 

And the key to getting APRS used, is to not try to change those
operators, but instead, to place a PC APRS display in front of
them, not to make him an APRS opeator, but so that he has a MAP
display that he can zoom around on the map as needed to see what
is going on.  Let others in the background or away from the
area, be the INFO-INPUT people to keep the map and
BULLETIN/ANNOUNCEMENT board up to date.

See next message about the BULLETIN/ANNOUNCEMENT BOARD.

Bob, WB4APR