| |
ZL3AI > APRDIG 14.05.07 01:02l 287 Lines 11103 Bytes #999 (0) @ WW
BID : 10174-ZL3AI
Read: GUEST
Subj: [APRSSIG] Vol 35 #6, 1/2
Path: DB0FHN<DB0FOR<DB0MRW<DK0WUE<SP7MGD<SR1BSZ<IW2OAZ<ZL2BAU
Sent: 070513/2257Z @:ZL2BAU.#79.NZL.OC #:47712 [Waimate] $:10174-ZL3AI
From: ZL3AI@ZL2BAU.#79.NZL.OC
To : APRDIG@WW
Today's Topics:
1. RE: APRS and the I-95 Corridor (Cap Pennell)
2. RE: APRS and the I-95 Corridor (Charles Doughtie)
3. Re: APRS and the I-95 Corridor (Joel Maslak)
4. Re: APRS and the I-95 Corridor (Jason D. Triolo)
5. DIGI_NED 0.3.9 (Henk de Groot)
6. [nwaprssig] Info on the UP Steam Train 844 / 3985
(rcluster_at_comcast.net)
7. APRS and the Interstates (Robert Bruninga)
8. RE: APRS Question (Robert Bruninga)
----------------------------------------------------------------------
Message: 1
Date: Sun, 6 May 2007 10:29:40 -0700
From: "Cap Pennell" <cap_at_cruzio.com>
Subject: RE: [aprssig] APRS and the I-95 Corridor
Ian N8IK wrote:
>For mobiles check that your path is WIDE1-1,WIDE2-1 and if really
>remote try WIDE1-1,WIDE2-2. That way the home RELAYs can respond. See
>http://www.ew.usna.edu/~bruninga/aprs/fix14439.html
>
>73, Ian N8IK
Yes, but very few places are _so_ remote that WIDE1-1,WIDE2-2 (three digi
hops in all directions) is required or helpful.
WIDE1-1,WIDE2-1 from a mobile or portable station is far better, with plain
WIDE2-2 (or less) enough from a home or Base.
http://web.ew.usna.edu/~bruninga/aprs/APRSpaths.gif
If it's so bad that 3 hops seem needed, adding a (WIDE1-1 ONLY) fill-in
digi, perched on a local high point, can help out those wayward mobile
stations. Using a fill-in digi on Point Sur last weekend, we operated the
(very remote) Big Sur Marathon trackers with good results, and the _mobiles
did not need any settings changed_ from their daily routines. For local
map display using APRS, we re-labeled the map symbols on the marathon
course with tactical calls. http://bsim.aprsca.net Worked swell!
For good reason, RELAY and WIDE and TRACE are obsolete, at least in North
America. Please don't become part of (or cooperate with) that old problem.
73, Cap KE6AFE
"Boilerplate text" follows:
To explain the only problem (and my only concern) for VHF APRS:
Our only big problem in APRS is coping with the "reduced throughput" that
adversely affects all the APRS users on our single 144.390 MHz national VHF
frequency. Because of the limited amount of available airtime ("bandwidth")
at 1200bps on the shared frequency, only so many packets can be decoded at a
given receiver, only one at a time. Any more than that simply "collide"
(share airtime) at the receiver. Usually none of those colliding packets
are successfully decoded by the receiving station (though _occasionally_ the
"FM capture effect" allows the strongest signal to get through). Most of
these collisions occur at high elevations between all the mountain-top
digipeaters which all hear each other over great distances up there. We
rarely notice many collisions because we can only hear one or two digis from
our individual low-elevation Valley or coastal QTHs. By themselves, these
collisions (reduced throughput) are not a big problem because (with APRS's
Unconnected protocol) the transmitting APRS station will try again in a
short while. But with so many users sharing the nationwide frequency, the
real problem crops up when we hams try so hard to compensate for the reduced
throughput we notice. Naturally, we are tempted to try to compensate by
setting broader digipaths, more frequent transmissions, higher power, and
putting up new digipeaters for "better coverage." These things usually only
make matters worse and tend toward a slow "death spiral" of the VHF network.
Tragedy of the Commons:
APRS suffers the classic fate of all limited resources as well documented
since the 1830's.
http://en.wikipedia.org/wiki/Tragedy_of_the_commons
Whenever there is a balance between individual interests and the common
good, human nature guarantees the overloading and ultimate demise of the
common resource. In this case, APRS throughput. This is easy to understand
since the benefit of adding one more packet to the network always
immediately benefits the SENDER, but the negative "cost" is spread over
everyone else. There is no natural solution, other than the establishment
of "Golden Rules" to live by for all concerned.
------------------------------
Message: 2
Date: Sun, 6 May 2007 12:39:34 -0700 (PDT)
From: Charles Doughtie <n5exy_at_yahoo.com>
Subject: RE: [aprssig] APRS and the I-95 Corridor
--- Cap Pennell <cap_at_cruzio.com> wrote:
>Ian N8IK wrote:
>>For mobiles check that your path is WIDE1-1,WIDE2-1 and if really
>>remote try WIDE1-1,WIDE2-2. That way the home RELAYs can
>respond. See http://www.ew.usna.edu/~bruninga/aprs/fix14439.html
>>
>>73, Ian N8IK
>
>Yes, but very few places are _so_ remote that
>WIDE1-1,WIDE2-2 (three digi
>hops in all directions) is required or helpful.
I was running WIDE1-1,WIDE2-2 for the trip between central Texas and
Midland-Odessa. From this experience, I doubt a three digi hop in any
direction is possible except at each end.
------------------------------
Message: 3
Date: Sun, 6 May 2007 14:11:05 -0600
From: Joel Maslak <jmaslak-aprs_at_antelope.net>
Subject: Re: [aprssig] APRS and the I-95 Corridor
On May 5, 2007, at 7:11 PM, Jason D. Triolo wrote:
>I'll be driving from Florida to Virginia at the end of June. Have
>most/all digi operators along the way converted to the new
>paradigm, or do I need to have some old settings on standby in some
>areas?
>
>I'm most unsure about North Carolina. After running into a R,W digi
>in Greensboro, I'm wondering if that digi was an exception, or if
>that's typical within the state?
If you're concerned about IGate coverage, this is what a mobile running
WIDE1-1,WIDE2-1 gets (good antenna, full power D700, set up hopefully
properly, big wire [small gauge power wiring causing even a 1 volt voltage
drop can halve your output power], etc):
http://www.findu.com/cgi-bin/track.cgi?
call=n7xuc-7&geo=usa.geo&start=10000
Beacon time is once every 3 minutes I believe.
This track history includes I-95 from Daytona Beech (turnoff for Orlando)
and almost into New York City (turned onto Thruway).
Places with the biggest gaps that I've driven are Nebraska, Eastern CO, TX
panhandle, Georgia (almost no coverage between Atlanta and Savannah), Ohio
(especially I-70). My most consistent surprise has been Iowa - great
coverage along I-80.
Some of these gaps may be lack of digi coverage (Western Nebraska) while
others have digi coverage but no IGate (Savannah, GA). Yet others may not
support WIDEN-n.
------------------------------
Message: 4
Date: Sun, 06 May 2007 16:25:35 -0400
From: "Jason D. Triolo" <jasonacg_at_citicom.com>
Subject: Re: [aprssig] APRS and the I-95 Corridor
Joel Maslak wrote:
>http://www.findu.com/cgi-bin/track.cgi?call=n7xuc-7&geo=usa.geo&start=10000
>
>Beacon time is once every 3 minutes I believe.
>
>This track history includes I-95 from Daytona Beech (turnoff for
>Orlando) and almost into New York City (turned onto Thruway).
That's a great illustration of the coverage. Thanks for that link. Looks
far better than I expected it would be.
73 de Jason, KD4ACG
www.fieldcomm.org/aprs
------------------------------
Message: 5
Date: Sun, 06 May 2007 22:43:56 +0200
From: Henk de Groot <henk.de.groot_at_hetnet.nl>
Subject: [aprssig] DIGI_NED 0.3.9
xastir_at_xastir.org
Hello,
Here is an update to DIGI_NED, version 0.3.9. DIGI_NED works fine
everywhere and since adding the AGWPE interface it is more or less finished
work.
Last week a bug report surfaced, the longitude degree value of the stations
position were all zero. This is code that has been in DIGI_NED for years.
It turns out that there is a bug in that code that is only visible when
using the new GCC 4.x compiler. So that is what's fixed now.
Note that this bug didn't only affect the stations position conversion, but
any conversion of ASCII positions. When this doesn work the DX function is
useless.
Now that I'm making a new package I also made some changes to the
digi_new.ini sample rule file for the new paradigm. High hopcounts are not
longer converted but are now ignored.
I posted the source and binaries to my website:
http://www.homepages.hetnet.nl/~pe1dnn
The floppy configuration has not changed, this version brings nothing new
for DOS, so it doesn't make sense to update the floppy at this time.
I did not update the Cygwin binary, that one whas compiled with an older
GCC and doesn't show the problem.
Here are the changes to DIGI_NED itself from the Changes.txt file:
Changes.txt
06-05-2007 version 0.3.9
- With the new GCC 4.x compiler a bug in extracting the location surfaced
that was not noticable with older compilers. I have not seen the problem
with DOS or Cygwin either, but is is definately a bug. This was found
by Josh, AB9FT. Thanks Josh for reporting it!
- Changed digi_new.ini, the rulefile for the new paradigm. It does not
convert high hopcount WIDEn-N to their WIDE2-N equivalent but ignores
high hopcount WIDEn-N paths now.
APRS[tm] is a Trademark of Bob Bruninga,
his home page is at "http://web.usna.navy.mil/~bruninga/aprs.html"
Kind regards,
Henk.
------------------------------
Message: 6
Date: Sun, 6 May 2007 23:12:47 +0000
From: rcluster_at_comcast.net
Subject: [aprssig] [nwaprssig] Info on the UP Steam Train 844 / 3985
Hi Tim,
Here's the email about the steam excursion. Link near the end of the
email.
Bob
------
The upcoming Pacific Northwest excursion will be pulled by UP 844 this
time, a 4-8-4 locomotive (same wheel arrangement as the SP 4449). They
have other trips planned this year also, some using the UP 3985 Challenger
steam engine. Thanks to Curt, WE7U, and the UP RR we have the chance to
keep tabs on the UP steam trips, regardless of which engine they are
using.
One of the passenger cars in the train is fitted with a GPS receiver that
sends the trains position and speed to the UP, which they use to update
the following web page:
Curt's script pulls the info from this page, reformats it to the correct
object format for APRS and injects it into the Firenet and APRS-IS data
streams at 10 minute intervals.
You can track it on your APRS maps if you include o/STEAM in your filter
string. If you are an iGate, you can gate this object to RF for mobile
stations to use. I'll be doing that when the trip actually starts on May
3rd. If there is anyone in the Portland, OR and the Seattle/Tacoma, WA
area that would gate out this object also it would be appreciated (by me
at least......I'll be out taking pictures again).
Basic route is Wyoming, Idaho, Oregon, Washington, and then return via the
same route. It will pick up the SP 4449 Daylight Steam engine in Portland,
OR for the run to Seattle and back. Big steam operations, let alone double
headed steam is pretty rare these days. If you're anywhere close to the
route, try to go experience it.
Detailed schedule is here:
73.....Ron.....AC7TK
(-9 Mobile, -7 hiking (D7),
-2 Wx, -1 Work....Sheesh)
UI-View32 iGate, Wx & WIDE1 digi
Eugene, OR
_______________________________________________
nwaprssig mailing list
nwaprssig_at_nwaprs.info
http://www.nwaprs.info/mailman/listinfo/nwaprssig
------------------------------
Read previous mail | Read next mail
| |
