| |
ZL3AI > APRDIG 26.09.03 12:21l 207 Lines 9185 Bytes #999 (0) @ WW
BID : 1984-ZL3AI
Read: GUEST
Subj: TAPR Digest, Sep 23, 4/7
Path: DB0FHN<DB0RGB<DB0FSG<OE7XLR<OE9XPI<DB0CZ<DB0GV<DB0SIF<DB0EA<DB0RES<
ON0AR<ZL3VML
Sent: 030925/1536Z @:ZL3VML.#80.NZL.OC #:9012 [Chch-NZ] FBB7.00i $:1984-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
Subject: Part 2/2 -Re: Take Control - oh let's just go backwards on things,
that's the solution NOT
From: "Jeff Thomas - KD4EVB" <kd4evb@hotmail.com>
Date: Tue, 23 Sep 2003 10:33:10 -0400
X-Message-Number: 17
I'm currently running thru several weeks of off-n-on logs from our rf
network around here as I identify where the current problems are and soon
will be turning WIDE back off on our digi's here in NKY and doing some
filtering of a few problems I found. I can only suggest that sysops do a
lot of logging and studying of what the problem really is in their area
before just jumping in focusing on one particular path that seems to
irritate you and making drastic changes to your local rf/igate
archetecture.
Around here WIDE4-4 and especially WIDE5-5 or greater is considered
excessive, other areas may not consider 5 hops excessive. Around here our
philosophy is never use more hops than is takes to reliably hit an IGATE,
any more hops is usually wasting bandwidth. Contact the problem stations,
if they don't adjust in a few days to be more considerate of others, then
just filter them off, simple enough. Killing the more intelligent WIDEN
digipeating protocol and going backwards in time to the old "legacy" paths
which I bet you will find is where the real problems are originating).
Unless your in a very remote area with considerble distance between digi's,
I'd venture to say that RELAY,WIDE,WIDE is doing more damage to the rf
channel than his WIDE5-5 is. Run some logs, run some tests, get someone
that understands the WIDE and WIDEN protocol to look over the logs with you,
go beyond just focusing on this one guy with WIDE5-5, I bet you got other
worse problems on rf. Sort your station list by decending number of packets
and study who is creating abnormally high numbers of packets locally, then
investigate why.
I ran three hours of logs directly off the TNC at the digi site a few weeks
ago and only took a few minutes to see several problems.
The best solutions, given what we've got to work with now, for bringing
144.390 under control are:
1. User education, (eg your house doesn't move so why beacon it's posit'
more than once every 30 minutes). Trackers and Wx stations with default or
overly high tx rates (often combined with bad paths) often are what is
consuming the bandwidth.
2. Get away from the older "legacy" paths, especially WIDE as fast as you
can on the digi's. WIDEN offers better packet flow and dupe/loop prevention
when properly setup on digi's and users. LEAD....THE REST WILL FOLLOW...if
they want to get out with any reliability. Filter the continuing problem
stations off and move on folks.
3. The people in the best position to bring the rf network under control
are the sysops of the digi's and Igates. Work together to get optimal
settings and share filter lists for folks causing problems and too hard
headed to change.
4. Study the traffic on your local rf systems from time to time, adjust,
filter, and adapt as needed. Some folks will never change till they have
to, for them filtering is the best way to solve the problem.
5. Embrace WIDEN, embrace WIDEN, embrace WIDEN can I say it enough?
6. Yeah it would be nice if the WIDEN digi folks could create filters that
block excessive WIDEN paths, but trust me going back to the RELAY and WIDE
days isn't the solution either.
7. We better start coming up with something even better than WIDEN and 1200
baud folks. The above will only keep things contained for so long, there's
simply a limit to how much traffic you can pump thru rf at 1200 baud, since
it's unconnected traffic, it might as well be 600 baud (no collision
detection, no retransmitting in the protocol, your packet suffers collision
along the path...it's dead) for all practical purposes. Many folks are
tinkering around on the old 440 packet channels with 9.6k APRS, you might
want to check 441.0 and 446.5 in your area at both 1.2k and 9.6k, might be
surprised. Nothign says you can't put up a UHF digi or a digi on another 2m
freq and feed an igate off that channel (or not), many are doing just that
to get away from the piss poor reliability of 144.390 in their own area.
TIME TO INNOVATE SOME, EMBRACE THE NEWER PROTOCOLS AND NOT GO BACKWARDS.
I know filtering is a somewhat emotional topic for some, but given the
bandwidth brick wall we face at 1200 baud unconnected packets, I don't
foresee we are left with much of a choice anymore. I'd love to just leave
my digi's runni7.00i $:1985-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
Subject: Re: WIDEn-N to-UHF path splitters
From: Bob Bruninga <bruninga@usna.edu>
Date: Tue, 23 Sep 2003 12:49:45 -0400 (EDT)
X-Message-Number: 21
On Tue, 23 Sep 2003, Spider wrote:
>The same holds true by just using another vhf freq for local traffic
>too! A VHF freq for fixed data stations would not be a bad idea or for
>SAR where a single SAR could and would destroy the current "magic
>number" idea! Can you imagine 20 extra trackers coming into your local
>144.39 freq and transmitting every second or so? Odds are it would shut
>your local network down to the point of being useless! Yeah, it makes
>sense to have 144.39 as a 'national' freq for trackers, but LOCAL areas
>should consider using other VHF freqs...
I would be strongly opposed to this idea. This is just more and more
disintegration of APRS and fractionalization. Keeping it simple by
removing the DX WIDEn-N from the local area (could be your entire state)
will more than solve the problem of saturation. No need to go to a
Again, the concept is simple. Turn off WIDEn-N in digis that are flooding
your area with outside N-N traffic. Leave that digi intact as a
RELAY/WIDE digi with call substitution for all local or regional activity.
Install a second TNC and UHF transmitter that will still HEAR the WIDEn-N
traffic at that point, and send it out onto the UHF backbone where it can
still be heard in yoru area if someone wants to hear it.
Thus, nothing is lost. Yet one gains local control of what FLOODS your
area. In fact, by doing the crossband to UHF digipeat of WIDEn-N traffic
as it nears cities, then it can still GO THROUGH the city and out the
other side if all the surrounding WIDEn-N digis were using the same UHF
frequency.
In otherwords we have easily and effectively split all APRS traffic into
local and long-haul using what we already have. THus KISS...
de WB4APR, Bob
----------------------------------------------------------------------
Subject: Re: WIDEn-N to-UHF path splitters
From: Dave VanHorn <dvanhorn@cedar.net>
Date: Tue, 23 Sep 2003 12:40:54 -0500
X-Message-Number: 22
>But the idea is to stop digipeating WIDEn-N at the border digi before
>it gets to tothat is all fine and good, but it
would be best not to imply that it is APRS Version 2 and it probably
shouldn't target an already saturated 144.39 until or unless there is
unanymous local concurrence...
Bob
----------------------------------------------------------------------
Subject: Re: WIDEn-N to-UHF path splitters
From: Bob Bruninga <bruninga@usna.edu>
Date: Tue, 23 Sep 2003 13:53:59 -0400 (EDT)
X-Message-Number: 25
On Tue, 23 Sep 2003, Daron J. Wilson wrote:
>>In other words we have easily and effectively split all APRS traffic
>>into local and long-haul using what we already have. THus KISS...
>
>Let us just remember though that we don't already have:
> 2nd TNC at each location
> UHF transmitter/cavity/antenna at each location
> Dual band radios for each user in the area
Ah, but those are only needed if one insists on continuing to see WIDE7-7
traffic from everyone in their surrounding states. THe fundamental
principle is to simply turn off WIDEn-N in those LAN's that are flooded
by external traffic. It requires NOTHING to do that.
I only offer the added TNC and UHF radio for those that then want to go
back in and still hear all that junk. I cannot imagine MOBILES would
ever be interested in flooding their screens with traffic from 500 miles
away. The only people that would need a UHF receiver (about $80) would
be an IGate that might need to still hear the DX traffic.
>Doing this presents a relatively large upgrade of the system, and we
>need to be sure that is the most effective way of doing it.
I dont think so. It is a trivial chnage. Just turn UIFLOOD in the
offending digi's TNC to OFF.
de WB4APR@amsat.org, Bob
----------------------------------------------------------------------
Subject: Tactical RF Networking !!!
From: "Sadowski, Allan" <allan.sadowski@ncshp.org>
Date: Tue, 23 Sep 2003 14:06:44 -0400
X-Message-Number: 26
http://www.faqs.org/rfcs/rfc1677.html
Having heard repeatedly about the "tactical" nature of APRS... the one
thing that APRS really fails to deliver is ASSURED DELIVERY of position
info. In REAL tactical situations... you really need to get the message
through in time to be useful - or at least know that it failed to get
through...
I won't go at length - but it's interesting that there is an internet
RFC on the topic...
----------------------------------------------------------------------
Read previous mail | Read next mail
| |
