| |
ZL3AI > APRDIG 03.10.03 09:41l 279 Lines 11018 Bytes #999 (0) @ WW
BID : 2071-ZL3AI
Read: GUEST
Subj: TAPR Digest, Sep 30, 14/16
Path: DB0FHN<DB0RGB<OK0PPL<DB0RES<ON0AR<WB0TAX<N1UAN<ZL2BAU<ZL3VML
Sent: 031002/1457Z @:ZL3VML.#80.NZL.OC #:9568 [Chch-NZ] FBB7.00i $:2071-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
Subject: Re: Digipeater Duplicate Checking is broke
From: "Tim Cunningham" <tim_cunningham@mindspring.com>
Date: Tue, 30 Sep 2003 17:26:53 -0500
X-Message-Number: 68
>>1) there will always be some collisions.
>>2) There will always be some success from DIGI A just about everywhere
>>3) There will always be some success from DIGI B just about everywhere
>
>I guess I'm not following how this is supposed to work. You've got two
>digis equidistant from a fixed station. Both digis have zero DWAIT. A
>mobile somewhere between them is picked up by both digis, and digipeated at
>the same time, give or take a 200 msec in TXD difference. The fixed station
>has a pretty constant multipath situation. How does it ever see ANYTHING
>from EITHER digipeater?
You are correct it is physically impossible, because they will trash each
others packets. If they make it to another WIDE digipeater outside your
range, then you will never decode it. I think physics rules here and that
is a problem with the old DWAIT parameter and one of the reasons Persist
and Slot were implemented. That is, to avoid the packet collision.
Using DWAIT to avoid dupes does not seem rational when the dupe checking
algorithms are suppose to do that function.
----------------------------------------------------------------------
Subject: Re: aprsnews digest: September 29, 2003 = overblown math
From: "Tim Cunningham" <tim_cunningham@mindspring.com>
Date: Tue, 30 Sep 2003 17:36:36 -0500
X-Message-Number: 69
>>A protocol even better than WIDEn-n would be a great start.
>
>I know Im the new guy around here but why dont we do something that the
>physical wire guys have been doing for years on 'shared' ethernet media.
>CSMACD
>
>Each digi does a random 'back off' before retransmission of a packet. If
>it hears another digi send the message they were going to send out it
>incriments the 'number' and transmits as scheduled. If it has come to the
>end of the requested path (WIDE3-3 for example) the packet gets thrown in
>the trash.
>
>Sorry if Im not using the write APRS protocol terms..like I said..Im new
>to APRS...not new to network technology.
>
>-Tyler
We call a similar implementation of that Persistence and Slot Time in the
packet world. It does exist, but it is not being advocated from what I am
reading in the APRS world..
Persistence is a number from 0 to 255 where 127 represents a 50%
probability that channel access will be attempted. This is derived from
a random number generator. The higher the number the greater the
probability.
Slot time is typically a number between 0 to 255 specifying time in
100ms increments that specifies the delay between attempts to access
the channel.
Back in the 80's DWAIT was an acceptable method for digipeaters
because that is all we had to seize the channel. It caused problems in
some areas. Hence, the Persist and Slot method was implemented in
these cases to solve the packet collision between digipeaters.
It helps if adjacent digipeaters use the same numbers for the Slot Time
method.
Tim - N8DEU
----------------------------------------------------------------------
Subject: Re: The bottom line, simply [was:***New*** TRACEn-N...]
From: Bob Bruninga <bruninga@usna.edu>
Date: Tue, 30 Sep 2003 20:00:40 -0400 (EDT)
X-Message-Number: 70
On Tue, 30 Sep 2003, Ev Tupis (W2EV) wrote:
>Bob Bruninga wrote:
>>Nationwide traveler: RELAY,WIDE2-2
>
>Isn't this really the issue? The APRS world would work if e-v-e-r-y-o-n-e
>simply launched RELAY,WIDE2-2. Remember the chant from last year?
>"RELAY,WIDE2-2 in 2002!"
>
>I believe that the best path is actually RELAY,TRACE2-2 but who am I? :)
But we dont even want 3 hops in many cases, so RELAY,WIDE is the same as
RELAY,WIDE1-1 anyway. but your TRACE idea is exactly why I am so excited
about my NEW LANn-N using UITRACE...
Because TRACE3-3 is really a GREAT universal path... but there is the
TEMPTATION for many many people to set TRACE3-3 and more and more. BUT
that is what MY LANn-N idea is all about.
Because it is a LOCALLY named LAN-N and it does TRACE functions, then
it CANNOT be overloaded or aboused, because in a LANn-N network with say
12 digipeaters, named OURSn-N will workt he same with OURS3-3 or OURS7-7
and there is NO futher damage to anyone. Every OURSn-N digi gets ONE
copy and NO OTHER COPIES go anywhere else.
That is why this LAST *** NEW *** LANn-N idea of mind using the UITRACE
parameter solves everything. Furhter TRACE7-7 will no longer work and so
it wont hurt anything either!
>Is it possibly just this easy?
Yes, absolutely. But you see most people dont seem to understand...
>Nothing to buy and plenty is fixed.
Yep. A great fix overnight...
Bob, WB4APR
----------------------------------------------------------------------
Subject: Re: ***New*** TRACEn-N (LANn-N) Paradigm
From: "Scott Miller" <scott@home.miller.org>
Date: Tue, 30 Sep 2003 17:34:18 -0700
X-Message-Number: 71
I'm just saying that people do it now. I don't want to xxxx off users in
either direction by not passing traffic through.
-----Original Message-----
From: bounce-aprssig-31505@lists.tapr.org
[mailto:bounce-aprssig-31505@lists.tapr.org]On Behalf Of WA8LMF2@aol.com
Sent: Tuesday, September 30, 2003 3:36 PM
To: TAPR APRS Special Interest Group
Subject: [aprssig] Re: ***New*** TRACEn-N (LANn-N) Paradigm
In a message dated 9/30/2003 12:47:59 PM Pacific Daylight Time,
scott@opentrac.org writes:
>fall of Central California
>does this, how do we get packets from Southern California to Northern
>California?
The 1200 baud 144.39 channel IS ALREADY SATURATED in both Southern and
Northern CAL. It is unrealistic to expect to propagate data reliably from
one overloaded network to another overloaded network 300 miles away! The
last thing each end of the state needs is more QRM from the other end!
Stephen H. Smith wa8lmf (at) aol.com
Home Page: http://wa8lmf.com
Ham Radio/Mobile SSTV page: http://members.aol.com/wa8lmf/ham
APRS Stuff
http://members.aol.com/wa8lmf/aprs
----------------------------------------------------------------------
Subject: Re: Digipeater Duplicate Checking is broke
From: "Scott Miller" <scott@home.miller.org>
Date: Tue, 30 Sep 2003 17:33:28 -0700
X-Message-Number: 72
I'm with Henk - I think the overlapping footprint of the digis is larger
than my direct RX range, especially considering terrain down here in the
valley. At least two digis are likely to hear any decent mobile signal, and
a large portion of what I get from those digis gets trashed.
----------------------------------------------------------------------
Subject: Re: Take Control of your DIGI part 4
From: "Spider" <spider@rivcom.net>
Date: Tue, 30 Sep 2003 17:39:13 -0700
X-Message-Number: 73
From: "Bob Bruninga" <bruninga@usna.edu>
To: "Spider" <spider@rivcom.net>
Cc: "TAPR APRS Special Interest Group" <aprssig@lists.tapr.org>
Sent: Tuesday, September 30, 2003 6:50 AM
Subject: Re: [aprssig] Re: Take Control of your DIGI part 4
>Ah, but if a mobile uses the generic path of RELAY,XXXXX and he is
>driving near one of your WIDE only digis, then he is out of the network
>even though he is under a digi. That is why all digis have to do
>RELAY...
Well, back to my other common rule.....if you are in range of a WIDE you
should 'not' use RELAY to get to it if you can use WIDE yourself and get to
it.
There are always exceptions and 'what-if's but I would stick to this rule.
Jim, WA6OFT
----------------------------------------------------------------------
Subject: Re: Take Control of your DIGI part 4
From: "Bill Vodall WA7NWP" <wa7nwp@jnos.org>
Date: Tue, 30 Sep 2003 17:42:06 -0700
X-Message-Number: 74
>Henk, what are DIGI_NED's requirements for RAM and program space? Is there
>any chance that it could be squeezed into an embedded platform, like maybe a
>KPC-3? How much OS-dependent stuff has it got?
>
>Scott
>N1VG
The comments a day or so ago about using a Palm device triggered an
interesting thought. It would be a good project to get Digi_ned running
on an older Palm device.
Bill, WA7NWP
----------------------------------------------------------------------
Subject: RE: Random backoff
From: "Scott Miller" <scott@home.miller.org>
Date: Tue, 30 Sep 2003 17:56:02 -0700
X-Message-Number: 75
>Just further disintigration of the 144.39 APRS network that COULD work
>reliably everywhere at ANY time if people would just understand that it is
>a LOCAL network for LOCAL use. Yes, you can spin off all kinds of ways to
We're seeing a constantly increasing number of stations. It's really not
hard to reach the 50-station limit with a single big event.
>split the traffic and split the load. But HOW WILL YOU USE THIS at a
>local event which is COME-AS-YOU-ARE...
Everyone knows about APRS channels A, B, and C. Pick one. Only the digi
sites have to invest in multiple receivers.
>Now you ae also giving up real-time...
Ok, so if 'real-time' is that critical, and APRS is only ever near real-time
anyway, hold on to the packet for a few seconds and see if you've got
something else to piggyback it on.
>Bingo. But if your intent is to get it to the IGatge, whats wrong with
>having the IGate get it from 144.39. Bingo! Thats what we have now.
Because what portion of the time can you get to the IGATE with a single hop?
Less than 100%, I'm certain. Even here in CA, it's been proven that 2 hops
doesn't get you in from everywhere. If it can get in locally, great. If
not, keep it from flooding the network all the way down the line and just
inject it into your backbone stream.
>and it works well. Put an IGate where ever it is needed and get users to
>stop trying to FLOOD the 144.39 network with DX packets..
Someday we'll have broadband at every hilltop, but it's not there yet. I'm
not sure they can even spell DSL in parts of West Virginia. =]
>Now that will have completey broken the user network by making DIGIS only
>let APRS be used for what a few SYSOPS define is impmortant. THAT NEVER
>WORKS IN HAM RADIO...
Nope, I'm just saying you stop making the users figure out how to make the
network do what they want, and just let them tell it what they're trying to
accomplish. Leave in source routing if you must, but don't make it the
default. You can still source-route IP packets, though it's rarely done for
a legitimate reason these days.
>But yes, the only way to insure more traffic on RF is to bundleit all to
>UHF at 9600 baud as I have been proposing since 1997 or so... but back to
>reality. Lets fix 144.39 now.
How about we do what we can with what we've got, and start accepting the
fact that it's still not going to cut it in the long term. Stop thinking
about deploying KPC-3+ digis, and start thinking about embedded PCs that can
be reprogrammed and upgraded remotely.
Scott
N1VG
----------------------------------------------------------------------
Read previous mail | Read next mail
| |
