| |
ZL3AI > APRDIG 19.09.06 21:52l 194 Lines 7605 Bytes #999 (0) @ WW
BID : 8754-ZL3AI
Read: GUEST
Subj: [APRSSIG] Vol 27 #11, 3/3
Path: DB0FHN<DB0MRW<OK0PPL<DB0RES<ON0AR<IW2OAZ<ZL2BAU
Sent: 060913/2145Z @:ZL2BAU.#87.NZL.OC #:3955 [Waimate] $:8754-ZL3AI
From: ZL3AI@ZL2BAU.#87.NZL.OC
To : APRDIG@WW
Message: 20
Date: Mon, 11 Sep 2006 08:20:56 -0400
From: Steve Dimse <steve_at_dimse.com>
Subject: Re: [aprssig] APRSDepot.com
On Sep 11, 2006, at 7:35 AM, john b. leonard, jr. wrote:
>Outstanding work! Thanks. I put W9JBL-9 in there, and immediately I could
>see where the digis didn't hear my sig. I was using a 5 watt ht.
I must caution everyone about data derived from the APRS Internet System
for propagation and network studies.
The APRS-IS was designed for the purpose of distributing the data payloads.
Duplicate filtering removes packets at every point within the APRS IS (and
to a limited extent on RF) to keep the bandwidth usage as low as possible.
It is estimated that only a tenth of the packets heard at IGates' TNCs are
seen by clients on the APRS IS. None of the payload data is filtered, but
perhaps 90% of the digipeater and IGate recipient data is filtered.
If the filtering were random, an argument could be made for treating the
data as a sample, with error bars determined by statistical means.
Unfortunately, the data is VERY non-random, and non-random in a way that is
dependent on impossible to quantitate factors. At each point, the first
packet to arrive will have its entire packet forwarded. Two clients
connected to different APRS IS hubs will see different digipeater and IGate
info, dependent on digipeater delay times, RF propagation, internet
propagation, and the exact interconnections present in the APRS Internet
System.
Any data source which has 90 percent of its data removed in a non- random
way cannot be depended upon. Use this data with care and with full
awareness of its shortcomings. For example, the above use is fine, looking
for places where a single transmitter was not heard, because this is based
on the payload data. This same information is available on APRSworld,
jfindU, and findU among others. On the other hand, using this site to see
whether a particular digi or IGate covers an area is not an appropriate
use, there are systematic reasons that a packet transmitted in a given
position could always be seen on the APRS IS via a different digi or IGate.
Steve K4HG
------------------------------
Message: 21
Date: Mon, 11 Sep 2006 07:28:02 -0600
From: Joel Maslak <jmaslak-aprs_at_antelope.net>
Subject: Re: [aprssig] Recommended IGate Connection
On Sep 11, 2006, at 5:19 AM, Jason Winningham wrote:
>On Sep 10, 2006, at 11:08 PM, Joel Maslak wrote:
>
>>I'm running an IGate for a relatively small geographic area
>>(transmit path of WIDE2-1, considering shortening even more to one
>>specific named WIDE).
>
>WIDE2-1 is a one hop path; the only way to get it shorter is to
>transmit with an empty path, direct only.
>
>WIDE is a one hop path element, obsolete in most areas. WIDE2-1
>(or WIDE1-1) is the "newN-N paradigm" equivalent.
Actually, I meant to say I'd be using the actual call of the digi I'd be
interested in (a digi that kind of sits in a hole with me, versus WIDE2-1
which hits both that digi and one on top of a very tall mountain).
------------------------------
Message: 22
Date: Mon, 11 Sep 2006 08:49:29 -0500
From: "AE5PL Lists" <HamLists_at_ametx.com>
Subject: RE: [aprssig] Recommended IGate Connection
>-----Original Message-----
>From: Joel Maslak
>Posted At: Sunday, September 10, 2006 11:11 PM
>Subject: [aprssig] Recommended IGate Connection
>
>Right now, I use aprsd (2.2.5 I think). I'm using the
>following to connect to the internet stream in the aprsd.conf:
>
>Server rotate.aprs.net 23 hub-sr
>
>I'm not sure I'm using the prefered port (or other options
>for that matter).
>
>What's the current recommendations for systems like mine? I
>want to support message traffic to my local RF users, but
>less bandwidth for the upstream server would be a good thing
>if it doesn't impact my local users.
If you are using aprsD as only an IGate, have it connect to port 14580 on
the servers. This is minimal bandwidth but fully supports messaging. You
can also use javAPRSSrvr which gives you the ability to add filters to the
upstream login if you want to see certain other things. javAPRSSrvr is free
for amateur use by emailing to me directly at pete_at_ae5pl.net (not my
list address).
73,
Pete Loveall AE5PL
mailto:pete_at_ae5pl.net
------------------------------
Message: 23
Date: Mon, 11 Sep 2006 08:53:04 -0600
From: Tom Russo <russo_at_bogodyn.org>
Subject: Re: [aprssig] GPS Display of D700 stations
On Mon, Sep 11, 2006 at 04:05:02AM +0300, we recorded a bogon-computron
collision of the <oh2kku_at_iki.fi> flavor, containing:
>Curt Mills wrote:
>>On Sun, 10 Sep 2006, Tapio Sokura wrote:
>>
>>>I have one of those yellow eTrexes and it accepts waypoints via $GPWPL
>>>just
>>>fine. If it doesn't work for you, it might be due to the software/hardware
>>>version of the GPS or the length of the waypoint name.
>
>>Someone came up to me at the NWAPRS summer gathering yesterday and
>>had one of these units. There was no option on the screen for
>>setting it to NMEA IN/OUT mode. Just NMEA OUT.
>
>Mine has the following settings for I/O format:
>GARMIN
>GARMIN DGPS
>NMEA
>TEXT OUT
>RTCM IN
>RTCM/NMEA
>RTCM/TEXT
>NONE
>
>The NMEA setting has worked for me. On startup it says "1999-2002 Garmin
>Corp. Multi-Lingual" and the software version is 2.20. Maybe there is a
>"single-lingual" version as well that doesn't support NMEA input.. Also
>looking at the Garmin changelog for the multi-lingual version, NMEA
>waypoint input was implemented in software version 2.04.
>http://www.garmin.com/support/download_details.jsp?id=89
I got my eTrex very shortly after they were released, in 2000.
I think my eTrex has (US) version 2.10 of the software --- I updated it in
2001 a year or so after buying it because of a few annoying missing
features (like "projected waypoints" and an informative satellite
acquisition screen) that were fixed in that revision. I haven't tried
updating since. When I tried it before it couldn't do waypoint plotting.
I have an eTrex Venture that I used with my D700, and saved the yellow
eTrex for my TinyTrak instead because of the waypoint issue.
I will hose the thing up to a computer and try it again to be sure, then
upgrade to the latest software (version 2.14, according to Garmin's site)
and try yet again. It may very well be that this is entirely a software
revision issue. There is certainly no mention of adding GPWPL support in
the release notes on Garmin's site when I went to:
and chose the "download" link next to version 2.14. That took me to a
slightly different URL than you gave:
Perhaps the feature was added but didn't make it into release notes for the
English-only version. Comparing the two release notes, it looks like
version 2.10 of the English-only version is roughly the equivalent of
version 2.03 of the Multi-lingual version, and of the changes noted for
version 2.04 of the multi-lingual version only the "prevents excessive
number of trackpoints" change is shown for version 2.11 of the English-only
version.
*shrug*
--
Tom Russo KM5VY SAR502 DM64ux http://www.swcp.com/~russo/
Tijeras, NM QRPL#1592 K2#398 SOC#236 AHTB#1
http://kevan.org/brain.cgi?DDTNM "And, isn't sanity really just a one-trick
pony anyway? I mean all you get is one trick, rational thinking, but when
you're good and crazy, oooh, oooh, oooh, the sky is the limit!" --- The
Tick
------------------------------
aprssig mailing list
aprssig_at_lists.tapr.org
https://lists.tapr.org/cgi-bin/mailman/listinfo/aprssig
End of aprssig Digest, Vol 27, Issue 11
Read previous mail | Read next mail
| |
