| |
ZL3AI > APRDIG 26.09.03 12:25l 205 Lines 9885 Bytes #999 (0) @ WW
BID : 1983-ZL3AI
Read: GUEST
Subj: TAPR Digest, Sep 23, 3/7
Path: DB0FHN<DB0RGB<OE5XBL<OE2XOM<DB0PV<DB0MRW<OK0PKL<OK0PCC<OK0NAG<OK0PPL<
DB0RES<ON0BEL<VK7AX<ZL2BAU<ZL3VML
Sent: 030925/1518Z @:ZL3VML.#80.NZL.OC #:9011 [Chch-NZ] FBB7.00i $:1983-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
Subject: Re: WIDEn-N to-UHF path splitters
From: "Spider" <spider@rivcom.net>
Date: Tue, 23 Sep 2003 07:02:56 -0700
X-Message-Number: 14
From: <wes@johnston.net>
To: "TAPR APRS Special Interest Group" <aprssig@lists.tapr.org>
Sent: Tuesday, September 23, 2003 6:24 AM
Subject: [aprssig] Re: WIDEn-N to-UHF path splitters
>I've been thinking about this one....
>
>Given that 70cm has a smaller coverage area, if we did aprs on 70cm LOCALLY,
>the coverage area would be smaller and less subject to distant QRM from
another
>town.
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...lord knows there are a few of them that are totally under
utilized! Many Igates can handle several ports without much of an
issue...except for equipment.
Someone mentioned using 144.34 a while back. Well, IMHO, that is too close
to 144.39 if colocation was necessary. Moving to something like 145.55
would allow proper filtering to occur and desense and overload issues would
be minimal.
Just thinking....
Jim, WA6OFT
----------------------------------------------------------------------
Subject: Part 1/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:17:36 -0400
X-Message-Number: 15
I normally never get involved in discussions on this list, but as a sysop I
have to say this idea of getting rid of the more intelligent WIDEN
digipeating has to be about the worst option a sysop could use, the
opposite is what's needed. Several other suggestions in here would only
hurt, not help, nothing like shooting ourselves in own foot...we hams seem
to be getting good at this, APRS seems to be a good example anymore.
Going back to the dumber "legacy" paths has to be about the worst choice
IMHO. Want to clean up your local rf network? Then kill WIDE, not WIDEn
and TRACEn, drop the offending stations a quick note offering a better
suggested path, watch for awhile if they don't change, you filter them off
at the digi's/igates, sooner or later they get a clue. While NKY is no
hotbed of APRS activity itself, we had some pretty bad channel congestion
issues a year or so ago, I ran some logging at the digi site and it was
clear the old RELAY,WIDE and especially RELAY,WIDE,WIDE and other ongodly
unproto paths were the problem, not the folks using WIDEn properly. I had
about 5-6 stations eating about 25-30% of the channel bandwidth out from
under a list of about 200 stations, these 5 stations were each generating
about a 1000 packets a day with no obvious explanation (messaging etc). I
filtered these problems off (most were nearly a state away and never
noticed), killed WIDE and I CAN TELL YOU FOR A FACT, it was like night and
day the difference it made for the channel access times and relibility for
the local users. If it wasn't for supporting the transient mobiles passing
thru, I'd kill RELAY in the digi's and make the entire NKY rf network
WIDEN/TRACEN only :-) It may very well come to that eventually.
Yes, every area is different. May I suggest you work with a digi sysop
and/or the igate ops to log traffic over a long period (more than just a few
days) and study what is really going on your local rf/igate network. You
might just be surprised what the problem really is.
Around here we have a distant tracker running: RELAY,WIDE,WIDE3-3 Due to
the nature of 2m propagation in this area, this effectively breaks
WIDEN. A typical single packet tx from this station will often create 8
packets in less than 10 seconds as one digi hits the RELAY portion, then all
the others that can hear it will digi the WIDE portion causing dupes and
loops out the wazzoo.
Here's a sample of his tracker traffic, his call has been changed to MASKED
(to protect the innocent, grin), note the timestamps, a flood of 8 packets
in 8 seconds due to using more than one legacy path in his packet together:
MASKED-12>S9PV8Q,K8SCH-10*,WIDE,WIDE3-3 [09/13/2003
01:17:50]:<UI>:`p>]l!ck/"6\}masked
MASKED-12>S9PV8Q,K8SCH-10,W8MWO*,WIDE3-3 [09/13/2003
01:17:51]:<UI>:`p>]l!ck/"6\}masked
MASKED-12>S9PV8Q,K8SCH-10,AB4WS-10*,WIDE3-3 [09/13/2003
01:17:52]:<UI>:`p>]l!ck/"6\}masked
MASKED-12>S9PV8Q,K8SCH-10,W8MWO*,WIDE3-2 [09/13/2003
01:17:53]:<UI>:`p>]l!ck/"6\}masked
MASKED-12>S9PV8Q,K8SCH-10,W8MWO*,WIDE3-2 [09/13/2003
01:17:53]:<UI>:`p>]l!ck/"6\}masked
MASKED-12>S9PV8Q,K8SCH-10,KD4EVB-10*,WIDE3-3 [09/13/2003
01:17:57]:<UI>:`p>]l!ck/"6\}masked
MASKED-12>S9PV8Q,K8SCH-10,W8MWO*,WIDE3-2 [09/13/2003
01:17:57]:<UI>:`p>]l!ck/"6\}masked
MASKED-12>S9PV8Q,K8SCH-10,KF4INN-10*,WIDE3-2 [09/13/2003
01:17:58]:<UI>:`p>]l!ck/"6\}masked
A few seconds of looking at the above and you should see the lack of wisdom
in using more than one "legacy" path in an unproto statement. One simple
packet from this tracker clobbers the channel for nearly 10 seconds and that
is just what I could hear from my location, at a wider view I'm sure the
effect was worse and more widespread than I could hear. The kicker, the
best I can tell he wasn't going much further than 2-3 hops anyways as the
collision city created by the dupes was likely stopping his packet dead in
its tracks, he'd got the same range with better reliability and packet flow
with just good old WIDE3-3. Using more than one legacy path in a packet
should obviously be personna non grata on rf under 99% of the situations.
>UIDIGI RELAY,WIDE,TRACE,xxxxx (up to 4)
>UIFLOOD disabled,28,NOID
>UITRACE disabled,TRACE,29
You can take the 28 and 29 in this and bump them to higher figures if you've
got a tracker or home hammering the channel with a tx every 30 seconds, set
it to 40, this will cut the loading from that station in half if he's
stationary (packet posit data not changing). To get rid of WIDE, you just
make UIDIGI say:
UIDIGI RELAY,TRACE,KY
substitute KY with your states abbreviation or just use RELAY,TRACE for this
setting. WIDE goes bye bye and around here the packet flow calms down to a
tolerable level as the duping and looping grinds to a halt. This keeps
RELAY in the digi for the transient mobiles still running RELAY,WHATEVER and
they can get out at least one hop, the rest will figure out they need to
switch to WIDEN fairly quickly, hams are innovative folks if they really
want to get out they'll figure the needed path out fast, trust me. After
monitoring the flow of mobiles coming and going from Dayton this year (my
digi's cover a good chunk of I-75 in NKY, I saw only one mobile that didn't
get out at all due to this change, he was running WIDE,WIDE, the rest were
either gettng one hop due to RELAY in their path and the bulk were either
running some form of RELAY,WIDEn-n or just WIDEn-n and getting out great.
One station affected for the benifit of many, that's a ratio I can easily
live with. I also saw a couple cases where no WIDE availability stopped
some folks with really bad paths from clobbering the network around here,
limiting them to one hop only.
NOTE: If you kill WIDE on your digi, you should create a "local only path
and beacon" every 10 minutes. There is a good chance that over 10 minutes
of pure WIDEN traffic could flow thru your digi, then since NOID is set on
UIFLOOD (as it should be), the possibility of a legal digi ID situation
developing is possible. I just set mine to pop off a posit every 10 minutes
to the path of LOCAL1 or the like (just use an unproto path that will not
get digi'd. This keeps things local, far better than using HID in my
opinion and doesn't impact the rf network beyond the local talkout range of
the digi itself. I'd venture to bet that if you're running WIDE,WIDE or
even worse RELAY,WIDE,WIDE you will likely find more areas you don't get out
due to being in a pure "WIDEN" environment than you would if you rand just
WIDE3-3 or RELAY,WIDE2-2. If there area exceptions, they'll be few and far
between anymore and getting fewer all the time.
Continued in part 2 of this saga.....
73 de Jeff, KD4EVB
----------------------------------------------------------------------
Subject: Re: Take control <g>
From: Byron Smith <wa6ylb@theworks.com>
Date: 23 Sep 2003 07:23:47 -0700
X-Message-Number: 16
On Tue, 2003-09-23 at 05:28, Bob Bruninga wrote:
>On 22 Sep 2003, Byron Smith wrote:
>
>>...Only the Paccomm firmware digis callsign swap the MYALIAS. Its
>>probably best not to even mention using MYALIAS for anything, because
>>most of the user base of tncs do not callsign swap. This goes for plain
>>TNC2's, tnc2 clones (such as 1270's etc), Kantronics (all), etc.
>>
>>Of course, those digis are Trace digis, and should be
>>upgraded to at least UI-DIGI.
>
>Yes, if they need WIDEn-N. But in local areas where WIDEn-N will b e
>disabled, then a Paccomm TNC will do perfectly.
>
>Thanks for the info
>Bob
Actually, the Paccomm TNC firmware should be upgraded to UI-DIGI. There
are a lot more features in UI-digi than exists in simple aprs friendly
paccomm firmware. I'd upgrade to UI-DIGI even if not using Widen-n just
to get the other features. Plain Paccomm firmware doesnt have all the
dupe checking stuff like UI-DIGI does.
Please click on this URL to see what I mean Bob. I think you'll agree
once you read this.
http://www.ir3ip.net/iw3fqg/doc/UIDIGIE.TXT
Besides, the price is about right :-)
----------------------------------------------------------------------
Read previous mail | Read next mail
| |
