Order Tray | Contact Us | Home | SIG Lists

[aprssig] THOUGHTS ON RELIEVING APRS CONGESTION ON 144.39

Robert Bruninga bruninga at usna.edu
Thu Nov 18 17:34:15 UTC 2010


Top Post Summary:  The way to greatly minimize local congestion
on 144.39 is this:

1) Leave the 144.39 network just like it is now. (so it still
works for visitors)
2) Provide an alternate INPUT channel (144.99?) TNC and receiver
at every big digi.
3) The PTT/TXaudio of that alternate TNC is connected to the
existing 144.39 XMTR.
4) The eXternal Carrier Detect (XCD) line is diode-ORed to both
TNC's PTT lines.

The result is vastly improved local user reliability since their
input packets on 144.99 do not have to compete with any of the
144.39 congestion.  Yet 144.39 still has ALL info for ALL users.

Now, how to add 9600 baud is a different animal. The PNW
experiment is forging new ground here and the D700 makes a great
dual system, but I have not figured out in my own mind an easy
way to merge the 9600 baud data back onto 144.39 easily.  So I
will not address that yet...

Bob
WB4APR
> On Wed, 2010-11-17 at 13:32 -0500, Robert Bruninga wrote:
> <snip>
> > The number #1 problem with congestion on 144.39 is
collisions on
> > the inputs of the digipeaters.  The outputs of the
digipeaters
> > on 144.39 are not a problem, because they can hear the
entire
> > regions and hold off until there is a quiet instant.  If
only
> > digipeaters are outputting on 144.39, then the channel can
carry
> > FIVE times what it is carrying now.
> >
> > So the goal is to move as many local stations *TX* to the
local
> > alternate channel.  All the locals will know it and so they
will
> > get immediately improved performance because they are TX'ing
on
> > a channel with no competition from ANY digipeaters or ANY
out of
> > area traffic.  This is a WIN-WIN way to do APRS.  Generally
if
> > 144.39 +600 (144.99) is available in an area, it makes a
perfect
> > local input channel for all locals.  They just have to
remember
> > to change to 144.39 simplex when they leave their area.
> </snip>
> 
> This strategy sounds neat and effective.  I am just trying to
get my
> head around the details and a practical setup.  I have had a
look on
> aprs.org for further information but can't find anything.
What is the
> basis for the increase in capacity of five times?  Isn't the
collision
> problem still going to exist but just on the alternative 
> input channel?

The huge difference is because on 144.39 there are DIGI ouputs
and user inputs.  So each user's initial input packet has to
compete with 95% of packets that are not other inputs, but are
digi outputs.  By having a separate INPUT channel, then inputs
only collide with other inputs AT THAT DIGI..  And there are far
fewer local users in simplex range of each "input" site...

> > The local system still LISTENS for 1st-hop WIDE1-1 inputs on
> > 144.39 visitors still get in perfectly and no change from
the
> > rest of the world.  But locals who want better performance
for
> > themselves (and hence, everyone else) will input on the
> > alternate channel (Maybe 144.99).
> >
> > Visitors to the area who want to improve their performance
with
> > a less congested input could also shift to the alternate
channel
> > (+600 like the locals).  He will know this is availablle by
the
> > BEACON from everyy digi in the area that is also listening
on
> > 144.99 input.  Their beacon will contain something like W2,
> > MDn-N,alt 144.99 ... (this is for Maryland MDn-N digis)...
> <snip>
> 
> Are you saying the WIDE2 digis listen on both frequencies?  

Yes, and this is hardware intensive because it needs 2 TNC's and
radios

> Do the fill in WIDE1 digis listen on 144.39 but pass 
> the packet to the WIDE2 digi on the second channel (144.99)?

The 144.39 network remains just like it is now.  But you ADD a
second set of 144.99 RECEIVERS and TNC's at each digi to bring
in the local uers who decide to use that much more uncongested
channel.

Bob
WB4APR

> 
> Thanks for your insight.
> 
> Regards
> Steven  VK2BOS
> 
> 




More information about the aprssig mailing list