[aprssig] APRS Net Cycle Times

[Robert Bruninga]

>> If it is a house saying 'here I am', 
>> I fail to see the value.  

That's why several years ago, we added the OPERATOR-PRESENT bit.
When it detects operator presence, the decay algorithm is reset
and the station packet is sent immediately with the operator bit
set to PRESENT.  From then on down, the rate decays down to 10
miuntes as long as the operator remins present.  When he is no
longer present, then the decay algorithm continues on down to
the final default 30 minute rate.

> I boot up UI-View, meaning I'm at the keyboard, 
> able to respond to contacts.  ...
> [conisdering] vanity, is a home beacon anymore 
> or any less a vanity beacon, than mobile beacon?

APRS is a real-time network.  A network depends on presence of
stations and consistent performance.  The spec defined two
net-cycle-times.  10 minutes for local-real-time operations
(direct and one hop), and decaying down to a 30 minute rate for
(2 or more hop regional operation) to maintain the situational
awareness.  And if not heard in 80 minutes, the station is faded
to gray and assumed off the air (that's 2 missed chances).

Since APRS is a come-as-you-are system, often dependent on
packet paths via advantaged neighbors (whether or not an
operator is present), then network presence of stations is part
of the network.  All stations are supposed to transmit their PHG
data so that the range and performance of their station is
visibile on the map so that people can devine work-around or
direct paths just by looking at the overlapping range circles.

Problem is, Uiview did not implement PHG circles, neither
transmitting them nor receiving and displaying them, so unless
the operator manually codes it into his beacon, or runs an
add-on, most of these home stations are useless from a network
standpoint because you cannot see their relative performance.

Second problem is, Uiview did not implement the automatic
net-cycle times, but leaves that up to the user.  To change at
will.  And Uiview does not sanity check or make real-time
recommendations to the best value.  Therefore the rate does not
automaticly change based on need, nor decay on lack of need.

Third, Uiview did not implement the OPERATOR-PRESENT bit and
varible beacon rate based on presence. (though I don't think any
system other than APRSdos has done it either).

Fourth, Uiview did not implement the fundamental decay rate.  SO
it is unresponsive to activity, new data, or changed data.  Say
your station is set to 30 minute rate.  And a skywarn is called
up.  Many APRS operators come on the air to assist, yet it is 29
minutes before your station appears on their maps!  The result
of all these is a lack of responsiveness to activity and
immediate functionality to serve the real-time emergent needs of
the operator... 

OF COURSE, the talented Uiview operator that is aware of these
limitations can actively change his rate to meet the immediate
need and patch, and forces immmediate beacons as needed to
participate in the network.  And we are dependent on him to
remember his changes and revert back to low, benign settings and
paths when he walks away..

Adhering to the original network standards gives APRS consistent
performance and gives all users consistent expectations.

Bob, WB4APR