| |
ZL3AI > APRDIG 04.10.03 11:17l 226 Lines 9722 Bytes #999 (0) @ WW
BID : 2085-ZL3AI
Read: GUEST
Subj: TAPR Digest, Oct 01, 10/11
Path: DB0FHN<DB0RGB<OK0PPL<DB0RES<ON0AR<ON0AR<WB0TAX<W4JAX<VK4TUB<ZL2BAU<
ZL3VML
Sent: 031003/1417Z @:ZL3VML.#80.NZL.OC #:9645 [Chch-NZ] FBB7.00i $:2085-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
Subject: Re: RELAY,WIDE,WIDE
From: Earl Needham <needhame@yucca.net>
Date: Wed, 01 Oct 2003 16:39:40 -0600
X-Message-Number: 65
At 09:22 AM 9/17/2003 -0500, Mark Cheavens wrote:
>In West Texas (North) where there are many KPC-3's Relay is NOT allowed.
>(because of packet duplication bug, see my previous email).
Regardless of the reason, this puts those digis out of spec. See
DIGIS.TXT, dated September 2001:
> APRS satisfies its real-time, emergency tactical needs without prior
>knowledge by using generic TO and DIGI callsigns. ALL APRS stations
>are given the generic digipeater callsign alias of RELAY and all digi-
>peaters are aliased as WIDE. This way any station can use any digpeater
>by using an UNPROTO path of WIDE or he can use any other station as a
>digipeater by simply addressing the packet VIA RELAY. With this generic
>digipeating, a mobile, or new station does not have to know anything
>about the network in advance in order to be seen by adjacent nodes.
>After 10 minutes and his map begins to show the location of all stations
>and digipeaters on frequency, he can then customize his outgoing Unproto
>path to specific digipeater callsigns to cover his intended area without
>as much QRM.
7 3
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: 10975WU/7.13yrs!
----------------------------------------------------------------------
Subject: RE: Correctly IDing weather stations
From: "David Odom" <dodom@mindspring.com>
Date: Wed, 1 Oct 2003 20:18:11 -0400
X-Message-Number: 66
I believe the reason the FCC Rules require a call sign is to identify the
transmitter. They are not interested in the network. Each transmitter
stands alone and must be identified according to the rules..
Dave
W4VOR
----------------------------------------------------------------------
Subject: RE: APRS Linux digi, was: Re: DigiNed, was: Re: Take Control of your
DIGI part 4
From: "Scott Miller" <scott@home.miller.org>
Date: Wed, 1 Oct 2003 17:38:26 -0700
X-Message-Number: 67
>Are they using the AMD chip? I thought they were ending production on
>those. It should not make too much difference, interesting that there are
>still people producing 486 based systems. Not that there's anything wrong
>with that.
Well... sort of. They're using the NS Geode, which just got sold to AMD.
http://www.national.com/appinfo/solutions/0,2062,396,00.html. Keep in mind,
this is a single-board computer intended as an embedded communications
controller, not a desktop motherboard. =]
>Debian is about as good as it's going to get if you don't want to cut
>corners. I think you might be able to squeeze a base install into 128
>megs. I dunno though, I don't use Debian.
Yeah, I use Debian on i386 and Alpha platforms. Not sure how small it'll
go, but I think I saw a mini-Debian someplace.
>Actually I've not had much of a problem corner cutting. I've learned
>quite a bit about the kernel and shells in the process.
Very true. I've done more trimming with OpenBSD than Linux, but I know the
basics.
>Kernel. What do you need and what don't you need. Some stuff is fairly
>obvious to trim, others not. Likewise, pick a baseline. Support 486
>procs, anything newer will work without the added features. That's not
>the end of the world. This project is built to meet a certain need and
>processor support is not an issue (read, proc / chipset speed).
Doing this once isn't a big deal. Doing it again and again is something I
don't want to commit to. Hence, the search for a distro which would be a
good fit for the target platform, so I don't have to do everything myself.
Scott
N1VG
----------------------------------------------------------------------
Subject: Re: New Mexico LANn-N?
From: "Ev Tupis (W2EV)" <w2ev@arrl.net>
Date: Wed, 01 Oct 2003 20:37:43 -0400
X-Message-Number: 68
Bob Bruninga wrote:
>I think they have a well defined area of interest in their state. Here is
>how the new LANn-N paradigm might work in such an area:
>
> - Make all digis of interest use UITRACE NM <=supports the NMn-N net=>
> - Leave WIDEn-N ON in the first few tiers of digis radiating outward from
> - ALbuquerque so that WIDEn-N can still be used easily within their area
> - On the OUTER BOUNDARY of all digis under their control, convert
> the UIFLOOD paramater from WIDEn-N to something else or off.
You have just created an "APRS firewall". Consider this...
----Arizona---|--------New Mexico----------------------------------------
WIDEn-N NMn-N NMn-N NMn-N WIDEn-N WIDEn-N WIDEn-N
WIDEn-N NMn-N NMn-N NMn-N WIDEn-N WIDEn-N WIDEn-N
WIDEn-N NMn-N NMn-N NMn-N WIDEn-N WIDEn-N WIDEn-N
WIDEn-N NMn-N NMn-N NMn-N WIDEn-N WIDEn-N WIDEn-N
WIDEn-N *SAR* NMn-N NMn-N WIDEn-N Albuqueque WIDEn-N
WIDEn-N NMn-N NMn-N NMn-N WIDEn-N WIDEn-N WIDEn-N
WIDEn-N NMn-N NMn-N NMn-N WIDEn-N WIDEn-N WIDEn-N
WIDEn-N NMn-N NMn-N NMn-N WIDEn-N WIDEn-N WIDEn-N
WIDEn-N NMn-N NMn-N NMn-N WIDEn-N WIDEn-N WIDEn-N
WIDEn-N NMn-N NMn-N NMn-N WIDEn-N WIDEn-N WIDEn-N
An emergency (*SAR*) presents itself near "the firewall". Amateurs from
Arizona converge on the scene, only to find out that their RELAY,WIDEn-N
doesn't cut it. They realize that NMn-N is the thing to do...but when they
change to that, they lose the ability to talk with Az to the west.
What should they do? APRS is about emergency/tactical communication.
Somebody is going to be in a world of hurt. There's too much thinking that
has to take place.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Imagine instead that the APRS network stays as it is and New Mexico has
well-place APRSniffer's (a theoretical plug-in that sniffs TX's unproto
paths, compares them against the path that New Mexico hams feel is
appropriate and sends APRS messages to folks who exceed it).
All Digi's support TRACEn-N and RELAY and all users TX via RELAY,TRACE2-2
(assuming that's the NM 'standard'). Now *SAR* occurs, amateurs from
everywhere converge and get to work saving life, limb or property rather
than trying to figure out how to set their UNPROTO. As a matter of
fact...they may even wish to setup for RELAY,TRACE6-6 during the event for
some reason...and they'd be able to.
TRACEn-N makes messaging extremely efficient. When they first power up
with RELAY,TRACE4-4, they get a message from the local APRSniffer saying
"Guys...we support RELAY,TRACE2-2 here, please be a good network neighbor
and change your UNPROTO." They ignore it. Three days later they are
either done or they get another message, etc.
The new paradigm should be the development of automated APRSniffers that
tell people the correct UNPROTO for a given area, while leaving the network
as it is for special cases if/when they present themselves.
Regards,
Ev Tupis, W2EV
----------------------------------------------------------------------
Subject: Re: LANn-N Experiment
From: "Tim Cunningham" <tim_cunningham@mindspring.com>
Date: Wed, 1 Oct 2003 19:08:01 -0500
X-Message-Number: 69
>1) IE, how many surrounding digis would consider themselves to be part of
>the North Alabama LANn-N network? What would be the typical length of
>most LANn-N hops?
At the present time that would be Moulton, Wilson Mountain, Huntsville,
Scottsboro, and Fort Payne. There may be 2-3 others or which 2 would be
cooperative and 1 unsure.
>2) Are there any linear pipelines that could be converted to linear chains
>of LINKn-N digis?
The linear pipeline could extend from Fort Payne from the east to Moulton
over to the west at the present time.
>I see about 15 digis in 80 miles and that covers about 100 users.
>Probably it should not go as far as birmingham. But I wonder what Lookout
>mountain thinks? I dont think they could belong to tan ATLANTA LANn-N
>beacuase it would be saturated.
Cullman would likely be the farthest south that boundary would extend.
Lookout Mountain is a little far north to be in the Atlanta area.
>You could experiment with the LANn-N concept without impacting any current
>users, because most people dont use TRACEn-N anyway. So simply get some
>of your sysops to remotely change their UITRACE parameter to NALAn-N
>and experiment.
Actually I am planning on exploring the implementation as an experiment for
another reason at the moment, but I am game. We have one UIDIGI to upgrade
to the latest firmware to fix a dupe issue. We also have to set Persist=255
and Slot=1 to effectively come close to a DWAIT=0 scenario since UIDIGI
does not employ DWAIT. I set one of the digis to do that last night. I have
access to the digis listed above to make the changes just about any time
remotely from here. So, they are easily manageable and configurable for
experimenting..
>(Of course, not until you disable WIDEn-N will you see the benefits, but
>it wouldnt hurt to start implementing the NALAn-N underneath and slowly
>moving people over to it.. then some day, turn off WIDEn-N and then see
>what results...
That is easy enough to do, but I need a few weeks to warn the users to
prepare for a change. This should be no problem since most of them are
very compliant and adaptable to changes.Even then, the message can be
posted on the digis to announce in the posit and/or status message.
73's,
Tim - N8DEU
----------------------------------------------------------------------
Read previous mail | Read next mail
| |
