[aprssig] THOUGHTS ON RELIEVING APRS CONGESTION ON 144.39

[William McKeehan]

In East Tennessee, we found that our problem was too many packets from outside
of the area. Here's a post that I put on another board trying to explain how
we addressed this situation; a similar solution may work for you.


The digi's in East Tennessee typically have a HUGE coverage area because of our
mountainous terrain. Without restricting what they digi on, we frequently see
packets from hundreds of miles away (i.e. from Florida, Arkansas, Ohio,
Missouri, etc.) in our area. These packets are needless and reduce the
reliability of the local area packets.

The other TNCs in the area are Kantronics KPC3+; we have them configured with
something like this:

UIDIGI ON TN,WIDE1-1,WIDE2-2
UITRACE TN,30
UIFLOOD TEMP,30,ID

This generally provides one or two hops to any station in the area using
recommended paths. We have found that this is enough to facilitate local
situational awareness, getting local traffic into an iGate and local messaging.

We do not digi on WIDE2-1; that is generally used in conjunction with
WIDE1-1 as in WIDE1-1,WIDE2-1. We digi on WIDE1-1, then let the WIDE2-1 die or
possibly be picked up by a digi outside of the area.

We have determined that in our area with our very wide area digis that a
single hop is sufficient for 90%+ of the day-to-day traffic and limiting in
such a way has improved the efficiency of our local network.

We also have the option of using TNn-N if we need wider coverage and support TN
to take advantage of some older TNCs in the area which we have not been able to
get updated to the new WIDEn-N paradigm.

We did extensive testing to arrive at this configuration; we have found that for
day-to-day operations, it works very well and has dramatically reduced the
number of out-of-state packets hear in our area and has greatly improved the
reliability of our local network.

Is this the ideal solution for everyone? Maybe not, but the terrain in East
Tennessee makes things a little different and we have modified our network
infrastructure to deal with these differences as best we can.
-- 
William McKeehan
KI4HDU
http://mckeehan.homeip.net


On Tue, November 16, 2010 10:28 pm, David Dobbins wrote:
> Hello fellow APRS enthusiasts. I’m curious to know what the rest of the
> world is doing to relieve some of the congestion of APRS traffic on the
> primary freq 144.39? In my wide travels, my experience has been the larger
> metro areas are suffering from APRS indigestion, meaning if you turn the
> volume up on 144.39 and listen, it’s uncommon to hear any break in the
> packets the closer you get to the big cities.
>
>
>
> I’d like to share what we’ve been doing about this oversaturation of the
> primary freq in the Puget Sound area. For the past couple years we’ve been
> experimenting with, and done some implementing of APRS at 9600bd on both UHF
> and VHF. The initial alternative frequency/speed experimentation began on
> UHF 440.800MHz at 9600bd by Bob King, K7OFT. We have several UHF APRS
> digipeaters around the Seattle area. The typical digi setup is an Icom
> IC-207 and Kantronics KPC-9612, using the same configuration settings found
> on the primary frequency. The biggest group of users are mobiles, typically
> those with TM-D700/D710 or the Yaesu FTM-350R and similar handhelds. Those
> tracking on the UHF frequency are gated to the APRS-IS, and those with an
> internet connection at their home station will see both the VHF primary, and
> UHF secondary APRS activity. Our VHF 9600bd effort commenced a little later
> than the UHF interest, but has grown significantly over the past year, with
> several high level digipeaters serving the alternate VHF frequency
> 144.35MHz. Scott Cronk, N7FSP has been leading this effort. We eliminated
> the possibility of interference between the two freqs (144.39 and 144.35) by
> replacing an existing APRS digipeater VHF radio with a Kenwood TM-D700 or
> D710, and retaining the existing KPC-3 (or an Argent TNC). The internal
> radio TNC operates at 9600bd on 144.35, and the other side of the radio is
> set to 144.39 and uses the external 1200bd TNC. No change to the filter
> solution has been necessary, or need to add or change antennas, since the
> two freqs are close together. We’ve had three arguments presented why this
> solution wouldn’t work, and all three have been dismissed. First, folks said
> 9600bd won’t work on VHF. It does, and quite well. Second, folks said the
> two freqs were too close together and would cause interference. Not so, as
> the D700 becomes “deaf” on one side of the radio when the other side is
> transmitting, thus no issue. Third, while one side was transmitting, there
> would be packets not digipeated on the other side. We’ve found this to be
> not much of an issue, and the increase in packet loss at the digipeater is
> insignificant. We have a growing number of mobile users throughout Puget
> Sound using the 144.35 APRS @ 9600bd with very good results. With several
> iGates, including direct IGating from the mountaintop digipeaters with
> internet access, everyone trying to get their data to the APRS-IS is getting
> through. We’re encouraging home and other fixed stations to make the switch
> to the alternative frequency to further relieve some of the congestion on
> the primary frequency. It’s too early to tell just how much relief we’ve
> seen on the primary frequency, and difficult to measure. We've also been
> experimenting with cross-banding of data, feeding packets and messages back
> and forth between the VHF 1200bd, VHF 9600bd, and UHF 9600bd channels.
>
>
>
> We’re also encouraging makers of the VHF trackers to add 9600bd capability
> to their products. For those folks in areas oversaturated by APRS packets, I
> suggest the next time you make the mountaintop digipeater run to replace the
> existing VHF radio with a Kenwood TM-D700/D710 and give dual-APRS ops at
> 1200bd and 9600bd a try.
>
>
> Dave K7GPS
>
> NWAPRS Spokane Area Coordinator
> _______________________________________________
> aprssig mailing list
> aprssig at tapr.org
> https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig
>