Order Tray | Contact Us | Home | SIG Lists

[aprssig] APRS rates (and decay)

Robert Bruninga bruninga at usna.edu
Mon Jan 14 22:13:32 UTC 2008


> > There are two specified beacon rates for APRS, 
> > 10 minutes at events or DIRECT or ONE-HOP local 
> > use, and 30 minutes for 2 hops or more wider 
> > area use. So a parked car, if not turned off
> > altogether, should decay to 30 minutes.  These 
> > standard final rates are there so that APRS has a 
> > consistent expectation of latency for operating stations.
 
> Are you saying that stations should ONLY transmit 
> every 10 minutes (direct - no path) or every 30 
> minutes (2 hop path) and nothing other than
> that? 

No, not at all.  You have to remember that the original APRS
applied the decay rate to everything.  Positions, messages,
status, everything.  If it was new, it was refresehed starting
at a high 8 second rate but then always decaying down until it
reached the bottom-line final rates of 10 or 30.  And these also
were NOT user settable!  If the user was using a path of DIRECT
or 1 hop, then he decayed to a 10 min rate.  If he was uwing 2
hops or more, then he decayed to 30 minutes.  That was the
fundamental principle of APRS sharing a channel. 

The number one advantage of this original APRS design, was that
there were no user settable rates to screw up!  It was all
transparent to the user.  Any new bit of information that he
entered into APRS was refresehd at an initial rate of 8 seconds,
and then on down.  The 10 and 30 minute FIXED rates are the END
of that decay process if the data -has-not-changed.  And again
this was not a user setting.  It depended on the length of his
path.  That alone could tell us if this was a local event (final
10m rate), or a regional event (final 30m rate).

Now of course, for a mobile with GPS, then there was a user
selectible rate since 8 seconds would be too high for that.
That was then the only user settable rate.  Say 1 minute for a
special event, 2 minutes for routine.  BUT it also got the same
DECAY algorithm applied to it as well.   As long as the GPS data
was changing (beyond 100 feet), it stayed at that 1 minute rate.
But if the vehicle stopped, and the position did not change,
then it would automatically decay., but it would pick back up
immediatelly if it changed again.  Again, no user intervention
required, and also randome GPS gitter was also ignored.

> I stand by my statement that I think Kenwood 
> would have included it if you would have asked 
> them to. 

I have asked them to.

>> Proportional pathing makes sure that locally,
>> a vehicle is reported more often than at distance. 
>> Hence it reduces channel QRM by an order of magnitude. 

> However, it still sounds lie the D710's going out 
> with a 2 hop path every 4 minutes.  However, is 
> that "no matter what" or does it reduce then to 
> every 30 minutes if it's stationary? 

Yes and no.  Both Proportional Pathing and Decay are independent
options that can be enabled or disabled.  They both apply.  If
you have them both on, and pull into work but leave your system
running, then it will slowly decay to a lower rate AND will also
not use the longer path except for every 4th packet, etc..  If
after an hour, the rate has decayed to 30 minutes, then you will
hear the car every 30m locally, once an hour via the local digi,
and once every 2 hours throughout the state (east coast state).

> If I look around me, most stations are not moving. 
> Home stations, weather stations, digipeaters etc...

In the original APRS, WX station data is treated like all other
data, if it is changing, then it is transmitted at the initial
rate.  If it is not changing then it is decayed.  If there is a
change, then the decay is canceled and it is transmitted at the
high rate again.  The idea always is that NEW informaiton in
APRS is desired FAST and old data is desired slow, and we should
not depend on the user or the operator to be constantly
changing.  It was supposed to be fully automatic and transparent
to the user.

> The operator at the home station can set
> responsible paths and set it at a low beacon rate. 

No, such simplistic reasoning and dependency on correct settings
by users for each situation completely undermines the design of
APRS.  APRS was not supposed to have to have trained operators
always having to manipulate every path, every timing, every rate
depending on what he was doing!  It is this simplistic approach
taken in most follow-on clones that is ruining the concept and
making APRS less useful as the real-time situational awareness
and communication system.

> To be useful, the weather stations should probably 
> beacon more often... every 5 or 10 minutes.

Yes, but if they were done like the original APRS, then they
would be proportional to what was happening, and no one would
have to change them.  As soon as we have operators having to
change to high rate for some situatinos and low rate to minimize
QRM, we are setting ourselves up for all the exact problems we
have today.  Forgotten parameters beaconing too often, too far,
or not enough when needed.

> The digipeaters we have sorted out with most 
> of their own beacons going out direct with 
> no path, but with a one hop path once an hour 
> and a two hop path once an hour. 

Yes, that is proportional pathing...

> The DR-135T has a NICE setting where it 
> will skip the next X beacons if it hears 
> itself having been digipeated, the idea 
> being that it can beacon at a faster 
> rate in areas with poor coverage, but hold 
> off on the next several beacons if 
> it hears itself coming back. 

I sure hope there is more to it.  Because that also is a good
definition of a nuclear melt down.  The term "in areas with poor
coverage" is completely indistinguishible from an "area with
total overload" if all you are using to measure it is
-own-packet-heard.  Neither one of them are hearing their
packets.  In the one case transmitting again makes sense.  In
the other, it is the worst thing to do.  The ONLY WAY, I can
agree to such a potnential melt-down algorithm is if it has an
external squelch connection or runs OPEN squelch and it can also
detect channel BUSY (not just packets detected.  There is a
catastrophic difference).. 

There really was a lot of effort put into this that was ignored
when APRS became to be viewed as only a vehicle tracking system
(with simplistic fixed rates)...

Bob, WB4APR





More information about the aprssig mailing list