[aprssig] The new D710 and Smart Beaconing?

Thu May 24 02:17:24 EDT 2007

> ... Don't all TNCs know this?  Don't they 
> wait until DCD goes away,... 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..

True, but only the digi on the mountain hears "the channel"...
The problem is that the mobile only hears maybe 5% of what is
happening on the DIGIpeater's input.  And the digi's input is
the only place where the loading on the channel can be properly
assessed... Not at the mobiles...

That is why we must not use any algorithms at the mobile that
increases packet rates when the mobile thinks the channel is
lightly loaded, because the "quiet" channel it hears might
equally be totally saturated at the digi 
And that is why nothing is coming out of the digi...

Thanks
Bob

> 
> ----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
> 
> 
> _______________________________________________
> aprssig mailing list
> aprssig at lists.tapr.org
> https://lists.tapr.org/cgi-bin/mailman/listinfo/aprssig
> 