[aprssig] Beacon rate feedback

[Robert Bruninga]

This idea of retry-if-not-heard has come up a number of times on
APRS, but the general conclusion is that it has the potential to
be a disaster for the network.

The problem is that a "decoder" in a mobile cannot tell the
difference between an empty channel and a totally saturated
grid-locked one.  They both have very few decodes per minute.
Thus, these devices that try-harder-when-not-decoded  are a
china-syndrome melt-down scenario waiting to happen.

What needs to happen as the channel gets crowded and packets
become less reliable and are not-heard is exactly the opposite,
to reduce-the-rate, not increase it.

The best general algorithm for sharing the channel with others
while also being heard locally and getting out reliably is
Proportional Pathing.  Set to a 1 minute rate, it maintains a
nice consistent presence in its local vicinity for local, or
event operations, it maintains a nice 2 minute presence in the
area of its first digipeater, and maintains a nice 4 minute
presence in the region.  And the operator does not have to
change anything when doing something local (an event, 1 min) or
traveling on a long trip (being seen once every 4 minutes out 2
hops)...

See www.aprs.org/newN/ProportionalPathing.txt

Bob, Wb4APR



> -----Original Message-----
> From: aprssig-bounces at tapr.org 
> [mailto:aprssig-bounces at tapr.org] On Behalf Of Scott Miller
> Sent: Monday, November 24, 2008 1:15 AM
> To: TAPR APRS Mailing List
> Subject: [aprssig] Beacon rate feedback
> 
> I drove about 600 miles up to my sister's place in the San
Francisco
> area and back this weekend, and used the drive as an 
> opportunity to try
> a few things.
> 
> I was running an FC-301/D at 5 watts, which is a lot less
power than
> what I usually run on the DR-135T.  But this time, I set the
beacon
> interval to 30 seconds and the NICE parameter on the T2 (a 
> prototype of
> the add-on board for the FC-301/D) to 3.
> 
> The NICE parameter (named for the UNIX command for setting
process
> priority) causes the T2 to skip the specified number of 
> beacons whenever
> it hears itself digipeated.  I've never run it higher than 1
in normal
> operation, and never with a significantly higher than normal 
> beacon rate.
> 
> With the 30/3 setting, as long as it gets an echo, the beacon
interval
> is effectively 2 minutes.  If it didn't hear anything, it'll 
> retry every
> 30 seconds.
> 
> This is a higher rate than I'd run for everyday use, but I
don't make
> these trips often and I wanted to gather some useful data.
And so far
> it looks like it worked pretty well - there are very few
places where
> more than one packet in two minutes was seen at an IGate, and
some of
> those (like in Salinas) were heard by an IGate without 
> hitting a digipeater.
> 
> For highway driving at least, I think I like this scheme
better than
> SmartBeaconing.  It retries in places where it's needed and
doesn't
> flood the network.  Whether this would still be a good idea 
> at 50 watts,
> I'm not sure.  But I figure at 5 watts, the chances are very
good that
> if the digipeater can hear me, I can hear it at least as well.
> 
> I know the HamHUD has a digi-meter to tell you when you're
getting in,
> and I think APRSDOS had some kind of feedback, but I can't
recall if
> either of those actually controlled the transmission rate that
way.
> Does anything else do this?  It's something that the T2's been
able to
> do for a while now, but I haven't really been pushing the 
> feature.  I'd
> like to encourage greater use of it, but I'd like to hear 
> what the APRS
> community thinks of it.  The callsign in use was N1VG-6 if you
want to
> check it out.
> 
> 73,
> 
> Scott
> N1VG
> 
> 
> 
> _______________________________________________
> aprssig mailing list
> aprssig at tapr.org
> https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig
>