| |
ZL3AI > APRDIG 02.01.04 13:18l 256 Lines 10179 Bytes #999 (0) @ WW
BID : 2595-ZL3AI
Read: GUEST
Subj: TAPR Digest, Jan 01, 2/3
Path: DB0FHN<DB0THA<DB0ERF<DB0SON<DB0SIF<DB0GV<DB0ZDF<DB0GE<LX0PAC<LX0HST<
HA3PG<ZL2TZE<ZL3VML
Sent: 040102/1048Z @:ZL3VML.#80.NZL.OC #:15972 [Chch-NZ] FBB7.00i $:2595-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
Subject: Re: Trace Route on Findu?
From: Jeff King <jeff@aerodata.net>
Date: Thu, 1 Jan 2004 15:34:52 -0500
X-Message-Number: 11
You might try APRSWORLD also.
--
Jeff King, jeff@aerodata.net on 01/01/2004
----------------------------------------------------------------------
Subject: Re: Trace Route on Findu?
From: Steve Dimse <k4hg@tapr.org>
Date: Thu, 1 Jan 2004 16:14:13 -0500
X-Message-Number: 12
On 1/1/04 at 1:23 PM Earl Needham <needhame1@yucca.net> sent:
> Is there an easy way on Findu to show (on a map) what route my packets are
>taking to get from my station to an IGATE? Yes, I can read the raw packet,
>but a map showing the route would be helpful, in my opinion.
No, for a very simple reason...the APRS RF network, and to an even greater
extent the APRS Internet System, is optimized for tranmitting the data, not
for providing propagation info. For example, WIDEn-n does not show
intermediate digis, so even reading the packet won't work. Duplicate
packets are agressively removed in the APRS IS (and some digi software),
making it impossible to develop any picture of the "web" your packets would
actually form on the map.
If you elimiated WIDEn-n, ensured every digi ran with callsign
substitution, and eliminated dup checking from the APRS IS, you might be
able to draw some useful conclusions about the propagation, but the
internet stream would increase manyfold, and RF congestion would rise as
well.
Since you are running TRACE5-5, you can do it manually...
http://www.findu.com/cgi-bin/find.cgi?call=KD5XB-2
shows the packet as
KD5XB-2>APW272,MELROZ,CAPTAN,CAPILA,CREST*,TRACE5-2,qAR,W5MPZ-1:=3425.85N/10313.
56W-PHG7140/ -EARL_CLOVIS -272-<630>
cut out the path portion, delete the non-path data and do a find gives:
http://www.findu.com/cgi-bin/find.cgi?call=KD5XB-2,W5DIG-13,FTSUMN,ELKMTN,CREST,
W5MPZ-1
Since your path is a couple hundred miles long, it does not fit on the map,
it is centered on the last call, so move your call to the end to see the
start:
http://www.findu.com/cgi-bin/find.cgi?call=W5DIG-13,FTSUMN,ELKMTN,CREST,W5MPZ-1,
KD5XB-2
This could be done automatically, but it depends on people using TRACE,
which is discouraged, and shows only one path, most packets on the APRS IS
arrive by multiple paths, which one makes it to findU is determined by a
number of factors like RF and Internet delays and number of hops, it is not
random, but also not deterministic, making it impossible to draw
conclusions.
Since the data is very suspect, and it would encourage people to cause RF
congestion, I will not be implemented any such feature.
Steve K4HG
----------------------------------------------------------------------
Subject: Re: Trace Route on Findu?
From: Jeff King <jeff@aerodata.net>
Date: Thu, 1 Jan 2004 16:45:59 -0500
X-Message-Number: 13
Here is what I was thinking of:
http://aprsworld.net/data/igate-hops/
http://aprsworld.net/info/
you might want to ping James and see if he has done any further work along
these lines. One thing it does clearly show is areas that need an I-Gate
--
Jeff King, jeff@aerodata.net on 01/01/2004
----------------------------------------------------------------------
Subject: BPL?
From: Earl Needham <needhame1@yucca.net>
Date: Thu, 01 Jan 2004 16:48:43 -0700
X-Message-Number: 14
Remember the "Broadband over Power Lines" discussion a week or three ago?
Is BPL still in the works? I thought it wasn't approved yet, but I saw a
router at my local Radio Shack that purports to use your house wiring
instead of Cat5 cable.
Not the same thing, right? I hope...
Earl
Earl Needham, KD5XB, Clovis, New Mexico DM84jk
KD5XB-2>APW251,PCSAT-1%:=3425.83N/10313.55W-PHG7150/WinAPRS 2.5.1
-EARL_CLOVIS -251-<630>
SETI@Home: 11212WU/7.27yrs
----------------------------------------------------------------------
Subject: Re: BPL?
From: "Tim Cailloux" <tim@cailloux.com>
Date: Thu, 01 Jan 2004 19:10:12 -0500
X-Message-Number: 15
>Not the same thing, right? I hope...
Right, Powerline networking (what you saw in RadioShack) is different
from Broadband over powerlines. Whereas Powerline networking allows
10Mbps networking within your own home over your existing wires, BPL is
more like a service provider connection (think of the difference as
Powerline being your Cat5 and hubs/switches/router while BPL is like your
DSL or Cable modem connection to your ISP).
For some Powerline products, look at Linksys' offerings (the only ones I
have ever seen in action) at
http://www.linksys.com/products/group.asp?grid=34&scid=33
I've never used them but have friends that think it's pretty cool, if not
as useful as wireless (802.11b).
tim
--
Tim Cailloux
tim@cailloux.com
404-875-0778
----------------------------------------------------------------------
Subject: Re: BPL?
From: Mike Galgano <mgalgano@nanosecond.com>
Date: Thu, 01 Jan 2004 17:28:57 -0800
X-Message-Number: 16
Two interesting items on BPL:
The first is on using g-line technology. In the second, FEMA comes out
against BPL.
http://www.tvtechnology.com/dlrf/one.php?id=259
http://gullfoss2.fcc.gov/prod/ecfs/retrieve.cgi?native_or_pdf=pdf&id_document=65
51292045
MikeG - KB7PUX
----------------------------------------------------------------------
Subject: Re: Trace Route on Findu?
From: Steve Dimse <k4hg@tapr.org>
Date: Thu, 1 Jan 2004 22:39:16 -0500
X-Message-Number: 17
>http://aprsworld.net/data/igate-hops/
>http://aprsworld.net/info/
>
>you might want to ping James and see if he has done any further work along
>these lines. One thing it does clearly show is areas that need an I-Gate
Does it? What follows in not a criticism of James' good work, or any
particular person's analysis of the image, but to me this is a good example
of why you must be careful about drawing conclusions from APRS data.
One of the things I teach young doctors at the University of Miami is how
to critically analyse data, both in scientific papers and in the care of an
individual patient (as in lab data and history information). Most doctors
are able to make their way through 8 years of college and medical school
without this skill, it requires some knowledge of statistics, an eye for
unstated assumptions, and most importantly a healthy scepticsm, especially
of charts and graphs. People say statistics can prove anything, but people
are much more trusting of information when presented visually. The first
step in learning critical thought is to know your own biases, and
compensate (or better, over-compensate) for them.
There are two ways a map like this might show where an IGate is needed. No
data might get from a particular area, creating a blank spot on the map, or
there might be data requiring more hops.
To know if a blank space is real, you need to know that packets were
actually tranmitted from within the space. Obviously there will be huge
difference in the number of packets per square mile, and in California a
blank spot is more likely to represent an inihabited/untraveled area that
it is to represent an area with inadequate IGate coverage.
If you are looking for areas with high hop counts (yellow to red), the
first thing you must consider is how are the points plotted? If they are
drawn on top of each other (most likely) later points draw on top of older
ones...a point might have 100 1 hop packets, but if a single 3 hop packet
happened to occur last, the point will be colored yellow. What if an IGate
was down for 12 hours before the data was generated? Only if all the
packets from each point are pooled to arrive at a single color could you be
assured that the color is actually representative of the number of hops.
Are all satellite, HF, and direct internet packets removed from analysis?
(This is basically impossible, as there is no distinction between some of
these, for example a directly heard VHF and UHF packet.) The best you can
say is the vast majority of packets on the APRS IS are VHF, so they will
swamp the other modes, but again, unless you are averaging for each point,
this unfairly favors the last data transmitted.
Are the packet paths of all users set optimally? One guy with a manual path
of 5 local users might greatly lengthen paths in a give area. On the other
hand, a bunch of users with paths of simply WIDE will skew the data towards
single hops.
We are told that the data represents "the last few months" before
21-Jan-2003. Was the network stable during this time? Were there any
unusual propagation events during this time? Any special events with
temporary digis and IGates that might have resulted in a large number of
anomalous points in a given area?
Only if an adequate number of packets were sent from each location, and
only if all the above errors are eliminated, could you say the color
represents the actual number of hops required to reach the internet from
that particular location.
Even if we ignore all this, and just assume that each point is correctly
colored, we still have to be careful drawing conclusions.
It certainly is true that putting IGates in a yellow/red area will drop the
hop count, but does that mean an area needs a an IGate? What if an area is
served by a lot of low digis, and what is really needed is a high digi? A
blank spot, if not caused by desolation, is also likely to be indicative of
an RF problem rather than an IGate problem.
What if there already is an IGate in the yellow area, but for some reason
it has slower internet propagation (say it uses TCP over RF), and therefore
the packets with a longer RF path (which would normally be slower) are
getting to the APRS Internet System faster, and therefore are the ones that
survive dup-checking to appear in the database?
I probably could find more potential problems if I tried, but I think this
is enough to show that one should not draw blanket conclusions from this
image. It may well be a useful tool, that is something that needs to be
decided for the particular use after evaluating all the potential biases in
the data. You simply cannot trust something like this blindly.
Steve K4HG
----------------------------------------------------------------------
Read previous mail | Read next mail
| |
