| |
ZL3AI > APRDIG 30.09.03 10:53l 264 Lines 10076 Bytes #999 (0) @ WW
BID : 2028-ZL3AI
Read: GUEST
Subj: TAPR Digest, Sep 27, 4/7
Path: DB0FHN<DB0RGB<OK0PPL<DB0RES<ON0BEL<ON0AR<N2BQF<W4JAX<KD4GBA<ZL2BAU<
ZL3VML
Sent: 030929/1349Z @:ZL3VML.#80.NZL.OC #:9306 [Chch-NZ] FBB7.00i $:2028-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
Subject: Re: APRS Grass growing...
From: "Ken Brown" <W2KB@comcast.net>
Date: Sat, 27 Sep 2003 10:58:06 -0400
X-Message-Number: 16
Coupled with the decay, it should be re-emphasized to have the home station
digipeat as a relay. I've been on business trips and tried the D7 from a
hotel room to no avail on relay or wide. Finally, when a home station
beaconed, I used that call and got out fine. Waiting up to 30 minutes to
get the info can seem like forever. But everyone setting relay avoids the
issue.
---Ken
----------------------------------------------------------------------
Subject: Re: APRS Grass growing...
From: Bob Bruninga <bruninga@usna.edu>
Date: Sat, 27 Sep 2003 11:20:00 -0400 (EDT)
X-Message-Number: 17
On Sat, 27 Sep 2003, Steve Jones wrote:
>Participating in a net is a two way street. Just beaconing every 10
>minutes is a one way transmission that might or might not be received at
>net control. Relying on this one way transmission as indicating a
>station is active is foolish.
>
>If you really want to check the status of all stations in the net then I
>would suggested a directed aprs query to such stations. If the station
>does not respond then mark it questionable until the next directed
>query. If it does not respond after the 2nd (or 3rd etc) query then
>mark it as off air.
Sorry, such an approach viloates the KISS principle and also violates the
"principle of least astonishment" and BESIDES it DOUBLES the number of
packets to accomplish the original job!
>Perhaps the best way to do this is some sort of setup where you can list
>the stations participating in the net and be able to query only those
>stations with a quick key/mouse click. Stagger the beacons so you don't
>have a massive query reply coming back at you.
Wow, MORE complexity, MORE things that a USER can screw up, MORE things for
a USER to do...
APRS is simple. If you are on the air, you periodically send a single
packet to keep the net aware of your status. APRS was founded on the
principle of KISS.
de WB4APR, Bob
----------------------------------------------------------------------
Subject: More Complexity-Yes, was Re: APRS Grass growing...
From: "Georgette Sampson" <georgette.sampson@cox.net>
Date: Sat, 27 Sep 2003 10:54:21 -0500
X-Message-Number: 18
>Wow, MORE complexity, MORE things that a USER can screw up, MORE
>things for a USER to do...
That's what hobbies are for!
Future Project:
Maybe the whole concept of the digipeater is too simple for sophisticated
position reporting systems, and thus a continual source for deviant
behavior?
Maybe a "Net Control Station" NCS and "Participant Unit" PU system is
needed. Sort of like the Mode-S in ATC, or the old TADIL systems. Basically
an NCS station can send out an "All Call" and PU's pick a random number to
delay transmission of a time-slot request over (say) the next minute. Then
this process is repeated again in (say) 10 minutes. The "All Call" can
also send out a list of time slots that it knows about (which a PU can
compare to its own) and thus only new PU's will need to request a
time-slot. Also, after polling a time-slot x number of times and not
getting a response, the slot can be deleted.
If you want to join the net, and there are no time slots left, then you
don't get a PU slot, and you go to another frequency, or just listen, and
wait for a slot to open-up.
So a mountain NCS just sends polls to time-slots, and PU's reply with a
frame of data (maybe needing 2 frames to complete long data) that the NCS
repeats:
NCS-POLL0->PU-DATA0->NCS-DATA0->NCS-POLL1->
Two modes that I can think of, is to 1) transmit the reply data before
each poll, or 2) transmit all of the reply data at once (FEC included).
The only reason I bring this up, is that maybe the free-for-all digipeater
builders need an automated (more sophisticated, more complex) project? This
wouldn't work very well for fast moving repeaters, or NCS regions with
(say) more than a hundred PU's, but could work well in backbone
(Internet/UHF) connected NCS stations.
Film at 11...
Jo
----------------------------------------------------------------------
Subject: Re: Part 2/2 -Re: Take Control - oh let's just go backwards
From: "hasan schiers" <schiers@netins.net>
Date: Fri, 26 Sep 2003 09:16:01 -0500
X-Message-Number: 19
----- Original Message -----
From: "Bob Bruninga" <bruninga@usna.edu>
To: "TAPR APRS Special Interest Group" <aprssig@lists.tapr.org>
Sent: Thursday, September 25, 2003 12:14 PM
Subject: [aprssig] Re: Part 2/2 -Re: Take Control - oh let's just go
backwards
Bob (wb4apr) said:
>When it in fact is just continuing down that dead-end street
>that APRS CANNOT TOLERATE EVERYONE SENDING WIDE5-5 or >WIDE7-7!
This gets at the crux of the matter. I don't think we can effectively cure
the problem when we depart from the source of the problem, i.e., the
offending users.
It still seems to me to be a draconian solution to turn off WIDEn-n and
TRACEn-n.We worked very hard to get rid of "dumb" digipeating....we just get
it accomplished and now we are told to go back to dumb wides. I've watched
the effect of dumb wides on our network....one packet sent, SEVEN
retransmissions. Another dumb wide sent, FIVE retransmissions. Same station
same RF path: one packet sent, (at WIDE3-3), at MOST 4 retransmissions, and
often, just the 3 they were interested in.
Since we have a smart network, ostensibly, using dumb wides should not dupe
and loop. (All digi home stations and all firmware digis are running either
UI-View32 (home smart digi) or UI-Digi 1.9x (firmware dedicated digi)).
However, what I have noticed is that a station using RELAY, WIDE, WIDE
(mobile) or WIDE,WIDE (home) triggers off multiple retransmissions that are
truely excessive, while the same stations using RELAY, WIDE2-2 (mobile) or
WIDE3-3 (home) produce many fewer retransmissions.
Locally our mobiles use the path:
RELAY, WIDE2-2
Home stations (who are trying to keep network clutter down) use:
WIDE3-3 or TRACE3-3 (if network analysis is a goal) (notice no dumb wide)
Home stations who are trying to do part of what Bob suggests are running:
WIDE, WIDE2-2 or WIDE, TRACE2-2
We had a local discussion that went something like this:
"Now that we have dupes and loops cured by our smart network software, we
can go back to the use of dumb wides again, and it should work."
I don't know why this isn't true here, but it's not. As soon as we start
going dumb again, the traffic load jumps up dramatically. If it did work,
then turning off WIDEn-n would be an option.
================================================
None of this solves the WIDE7-7 problem, without creating a new problem.
We really are back to user education, user compliance, or eventually user
exclusion.
=================================================
Where we are now seems to work very well for us:
We (the major digi stations/nodes) all support:
RELAY
WIDE
WIDEn-n
TRACEn-n
IOWA
IA
Dumb wides/relay of more than one hop are strongly discouraged.
(RELAY, WIDE, WIDE or RELAY, WIDE) but RELAY,WIDE2-2 is fine as is NO
RELAY, just WIDE3-3 or TRACE3-3. Our network handles this just fine.
Home users don't need any dumb wides, but may use ONE.
(WIDE3-3 is fine, WIDE,WIDE2-2 is fine, but less so)
No path longer than 3 hops is acceptable. (we know what our network does)
============================================
What Bob said is quite correct:
"When it in fact is just continuing down that dead-end street
that APRS CANNOT TOLERATE EVERYONE SENDING WIDE5-5 or WIDE7-7!"
In our area, turning off WIDEn-n and going with just dumb wides, does not
appear to be the answer. User education and enforcement does appear to work.
We have yet to even have to "threaten" enforcement. Once the "agreed upon"
practices have been defined, COMMUNICATED and implemented, we have gotten
compliance.
Given we have absolute control of the digi network (via cooperation and
potential coercion), any user who chooses to do a WIDE5-5 or greater, after
being properly consulted, goes in the bit bucket.
There is no solution that ignores the central part users play in this
problem, that has ANY chance of working.
hasan, N0AN
p.s. Let's not talk about what happens when the band really opens up on
144.390. There's nothing one can do about that either, but at least it's
transitory. I have seen raw packet counts of 460 in 10 minutes during
multi-hour band openings. They were not being caused by WIDE7-7's either,
although, as Bob rightly points out, longs paths only make things worse.
----------------------------------------------------------------------
Subject: Re: Part 2/2 -Re: Take Control - oh let's just go backwards
From: "hasan schiers" <schiers@netins.net>
Date: Fri, 26 Sep 2003 09:30:46 -0500
X-Message-Number: 20
Bob said:
"Yep, its easy. Either get the users to cut back their paths (has been
shown to never work) or turn off WIDEn-N at the digis that are
overloaded."
This has NOT been shown to never work. It's the ONLY thing that will work. I
do agree, if you cannot get compliance or effective control over your
network (a marginal way to set up a network in the first place, imho), then
yes, SOMETHING has to be tried...but what makes you think the very people
that are ignoring the long path problem are not going to try to get around
the missing WIDEn-n digi's? That should be interesting!
As an act of desparation, turning off WIDEn-n might be a last resort.
I don't think turning off WIDE or RELAY is a good idea at all...the
universality of APRS is being lost and we are throwing out the baby with the
bath water.
The THREE FACES of EVE:
One face wants to turn off WIDES in a fit of pique.
Another face wants to turn off WIDEn-n in an act of desparation.
The last face wants to gain control of the network so neither of the
previous two are needed. This choice requires the most effort, and the other
two won't work.
Go figure....
....hasan, N0AN
----------------------------------------------------------------------
Read previous mail | Read next mail
| |
