Order Tray | Contact Us | Home | SIG Lists


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...

> 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
> > on 144.39 are not a problem, because they can hear the
> > regions and hold off until there is a quiet instant.  If
> > digipeaters are outputting on 144.39, then the channel can
> > FIVE times what it is carrying now.
> >
> > So the goal is to move as many local stations *TX* to the
> > alternate channel.  All the locals will know it and so they
> > get immediately improved performance because they are TX'ing
> > a channel with no competition from ANY digipeaters or ANY
out of
> > area traffic.  This is a WIN-WIN way to do APRS.  Generally
> > 144.39 +600 (144.99) is available in an area, it makes a
> > local input channel for all locals.  They just have to
> > 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
> 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
> > rest of the world.  But locals who want better performance
> > themselves (and hence, everyone else) will input on the
> > alternate channel (Maybe 144.99).
> >
> > Visitors to the area who want to improve their performance
> > a less congested input could also shift to the alternate
> > (+600 like the locals).  He will know this is availablle by
> > BEACON from everyy digi in the area that is also listening
> > 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

> 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


> Thanks for your insight.
> Regards
> Steven  VK2BOS

More information about the aprssig mailing list