[aprssig] The new D710 and Smart Beaconing?

Thu May 24 01:43:24 EDT 2007

Hi Bob,

Lucid as ever; thanks for the explanation.  I've been spending too much time 
designing 802.11 equipment, and forgot that the typical mobile setup can't 
detect RF energy - can't see the little light come on.

BUT...  The rigs with internal TNCs (the proverbial 710?) could look at the 
squelch status and implement a smarter Smart Beaconing.  The same control 
processor probably runs both the radio and TNC, and already knows when the 
channel is occupied.  Actually, come to think of it, I take back what I said 
above.  Don't all TNCs know this?  Don't they wait until DCD goes away, 
maybe plus a random backoff, before transmitting?  If so, then they would be 
able to count an approximate channel time by looking at the decoded 
"carrier" - whether it results in a good packet or not - even without seeing 
the actual squelch.  (They could also count ratios of good packets & CRC 
errors, and maybe add that to the equation.)

Lots of opportunities to improve on the algorithm, but you do that *after* 
you get the default settings right.  That gets you 80% of the way there.

Greg  KO6TH

----Original Message Follows----
From: "Robert Bruninga" <bruninga at usna.edu>
Reply-To: bruninga at usna.edu, TAPR APRS Mailing List <aprssig at lists.tapr.org>
To: "'TAPR APRS Mailing List'" <aprssig at lists.tapr.org>
Subject: RE: [aprssig] The new D710 and Smart Beaconing?
Date: Thu, 24 May 2007 01:01:36 -0400

Ah, this is a common trap to fall into...

 > Possibly a better algorithm would be to have it
 > beacon *less* frequently if it heard its own
 > packet digipeated *unless* it hears very little
 > traffic overall.

Ah, but it is nearly impossible for a TNC in a mobile to tell
the difference between a saturated/overloaded channel from a
lightly loaded one.  Both of them have fewer decoded packets.

 > If the channel is lightly loaded, then increasing
 > the frequency of the beacon will not hurt, and
 > it is more likely that you are in a more remote
 > area where it may take a few tries
 > to get a packet through unscathed.

This is simply not possible to assume.  And that is why this
kind of approach assures network melt-down (grid lock) above a
certain threshold.  Let me explain.

1) The mobile can only hear the output of a digi.
2) When the channel is overloaded, the digi hears far more
collisions and actually FEWER packets get through the digi.
3) The mobile cannot tell the difference between low numbers of
packets due to low useage, or low numbers due to total overload
and collisions at the input of the digis.

This is fundamental to packet radio and goes all the way back to
the 1960's and the first ALOHA networks.  Starting with a clear
channel, as  you add users, the throughput goes up linearly.
But as you add more users, the throughput begins to taper
slightly.  Add more users and the throughput almost flattens
out.  Add more users and the throughput starts to drop off
rapidly.  Add more users, and throughput rapidly approaches
zero.

The optimum point has been proven to be at about 18% of channel
capacity for an ALOHA network.   It can be as high as 36% if
everyone can hear everyone else simplex.  (This is NOT APRS)...

But in any case, since the "throughput" curve goes up and also
back down, then there are two meanings to any "measured
throughput".  One meaning is lightly loaded.  The other is
saturated.  But they both have the same value and it is
impossible for the mobile to tell the difference.  Notice also
that the curve crashes faster above the optimum loading than it
does going up.  That  is why we try hard to reduce QRM on the
APRS channel whereever possible.

Yes, the DIGI can tell the difference if it compares CARRIER
squelch-open times to decoded packet times.  But the mobile
cannot..  So the mobile should never thrown more packets on the
channel when it sees less success!

Bob, WB4APR

 > ----Original Message Follows----
 > From: Earl Needham via Kubuntu <needhame1 at plateautel.net>
 > Reply-To: TAPR APRS Mailing List <aprssig at lists.tapr.org>
 > To: TAPR APRS Mailing List <aprssig at lists.tapr.org>
 > Subject: Re: [aprssig] The new D710 and Smart Beaconing?
 > Date: Wed, 23 May 2007 11:43:09 -0600
 >
 > On Wednesday 23 May 2007 11:25:56 scott at opentrac.org wrote:
 >  > The Tracker2 has a new feature I'd like to see more widely
 > implemented -
 >  > you can set it so that if it hears its own packet
 > digipeated, it'll skip
 >  > the next n transmissions.  This means you can set a fairly
 > high beacon
 > rate
 >  > to get a better success rate out in the middle of nowhere,
 > but when you
 > get
 >  > into an area with better coverage it automatically cuts
 > back on beacons.
 >
 > 	The HamHUD had a similar feature some years ago.  If it
 > did NOT hear it's
 > own
 > packet repeated, it would send it again.  I believe it would
 > send a total of
 > three of these before it gave up.  I believe this feature was
finally
 > deleted
 > due to complaints of "over-beaconing".
 >
 > 7 3
 > Earl
 > KD5XB
 >
 > _______________________________________________
 > aprssig mailing list
 > aprssig at lists.tapr.org
 > https://lists.tapr.org/cgi-bin/mailman/listinfo/aprssig
 >
 >
________________________________________________________________
_
 > More photos, more messages, more storage-get 2GB with Windows
 > Live Hotmail.
 > http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_
TAGHM_migration_HM_mini_2G_0507
 >
 >
 > _______________________________________________
 > aprssig mailing list
 > aprssig at lists.tapr.org
 > https://lists.tapr.org/cgi-bin/mailman/listinfo/aprssig
 >

_______________________________________________
aprssig mailing list
aprssig at lists.tapr.org
https://lists.tapr.org/cgi-bin/mailman/listinfo/aprssig

_________________________________________________________________
More photos, more messages, more storage—get 2GB with Windows Live Hotmail. 
http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_TAGHM_migration_HM_mini_2G_0507