| |
ZL3AI > APRDIG 30.09.03 10:54l 255 Lines 11513 Bytes #999 (0) @ WW
BID : 2027-ZL3AI
Read: GUEST
Subj: TAPR Digest, Sep 27, 3/7
Path: DB0FHN<DB0RGB<OK0PPL<DB0RES<DB0EEO<DB0GOS<ON0AR<ON0AR<N2BQF<W4JAX<
KD4GBA<ZL2BAU<ZL3VML
Sent: 030929/1344Z @:ZL3VML.#80.NZL.OC #:9305 [Chch-NZ] FBB7.00i $:2027-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
Subject: Re: APRS Grass growing...
From: Steve Jones <s.jones@rogers.com>
Date: Sat, 27 Sep 2003 09:23:15 -0400
X-Message-Number: 11
on 9/26/03 6:30 PM, Bob Bruninga at bruninga@usna.edu wrote:
>Besides the purpose of a HOME station Beacon is not necessrily so much as
>to show us his non-changing position, but more so to indicate that he
>still has power, and is participating in the NET. That is how HAM radio
>emergency and special event traffic nets work. The various participating
>stations check in now and then to indicate that they are still avaliable
>to handle traffic. WIthout this, no one in the net knows who is
>available or what constitutes the net.
We're really getting off topic here but you're forgetting something
important.
What about the station timeout setting on most aprs clients? What's that
supposed to be set at? Is the default enabled/disabled and what default
value is used for all the different aprs clients?
If I lose power and miss my 10 minute beacon, you will not see it unless
you've set your timeout timer to a lower value. If you've got your timer
set high then you will not notice my station has disappeared for quite a
while.
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.
Note that I said directed not just a general query. 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.
--
Steve <s.jones@rogers.com>
----------------------------------------------------------------------
Subject: Re: APRS Grass growing...
From: Bob Bruninga <bruninga@usna.edu>
Date: Sat, 27 Sep 2003 09:58:42 -0400 (EDT)
X-Message-Number: 12
>>Violates the KISS principle and gains nothing. Already a home station
>>is only transmitting once every 30 minutes. Why get the digi involved
>>in it?
>
>Except that a awful of of clueless users have houses (and stationary
>parked mobiles) beaconing FAR more frequently than this.
Thanks for offering me this stump:
What? In APRSdos users have no control over that. If their position
information does not change, then the period decays down to 30 minutes.
This was fundamental to the design of APRS, that all client software
would beacon new data immediately, and then decay the period by a factor
of 2 after every transmission so that NEW data was updated frequencly, but
older and older data would decay out of the system.
This has been one of my biggest frustrations about other client software
in that it does not have as its PRIMARY goal, the proper management of
data on the network. That is why the DECAYING algorithm was FUNDAMENTAL
to APRS. Some authors ignored these fundamentals and just implemented the
simple FIXED rate. This is totally unsatisfactory in my opinion for 2
reasons.
1) If users set a FIXED rate of say 30 minutes, then the network has up to
30 minute LATENCY in data. If the home station changes his POSIT text to
say add his phone number or to change his status, then the EOC might not
get that info for 30 minutes , or an HOUR if there was a collision...
That is NOT the design of APRS!!!!
In APRSdos, (and as APRS was designed) if someone changes his position
coment or status, it is transmtted immediately, then 8, then 16, then 32
then 1 minute later and so on down to eventually 30. THus everyone in the
LAN is assured of getting NEW data almost instanly, and OLD data does not
hang around long.
2) To compensate for the EXTREME latency and poor reliability of only
transmitting NEW information once every 30 minutes, I dont blame USERS for
moving their update rate up to something more TIMELY. That is the only
way that those client progrms allow the user to get his NEW data out.
BUT then the USER forgets to change it back to 30 minutes after his new
data gets old. So it is not the USER'S fault here, it is the CLIENT
software that FAILS to implement the FUNDAMENTAL APRS concept of Fast
updates of NEW data and decaying to 30 minutes of OLD data.
I have been complaining of this FUNDAMENTAL flaw of some client software
for now 8 years and (to my knowledge) it is still not fixed. It is
KILLING APRS as a reliable real-time communications system.
Fortunately, I think some newer programs have implemented the FUNDAMENTAL
decaying algorithm. I'd like to see a list of how the various client
programs handle updates so that we can start weeding out the ones that
make our networks unable to move NEW data reliably and clog our nets with
old data at high rates...
Bob, WB4APR
----------------------------------------------------------------------
Subject: Re: I guess we're going to agree to disagree Bob. Part 3 of hopefully 3
From: Bob Bruninga <bruninga@usna.edu>
Date: Sat, 27 Sep 2003 10:08:59 -0400 (EDT)
X-Message-Number: 13
On Sat, 27 Sep 2003, Vince wrote:
>btw - the biggest problem we had a couple years ago for the event in
>eastern NC were the few outside stations using WIDE5-5 or more txing every
>few minutes. Beyond them, APRS was pretty quiet in the area.
And that is why I am so excited about this simple option of reminding
SYSOPS that with some prior thought to an event, they can simply with ONE
remote sysop command, disable WIDEn-N in surrounding digis and in minutes
secure control over their local event area. Even if only temporarily.
In fact, I actually want to make sure that we ONLY do this where and when
needed. We want to KEEP WIDEn-N as a fundamental process for long haul
where it is needed. And with this NEW option in local areas, we now
realize we have a SIMPLE mechanism (using existing DIGI hardware) to
differentiate between local and long haul traffic.
Those people who like to "play radio" can use this to actually design
long-haul linear routes for WIDEn-N traffic that are far more efficinet
than the current flooding process. SEE NEXT MESSAGE...
Thanks
Bob, WB4APR
----------------------------------------------------------------------
Subject: Re: Another thought on reducing congestion in busy metro areas...
From: "Dick Stanich" <dick@kb7zva.com>
Date: Sat, 27 Sep 2003 9:20:32
X-Message-Number: 14
>The inexpensive (< $35) TinyTrak implements a far smarter tracker that can
>send the same position data (and a comment and full choice of symbol/overlay)
in>FAR less time AND will send far fewer beacons when the car is parked. Not to
>mention that it uses far less DC power, it's settings don't get lost every
>time the power hiccups, and that it frees up a much more expensive TNC for use
>elsewhere. And the absolutely free bonus that the shorter strings are a lot
>more likely to be received successfully!
>
>Should we start a crusade to stamp out TNC dumb trackers to reduce needless
>channel loading?
Yes, agreed. However, the crusade needs to go a little further. Like those
Igates still using versions of WinAPRS that converted Mic-E's placing
mobiles all over our maps, sometimes at warp speeds. This became obvious
when 700's popped up on the scene. It took years, it seemed like, to get
the Sprouls to change WinAPRS not to convert mic-e. By then, there were far
too many copies of WinAPRS out there. Still are. Watch out for those
APK101's :) and questions like, 'Why is my mobile jumping all over the
place?' and 'If you are going for a swim off the coast of Africa, please
use the correct symbol'. I wonder how many Kenwood's needlessly ended up
being returned for a warranty repairs?
Dick, KB7ZVA
APRSWest
----------------------------------------------------------------------
Subject: LINKn-N linear routing
From: Bob Bruninga <bruninga@usna.edu>
Date: Sat, 27 Sep 2003 10:49:06 -0400 (EDT)
X-Message-Number: 15
LINKn-N is another RADICAL new option we could use NOW...
In existing DIGI's, overnight...
In a previous message I said:
"In fact, I actually want to make sure that we ONLY use the WIDEn-N
SQUELCH option where and when needed to protect local reliability. We
want to KEEP WIDEn-N as a fundamental process for long haul where it is
needed. And with this NEW option in local areas, we now realize we have a
SIMPLE mechanism (using existing DIGI hardware) to differentiate between
local and long haul traffic.
Those people who like to "design systems" can use this to actually design
long-haul linear routes for WIDEn-N traffic that are far more efficinet
than the current flooding process."
HERE IS HOW:
The UIFLOOD parameter was intentionally not forced to WIDEn-N in ROM. It
was made a sysop parameter. Thus, there is nothing that prevents groups
of DIGI sysops from inventing LONG chains for the LINEAR distribution of
LONG-HAUL traffic to specific locations. For example the setting of
UIFLOOD SHORE 28,NOID would allow a series of digis along the low density
Eastern Shore to support SHOREn-N traffic from South Carolina to
Deleware. Or UIFLOOD NS would allow for a linear system of NORTH-SOUTH
digis along the Appalachain Mountain chain to route user packets
originated as WIDE,NSn-N as many as N hops along that chain.
Or we could name them after the long-haul interstates that are the
arteries of our country. A path of WIDE,I95n-N would propogate N hops
along I-95.
Converting from the damaging FLOODING of WIDEn-N in ALL directions to
LINEAR use of this powerful technique will DRASTICALLY reduce QRM, will
improve long haul reliability between point A and B, and this concept can
be implemented right now, today with existing hardware by simply sending
the remote sysop command to change the UIFLOOD parameter in existing
DIGIS. (remember that UIFLOOD ID must remain off).
NOTICE HOWEVER, that all of these digis MUST continute to support the
FUNDAMENTAL RELAY/WIDE call-sign substitution so that ANYONE within range
of these digipeaters can continue to use them NORMALLY for NORMAL APRS
local traffic. Again, we MUST get all digis to stop hacking away at APRS
fundamentals and keep the basics.
To NAME this new option, I will call it LINKn-N routing...
Ponder if your area has unique requirements that could use it.
Again, my overall goal is:
1) encourage the universal fundamental path of RELAY,WIDE for mobiles
and WIDE,WIDE for the vast majority of APRS use. And LOCAL
use and reliability. (User education works when there is ONE answer
that works everywhere)
2) Allow the use of WIDEn-N in vast open areas that can support it.
Users in those areas could still use WIDE,WIDE or they could use
WIDE,WIDEn-N
3) in special areas, consider these special linear LINKS to solve
unique problems where two remote areas do need reliable long
haul path between them, but dont want to flood all adjacent areas.
We MUST get the FLOODing in APRS under control. If we do, then APRS can
continue to work reliably as IS. (while we dream away at new networks of
the future)...
de WB4APR, Bob
----------------------------------------------------------------------
Read previous mail | Read next mail
| |
