| |
ZL3AI > APRDIG 04.10.03 11:18l 257 Lines 9858 Bytes #999 (0) @ WW
BID : 2079-ZL3AI
Read: GUEST
Subj: TAPR Digest, Oct 01, 4/11
Path: DB0FHN<DB0RGB<OK0PPL<DB0RES<ON0AR<7M3TJZ<F6CDD<EA5RQ<VK4TUB<ZL2BAU<
ZL3VML
Sent: 031003/1348Z @:ZL3VML.#80.NZL.OC #:9639 [Chch-NZ] FBB7.00i $:2079-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
Subject: RE: Random backoff
From: Bob Bruninga <bruninga@usna.edu>
Date: Wed, 1 Oct 2003 10:28:23 -0400 (EDT)
X-Message-Number: 20
On Wed, 1 Oct 2003, Henk de Groot wrote:
>At 18:00 30-9-03 -0400, Bob Bruninga wrote:
>>Hold on. SLOT TIME and PERSIST only work in a connnected envrionment with
>>retries. (IE, regular packet) APRS is a UI system that has no retries,
>>thus no PERSIST. Yes we can assign SLOTS based on GPS timing...
>
>No, thats RESP and FRACK. SLOTTIME and PERSIST are used to find an empty
>channel..
Sorry, I stand by my post that we must have DWAIT of 0 in all DIGIS and
SLOT/PERSIT must be disabled.. You are correct, that SLOT and PERSIT
apply to UI packets, but ONLY TO USER PACKETS, NOT TO THE DIGI.
I am only talking about DIGI settings (sysop missguided hacks). THe DIGI
MUST NOT HOLD OFF, but must ALWAYS be the first to sieze the channel.
That is what SLOT and PERSIST do for the users, is to hold off and let the
DIGI do its job most effectively! But the DIGI Dwait MUST be 0 in an APRS
network for the DIGIS and SLOT and PERSIST must add no additional delays
for the digi.
de WB4APR, Bob
----------------------------------------------------------------------
Subject: Re: Take Control of your DIGI (3)
From: Bob Bruninga <bruninga@usna.edu>
Date: Wed, 1 Oct 2003 10:47:45 -0400 (EDT)
X-Message-Number: 21
On Wed, 1 Oct 2003, Tim Cunningham wrote:
>Back to the example and please do not say this is plain wrong. It is the
>reality. Of course, there are may things to fix, but the fact remains there
>are a whole lot of dupes in this scenario. To say dupe checking really
>works meams we really closing our eyes to the reality of what is happening
>here.
GEEZE, how many times do we have to go through this... YES!!!!! The below
example CLEALRY SHOWS how the EXISTING SYSTEM in YOUR area is TOTALLY
BROKEN. WE AGREE 100%! But the FAULT is not due to callsign
substitution!
>KE4ROC-9>BEACON,RELAY,WIDE,WIDE/1:!3440.31N/0863
>KE4ROC-9>BEACON,RELAY*,WIDE,WIDE/1:!3440.31N/086
>KE4ROC-9>BEACON,W4GPS-7*,WIDE,WIDE/1:!3440.31N/0
>KE4ROC-9>BEACON,W4GPS-7,WIDE*,WIDE/1:!3440.31N/0
>KE4ROC-9>BEACON,WC4ADG*,WIDE,WIDE/1:!3440.31N/08
>KE4ROC-9>BEACON,WC4ADG,WIDE*,WIDE/1:!3440.31N/08
>KE4ROC-9>BEACON,RELAY,W4SBO-7*,WIDE/1:!3440.31N/
>KE4ROC-9>BEACON,WC4ADG,W4GPS-7*,WIDE/1:!3440.31N
>KE4ROC-9>BEACON,RELAY,W4SBO-7,W4GPS-7*/1:!3440.3
>KE4ROC-9>BEACON,WC4ADG,W4SBO-7,W4GPS-7*/1:!3440.
>KE4ROC-9>BEACON,WC4ADG,W4GPS-7,WIDE*/1:!3440.31N
BUT THE PROBLEM IS NOT CALLSIGN SUBSTITTUION!!! It is a cascading of all
of the OTHER problems that I have now listed over and over again:
1) THIS IS A FIXED STATION! Why is it using RELAY?????
2) It clearly has HIGH antenna and can HIT MULTIPLE RELAYS and WIDES
WHY IS IT USING RELAY?????????
3) I count four un-callisgn substituted RELAYS (turn them OFF!)
4) I count at least TWO non-call substituting WIDES (obsolete in 1996)
Now if you would just stop being FIXATED on the forest and look at the
remaing trees when you FIX what should have been fixed since 1997, then
the RESULT is only these packets, and only ONE is a "dupe".:
>KE4ROC-9>BEACON,W4GPS-7*,WIDE,WIDE/1:!3440.31N/0 <= required at W4GPS
>KE4ROC-9>BEACON,WC4ADG*,WIDE,WIDE/1:!3440.31N/08 <= required at WC4ADG
>KE4ROC-9>BEACON,WC4ADG,W4GPS-7*,WIDE/1:!3440.31N <= The ONLY "dupe"
>KE4ROC-9>BEACON,WC4ADG,W4SBO-7,W4GPS-7*/1:!3440. <= required at W4SBO
AND the only reason you got the last packet TWICE at W4GPS was because of
one of the NON-CALLSIGN SUBSTITUTING DIGIS THAT DID NOT IGNORE THAT
ORIGINAL NON-CALLSIGN SUBSTITUTED COPY and let it FOLD BACK!!!!!
So your implication of 11 dupes due to callsign substitution is just plain
wrong, and missleading. If you would FIX your local network to at least
1996 callsign substution guidance, then there would only be ONE dupe.
And that is certainly worth all the advantages of full identity and
traceability in the network.
de WB4APR, Bob
----------------------------------------------------------------------
Subject: The new APRS n-N paradigm
From: Bob Bruninga <bruninga@usna.edu>
Date: Wed, 1 Oct 2003 11:25:42 -0400 (EDT)
X-Message-Number: 22
All the details of the new APRS n-N paradigm to immediately FIX 144.39
back to a high reliability system are now in my FIXING 144.39 WEB page:
http://www.ew.usna.edu/~bruninga/aprs/fix14439.html
ALL of the benefits are under SYSOPS immediate control and do not depend
on user education to get immediate results. User education will follow.
SYSOPS with an "open mind" should digest it thoroughly... Then implement
it consistently. Its a great opportuity to get that LAN you always
wanted. And you CAN control the damage of users. Go for it.
de WB4APR, Bob
----------------------------------------------------------------------
Subject: Re: The new APRS n-N paradigm
From: "Phil Pacier, AD6NH" <ad6nh@arrl.net>
Date: Wed, 1 Oct 2003 10:59:11
X-Message-Number: 23
As we all may know, it will be very difficult to get a "national" 70cm
frequency coordinated for APRS use, but I don't think that is a problem
that can't be worked around. I have written the local coordinating group
for 70cm in Southern California to ask for frequencies that can be used for
70cm 1200 baud APRS packet data. When I get a response, I will start doing
some testing using your different solutions. Could be fun!
73
Phillip Pacier - AD6NH
http://www.aprsca.net
----------------------------------------------------------------------
Subject: LANn-N Experiment
From: Bob Bruninga <bruninga@usna.edu>
Date: Wed, 1 Oct 2003 12:07:23 -0400 (EDT)
X-Message-Number: 24
Tim,
Since North Alabama is a nice average situation, I wonder if you would be
able to just give me your local assessment of what would be your ideal
design, if you were to take the advantages of LINKn-N and LANn-N concepts.
1) IE, how many surrounding digis would consider themselves to be part of
the North Alabama LANn-N network? What would be the typical length of
most LANn-N hops?
2) Are there any linear pipelines that could be converted to linear chains
of LINKn-N digis?
I see about 15 digis in 80 miles and that covers about 100 users.
Probably it should not go as far as birmingham. But I wonder what Lookout
mountain thinks? I dont think they could belong to tan ATLANTA LANn-N
beacuase it would be saturated.
You could experiment with the LANn-N concept without impacting any current
users, because most people dont use TRACEn-N anyway. So simply get some
of your sysops to remotely change their UITRACE parameter to NALAn-N
and experiment.
(Of course, not until you disable WIDEn-N will you see the benefits, but
it wouldnt hurt to start implementing the NALAn-N underneath and slowly
moving people over to it.. then some day, turn off WIDEn-N and then see
what results...
Bob
----------------------------------------------------------------------
Subject: Re: The new APRS n-N paradigm
From: Bob Bruninga <bruninga@usna.edu>
Date: Wed, 1 Oct 2003 12:09:50 -0400 (EDT)
X-Message-Number: 25
On Wed, 1 Oct 2003, Phil Pacier, AD6NH wrote:
>As we all may know, it will be very difficult to get a "national" 70cm
>frequency coordinated for APRS use, but I don't think that is a problem
>that can't be worked around. I have written the local coordinating group
>for 70cm in Southern California to ask for frequencies that can be used for
>70cm 1200 baud APRS packet data. When I get a response, I will start doing
>some testing using your different solutions. Could be fun!
Thanks. ANd the UHF channels don't need to be universal. Each area and
each application can (and must) have its own (to avoid QRM)...
Thanks...
Bob
----------------------------------------------------------------------
Subject: PCsat 2 year anniversary.
From: Bob Bruninga <bruninga@usna.edu>
Date: Wed, 1 Oct 2003 12:15:52 -0400 (EDT)
X-Message-Number: 26
We declared mission success when PCsat lasted a week.
Today is the beginning of the 3rd year of operation.
PCsat just came over and is OPS NORMAL and remains available for all users
since her last recovery on 13 Sept...
I see 50 users in the last 2 days on http://pcsat.aprs.org
Bob Bruninga
USNA Ground Station
----------------------------------------------------------------------
Subject: Re: The new APRS n-N paradigm
From: "Scott Miller" <scott@opentrac.org>
Date: Wed, 1 Oct 2003 09:33:07 -0700
X-Message-Number: 27
I was just looking at the CENCA band plan yesterday... last updated in 1996.
About all it says is to avoid frequencies below 438.00 to avoid interference
with ATV.
I'll have to scrounge up some (non-ATV) 440 hardware myself. It'd be
interesting to set up an experimental Linux digi somewhere more accessible
than the nearest mountaintop for testing.
Scott
N1VG
----------------------------------------------------------------------
Subject: Re: LANn-N Experiment
From: Bob Bruninga <bruninga@usna.edu>
Date: Wed, 1 Oct 2003 12:28:30 -0400 (EDT)
X-Message-Number: 28
Here is how you can experiment with LANn-N in your existing area WITHOUT
breaking anything useful that is already in use:
On Wed, 1 Oct 2003, Bob Bruninga wrote:
>You could experiment with the LANn-N concept without impacting any current
>users, because most people dont use TRACEn-N anyway. (and those that
>do use it greater than about 3 irritate us!)
>
>So simply get some of your sysops in your LAN area to remotely change
>their UITRACE parameter to XXXn-N and experiment.
>
>(Of course, not until you disable WIDEn-N will you see the benefits, but
>it wouldnt hurt to start implementing the XXXn-N underneath and slowly
>moving people over to it.. then some day, turn off WIDEn-N and then see
>the great results for your LAN...
de WB4APR, Bob
----------------------------------------------------------------------
Read previous mail | Read next mail
| |
