| |
ZL3AI > APRDIG 03.10.03 09:39l 218 Lines 9536 Bytes #999 (0) @ WW
BID : 2065-ZL3AI
Read: GUEST
Subj: TAPR Digest, Sep 30, 8/16
Path: DB0FHN<DB0RGB<OK0PPL<DB0RES<ON0AR<WB0TAX<N1UAN<ZL2BAU<ZL3VML
Sent: 031002/1426Z @:ZL3VML.#80.NZL.OC #:9562 [Chch-NZ] FBB7.00i $:2065-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
Subject: RE: How to locate someone?
From: "Cap Pennell" <cap@cruzio.com>
Date: Tue, 30 Sep 2003 12:25:18 -0700
X-Message-Number: 31
Their temperature and today's precipitation are about right for the posit,
but the barometric pressure's too low.
And it's probably not a ham. Probably a civilian running a misconfiguration
in WeatherDisplay (or equivalent) software with the Davis Vantage Pro wx
station on the internet only.
http://www.jfindu.net/near.asp?Latitude=42.78&Longitude=-85.63
I know, not much help. Sorry.
73, Cap KE6AFE
----------------------------------------------------------------------
Subject: Re: Take Control of your DIGI (3)
From: Bob Bruninga <bruninga@usna.edu>
Date: Tue, 30 Sep 2003 15:25:47 -0400 (EDT)
X-Message-Number: 32
On Mon, 29 Sep 2003, Tim Cunningham wrote:
>Callsign substitution does not eleiminate any dupes in todays network
>where UIDIGI or Kantronics is employed.
Sorry, tim, this is just plain wrong. Callsign substitution correctly and
ALWAYS will not duplicate a packet that the same digipeatr has already
digipeated. This is fundamental dupe elimination.
BUT, I agree, it will not eliminate the dupe caused if TWO digipeaters
hear the SAME original packet from a station. But as I have said over and
over, this dupe is either killed by fratricide (if sysops have not screwed
up the D-WAIT parameter) or even in the worst case, it GOES NO FURTHER
than the original digis that duped it. It WILL not further propogate in
the 2 hop generic system I propose like it goes out for hundreds of copies
in the totally broken WIDEn-N flooding systems...
>... With your plan, we must tolerate dupes now.
Absolutely. Some dupes were part of the mechanism for assuring reliable
local delivery in a widely varying multipath environment. But there is a
world of difference between the 1 or 2 dupes that you will see ONLY in
the local vicinity of the originator under the originally designed APRS
system (which will not further propagate) compared to the 11 copies you
are seeing in the EXISTING system that is based on FLOODING the network
with everything heard.... We must break that paradigm and get on with
designing our network to cover our ALOHA nets RELIABLY and not QWRMing
beyond that point.
de WB4APR@amsat.org, Bob
----------------------------------------------------------------------
Subject: Re: aprsnews digest: September 29, 2003 = overblown math
From: "Jeff Thomas - KD4EVB" <kd4evb@hotmail.com>
Date: Tue, 30 Sep 2003 15:27:10 -0400
X-Message-Number: 33
How about a little more fact, versus intentional or unintentional fictional
& exagerated math (not backed up with any real world rf capture data as
usual) that only serves to confuse the topic even more:
>From Bob's post ot APRS News on the 28th:
>What's Wrong with WIDEn-N Routing and How to FIX it!
>WIDEn-N FLOODS equally in ALL directions with dozens if
>not almost 200 copies. We can no longer afford this QRM
>in our network. If each digi can hear 3 others, here is
>the resulting number of COPIES at each HOP:
>
> SETTING 1st 2nd 3rd 4th 5th 6th 7th TOTAL
> ------- --- --- --- --- --- --- --- -----
> WIDE1-1 3 3
> WIDE2-2 3 6 9
> WIDE3-3 3 6 12 21
> WIDE4-4 3 6 12 15 36
> WIDE5-5 3 6 12 15 21 57
> WIDE6-6 3 6 12 15 21 24 81
> WIDE7-7 3 6 12 15 21 24 30 111
>
>That's bad enough. But in many cases digipeaters can
>easily hear 4 other digis. Then the numbers become:
>
> SETTING 1st 2nd 3rd 4th 5th 6th 7th TOTAL
> ------- --- --- --- --- --- --- --- -----
> WIDE1-1 4 4
> WIDE2-2 4 12 16
> WIDE3-3 4 12 20 36
> WIDE4-4 4 12 20 28 64
> WIDE5-5 4 12 20 28 36 100
> WIDE6-6 4 12 20 28 36 44 144
> WIDE7-7 4 12 20 28 36 44 52 196
First, off a packet sent to WIDE1-1 only gets digipeated once by the digi
that hears it, not 3 times (or 4 times). The packet is DEAD after that
first digi regardless of how many digi's hear that digipeated packet. The
only way to create 3 or 4 packets with WIDE1-1 is to either send it 4 times
(grin) or have 3 or 4 digi's hearing the transmitting station direct. Thus
the math scaling on this is looking a lot worse than it is, and I think the
errors in it are pretty obvious once you look at it. Never mind the fact
that a good chunk of the remaining numbers are assumming a perfect rf
network reception, no collisions, etc etc. It 'taint a perfect world.
I think once we look at how this math is derived, the errors in scaling are
way off and it's not even an arguable point (although I'm sure some will try
to argue it). I'm not going to get into any further discussion of the above
math, it's clearly wrong upon examination, it's very assuming,
counterproductive, and misleading if taken at face value (as many likely
will take it). Thus:
I say opinions are fine and needed to a degree on this list, but wthout
"real rf world" data captures to back them up, they deserve very limited
credibility in terms of deciding if it's fact or fiction. Till we get
beyond this non-data backed up discussion, we're just spinning our wheels
here and the in the real world of rf the problem remains:
1. Users using bad paths.
2. Users with too high tx rates
3. Overloaded channel
4. Need of a better path protocol and/or considerable reworking of WIDEn-n.
Those 4 points are pretty much where this discussion was 2 years ago, and it
appears to be were we're likely going to be this time next year. We've got
to start dealing with what is really going on at the rf level versus what is
perceived to be going on, that requires DATA not opinions or unsubstantiated
math.
The one thing I notice, no one denies we've got a problem on 144.390. The
unanswered question (at least answered with data to back up
opinions/assertions) is how do we as the APRS community fix it. We can set
here and argue opinions, feed our egos, and so on till the cows come home
and make ZERO progress. Otherwise we look like Democrats and Republican
politicians all fussing about how the other is or proposes to do something,
but never offering up any real solution themselves.
I'll be the first to admit I don't have the solution myself either. I've
got a few local 'stop gap" ideas for our local rf network for the time
being, but even they are just temporary and server to just "cover" the real
problems up like many other ideas I've seen here.
Yeap, I'm obviously biased FOR widen-n as being the closest thing to a
halfway decent protocol for todays APRS needs. Yeah it needs to be "suped
up" and made a lot more configurable for each areas needs, but it's a start
in the right direction. We're hams, we're supposed to be innovators, let's
forget egos and personal agendas and start working towards fixing this issue
for a change. A protocol even better than WIDEn-n would be a great start.
I know, easy to say there Jeff :-)
73 de Jeff, KD4EVB
www.qsl.net/kd4evb
----------------------------------------------------------------------
Subject: Alinco DR610, using it for voice and tracker
From: bob evinger <wd9eka@evinger.com>
Date: Tue, 30 Sep 2003 14:38:52 -0500 (CDT)
X-Message-Number: 34
I have been driving around with a old kenwood behind the seat as a tracker
radio when it finally hits me that my DR610 up front might be usable. Have
not got the books out on it yet, but has anybody set one up to use one
side for tracking using the "packet" connectors on the back to feed audio,
or are those connectors strictly for 9600 baud. Would be nice if I could
just leave the one side on 144.39 and use the other half for voice.
Anybody done tried it?
bob
--
Bob Evinger EMT-I WD9EKA/AAR5MG(Army MARS operator)
If Guns Cause Crime, Then Matches Cause Arson.
----------------------------------------------------------------------
Subject: Re: ***New*** TRACEn-N (LANn-N) Paradigm
From: "Scott Miller" <scott@opentrac.org>
Date: Tue, 30 Sep 2003 12:45:37 -0700
X-Message-Number: 35
>MODIFIED proposal for LANn-N operations that solves ALL problems...
That's pretty ambitious of you...
>1) TUrn off WIDEn-N in all areas that cannot afford to be seeing
> anythign beyond 3 hops without flooding the network
So where does that leave us, in an area where we don't have enough digis to
have a separate perimiter and local network? If all of Central California
does this, how do we get packets from Southern California to Northern
California? I suppose if you've got enough digis to allow a WIDEn (LINKn?
CALn?) corridor between the two, that's fine... but the reality is there
aren't enough digis to cut any out and still have a reliable path, IMO.
>4) Notice that a SINGLE digi can now BOTH support LINKn-N, and LANn-N AND
>is no longer vulnerable to WIDEn-N flooding from out of area!!!
And if the people here on the list - presumably the ones with the most APRS
knowledge - can't keep straight what path to use where, what are the chances
that the average user will?
I hope the techniques you've described will be of use somewhere, but I don't
see that it's going to do us a lot of good here.
Scott
N1VG
----------------------------------------------------------------------
Read previous mail | Read next mail
| |
