| |
ZL3AI > APRDIG 06.10.03 09:17l 248 Lines 9240 Bytes #999 (0) @ WW
BID : 2097-ZL3AI
Read: GUEST
Subj: TAPR Digest, Oct 03, 1/4
Path: DB0FHN<DB0RGB<DB0MRW<DB0SON<DB0SIF<DB0EA<DB0RES<ON0AR<ZL2BAU<ZL3VML
Sent: 031005/1242Z @:ZL3VML.#80.NZL.OC #:9818 [Chch-NZ] FBB7.00i $:2097-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
TAPR APRS Special Interest Group Digest for Friday, October 03, 2003.
1. Re: APRS Linux digi, was: Re: DigiNed, was: Re: Take Control of your DIGI
part 4
2. Re: The APRSteward SPAM filter [was: New Mexico LANn-N?]
3. RE: Random backoff
4. Re: The APRSteward SPAM filter [was: New Mexico LANn-N?]
5. GPS kid tracking in Japan
6. Re: GPS kid tracking in Japan
7. Laptop PCMCIA GPS Units
8. Re: The APRSteward SPAM filter [was: New Mexico LANn-N?]
9. Re: APRS Linux digi, was: Re: DigiNed, was: Re: Take Control of your DIGI
part 4
10. Re: Even cheaper GPS receivers
11. Re: The APRSteward SPAM filter [was: New Mexico LANn-N?]
12. Re: APRS Linux digi, was: Re: DigiNed, was: Re: Take Control of your DIGI
part 4
13. RS DigiTraveller wiring
14. Re: The APRSteward SPAM filter [was: New Mexico LANn-N?]
15. Re: The APRSteward SPAM filter [was: New Mexico LANn-N?]
16. Re: APRS Linux digi, was: Re: DigiNed, was: Re: Take Control of your
DIGI part 4
17. Re: The APRSteward SPAM filter [was: New Mexico LANn-N?]
18. Re: The APRSteward SPAM filter [was: New Mexico LANn-N?]
19. Re: Even cheaper GPS receivers
20. Re: Even cheaper GPS receivers
21. New Address
22. Re: Even cheaper GPS receivers
23. W1KFR-9 Trip
24. Yuma Ham Honored by NWS
25. Re: Even cheaper GPS receivers
26. Y-Cable?
----------------------------------------------------------------------
Subject: Re: APRS Linux digi, was: Re: DigiNed, was: Re: Take Control of your
DIGI part 4
From: Henk de Groot <henk.de.groot@hetnet.nl>
Date: Thu, 02 Oct 2003 22:48:09 +0200
X-Message-Number: 1
Hello Curt,
At 09:26 2-10-03 -0700, Curt Mills, WE7U wrote:
>As far as flash, make sure you minimize writes to the filesystem
>and/or use a flash filesystem underneath so that you "walk" the
>writes across the flash system. If you don't do that you'll end up
>replacing your flash too often 'cuz it'll wear out.
In Linux you can make in-core filesystems, if you worry about the flash and
feel unshure, create such a filesystem and start DIGI_NED from there. I
guess these systems do not have any swap partition, that would ware out the
flash very fast and it obviously doesn't make sense to have a swap
partition in core...
It makes sense to make an in-core filesystem for /tmp to catch all the
write activities for temporary data. The only other writes will be to the
/var filesystem, not much can be done about that except carefull planning
which programs should run. You cannot make /var in core unless you can
affort to loose the contents of /var after a reboot.
DIGI_NED only writes when file-writing is included in an invoked query,
when updating the satellite two-line kepler elements and of course if you
log the digipeating activity.
Kind regards,
Henk.
----------------------------------------------------------------------
Subject: Re: The APRSteward SPAM filter [was: New Mexico LANn-N?]
From: Henk de Groot <henk.de.groot@hetnet.nl>
Date: Fri, 03 Oct 2003 12:43:28 +0200
X-Message-Number: 2
Hello,
At 18:43 2-10-03 -0400, Ev Tupis (W2EV) wrote:
>What XXXn-N misses is the human factor. Why is WIDE7-7 a problem? Not
because
>of WIDEn-N technology, but because 7-7 is "bigger" than "2-2", so "it
must be
>better". The problem isn't the network, it's uneducated people.
Also WIDE7-7 is too easy to set up. If you had to specify
WIDE,WIDE,WIDE,WIDE,WIDE,WIDE,WIDE
then you "naturally" feel that it is over the top. (Note: I use "you" just
to address operators in general, don't take it personal!). I think people
will know that they do something wrong when they specify this. When you
specify WIDE7-7 then it still looks small; it doesn't look excessive until
you expand it to its WIDE equivalent.
If WIDE2-2 is not a problem but WIDE7-7 is, why not just refuse to take any
WIDE7-x packets? Oh wait, I see... you can't.
In the last 4 years that I read the APRSSIG the inability to actually do
what you want to do, because the existing TNC hardware doesn't allow it,
has been a millstone around the neck. Just because you cannot instruct most
digis to pass WIDE1-x and WIDE2-x and block WIDE3-x or worse the latest
"cure" is to shutdown WIDEn-N completely. It may be prossible to block
WIDE3-x or worse by patching the Kantronics EPROM. But since the DMCA
doesn't allow you to analyse their PROM and their Copyright does not allow
you to distribute slightly modified versions of their PROM (even if the
receiver has the original and paid for its use) you are stuck.
There are plenty more of these examples since this problem is recurring
over and over again. You keep running into a brick wall and it is about
time to tear the wall down.
I think the root cause of all the problems is not user education or ill
attempts do fix the network and breaking some fundamental thing along the
way. I think the root cause is a complete technology standstill. This is
not APRS specific, it happens everywhere and the normal response to this
would be to let the old system wear out and start a new system from
scratch, not burdened by the history that caused the standstill of its
predecessor.
Unless a miracle happens I don't see how APRS can ever be fixed. It's
FUBAR. Too many people are holding on to their installed base and current
operating practice. Every new idea will divide the operators more and more
since some will go along with the new idea and some will not. Its becoming
more and more fragmented and harder and harder to operate and use. Stop
beating a dead horse and focus on breeding a new one.
I think that is the human factor here...
Kind regards,
Henk.
----------------------------------------------------------------------
Subject: RE: Random backoff
From: "hasan schiers" <schiers@netins.net>
Date: Thu, 2 Oct 2003 10:55:00 -0500
X-Message-Number: 3
Our entire network is composed of two kinds of smart digi's:
UI-Digi stand alone's with smart digipeating
UI-View32 with smart digipeating
UI-Digi is stand alone and as Henk noted, has no DWAIT. It is the VAST
MAJORITY of our digi network, with UI-View32 smart digi'ing from some
selected home stations filling in the blanks.
Anything that depends on DWAIT=0, or advocates only using tnc's and firmware
that support DWAIT, is taking a BIG STEP BACKWARDS.
Let's all take a deep breath...
I cautioned earlier about the "law of unintended consequences" when
advocating the large changes being discussed. Several people have
contributed observations regarding these unintended consequences.
The one thing we CAN do, without unintended consequences, is user education.
Any approach/patch/recoding/repathing that does not place PRIMARY focus on
user education, coooperation, and compliance is doomed to the dustbin of
history....and what's worse...we'll be having another flavor of the month
"network redesign" again, next year.
Again, if you are driving through Iowa and a digi is available (esp from
I-35 North to I-80 West of the center of the state and most everywhere in
between, the following alias's are fully supported:
WIDEn-n
TRACEn-n
RELAY
WIDE
IA
IOWA
Recommended mobile path:
Relay, WIDE2-2 or
Relay, TRACE2-2
Recommended home path:
WIDE3-3 or TRACE3-3
This is based on:
1. A reliable national standard
2. Our topography
3. Our station density
4. Our distribution of digi's/coverage
It works, it is watched. Welcome one and all.
(Repeated abuse of path length (no matter what form) will get ya in the bit
bucket)) We have NEVER had to do this....maybe because we actually talk to
each other. <g>
....hasan, N0AN
----------------------------------------------------------------------
Subject: Re: The APRSteward SPAM filter [was: New Mexico LANn-N?]
From: wes@johnston.net
Date: Fri, 03 Oct 2003 08:35:55 -0400 (EDT)
X-Message-Number: 4
The new horse is opentrac! Scott is doing a great job with it... the first
tracker is on the air! http://www.opentrac.org/drive.jpg (I can't hit this
link this morning for some reason, but it's there!)
www.opentrac.org
Just to highlight some of the things which have caught my interest about
open trac....
1) it uses a heiriacial icon structure... Don't have an icon for a jeep,
back up one level on the "tree" and your client program will use a car
instead. Don't have an icon for an RV? The client will use a truck
instead.
2) a compressed posit report which is accurate to about 6 inches world wide
and is shorter than MIC-e.
3) advanced digipeater functions which allow packets to only propogate
outward AWAY from the source.
4) No characters in the packet are used depending on "context"... the packet
can be comprised of many chunks of data in such a way that no two elements
are mutually dependent... and if your client program doesn't know how to
handle a certain element type, it will skip over it and continue to process
what it can out of the packet.
5) UTF-8 alternate (multi byte) character set... at last an aprs format
which supports cryllic and kangi.
6) room for over 60,000 data elements.
7) able to be encoded by a simple PIC processor - can be done with mic-e,
but uses up all your program space.
Wes
----------------------------------------------------------------------
Read previous mail | Read next mail
| |
