| |
ZL3AI > APRDIG 17.09.03 21:32l 267 Lines 12222 Bytes #999 (0) @ WW
BID : 1930-ZL3AI
Read: GUEST
Subj: TAPR Digest, Sep 15, 7/10
Path: DB0FHN<DB0THA<DB0ERF<DB0BRI<DB0SIF<DB0EA<DB0RES<ON0BEL<ZL2BAU<ZL3VML
Sent: 030917/1419Z @:ZL3VML.#80.NZL.OC #:8565 [Chch-NZ] FBB7.00i $:1930-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
Subject: Re: Abusive Digi id paths Was: Can someone contact this guy?
From: "Spider" <spider@rivcom.net>
Date: Mon, 15 Sep 2003 17:30:42 -0700
X-Message-Number: 50
From: "Scott Miller" <scott@opentrac.org>
To: "TAPR APRS Special Interest Group" <aprssig@lists.tapr.org>
Sent: Monday, September 15, 2003 11:52 AM
Subject: [aprssig] Re: Abusive Digi id paths Was: Can someone contact this
guy?
>This reminds me of something I've been meaning to bring up. The local SAR
>team is really interested in getting equipped for APRS and setting up some
>RELAY digis for better backcountry coverage, in addition to the existing
>WIDEs.
APRS is an excellent tool in SAR. Couple of the FireNet team are into SAR.
>For actual local tactical use (like the network was designed for)
>I'd like to be able to command the digis under our control to refuse
>external traffic from beyond a certain range during SAR operations.
In my area, we do not limit traffic on an open public frequency. HOWEVER,
we use SAR for a digi name and the local Digi's digi on hearing SAR
locally, without going out to the WIDE or RELAY digi's. It keeps it local
for tactical operations in most cases. Midigation with local Node owners
can lead to them adding this name in their UIDigi names prior to an actual
search. If SAR is not enough, we can add WIDE or WIDEn-n to the path and
this works great!
> I think
>digi_ned can do this - maybe uidigi as well? How possible/practical is it
>to control these remotely?
If traffic needs to be limited, then odds are you need to QSY, IMHO.
Jim, WA6OFT
----------------------------------------------------------------------
Subject: Re: Abusive Digi id paths Was: Can someone contact this guy?
From: Bob Bruninga <bruninga@usna.edu>
Date: Mon, 15 Sep 2003 20:40:11 -0400 (EDT)
X-Message-Number: 51
On Mon, 15 Sep 2003, AE5PL Lists wrote:
>In a real emergency, APRS would be essentially useless beyond two hops
>with the level of activity that would be seen (at least in this area).
>This is regardless of whether someone uses directed paths or not. And,
>as stated below, people aren't going to be messing around with their
>paths in an emergency.
Well, then they better. If users are not adjusting their paths for
optimum during an emergency, then they are not practicing preparedness.
Then is when you want people to only direct their info where it needs to
be, not all over the place.
>You may encourage directed paths in your area, but because of the high
>usage rate and the knowledge that we have much more important things to
>do in an emergency, we encourage people to use short paths that will be
>effective for a tactical situation.
Thats what we are both saying. SHORT PATHS. But for traffic that has to
go 2 or 3 hops, they should sure be chosing a directed path. And the only
way to konw what is on the air is to have had the DIGIS that are out 2 and
3 hops having sent a W3-3 packet at some time in the recent hours so that
Emergency operators and NEW ARRIVALS on the scene know where those digis
are and how to set up these directed paths...
>In this area, that means no more than 2 hops.
Ah, I see, You are declaring that in an emergency, that there cannot be
any traffic for outside your 2 hop limit? Well, that seems short sighted
and exactly opposed to the basis for using APRS to get the data to where
it needs to go...
>We encourage directed paths as a standard for fixed operation, at least
>for the first hop. If the station sees that they are no longer being
>digipeated, guess what: that digi is down!
That is impossible to know beyond your local digi...
>They then fall back to trying either WIDE or RELAY depending on their
>location but they aren't going to be spending the next 10-20 minutes
>trying to figure out what path to use.
And that is exactly why they shouldnt be GUESSING. They should be looking
at their map and they should SEE what digis are on line. And the only way
to do that is to have digis send out a W2-2 or W3-3 once every several
hours...
>>recommendation was for
>>DIGIS and it was ONE 3-3 packet every 3 hours.
>
>I still stand by my statements that no one hundreds of miles away needs
>to know about a station (digis included) here or vice versa.
I have been told repeatedly that it takes 3 hops to go 90 miles or less in
Texas. Is DFW any better?
>Even in a connected network, we successfully proved during the 80's that
>relying on more than a couple of hops was optimistic at best using
>single frequency AX.25. With an unconnected protocol, it is even worse.
No, it is even better. Because you dont have the HOP-SQUARED problem
with ACKS. One way packets have a much better chance...
>>how emergency nets work. Nets HAVE to know what assets are available
>>and ON line in real time. It is not good practice to expect someone
>>to wait 30 minutes to see if the local digi is up..
>
>I know the local digi is up if I am getting digipeated. I don't need to
>see the digi beacon.
Really? If someone is using W2-2 then the packets arrive as W1-1 or W and
there is no digi info in there. SO you are then adding the additional
requiremnet for users to send PINGS with TRACE? THis again is poor net
planning if you want everyone to be always pinging to see what is out
there...
>And if there is a hole in coverage, it is pretty obvious. So, what's
>the solution? Move in one or more portable RELAY digis to fill the
>gap(s).
No, just look at the map (where the digis that are working have ID'ed
themselves) and use the ones that get the packet where it needs to go...
>>Yes for the casual user. But under stress, we want ALL users to then
>>look at their maps in detail and to CHOSE their paths in real time to
>>get any given bit of data to the intended recepient using the most
>>direct and
>
>In an emergency, these things are exactly what won't happen. There are
>far too many other things going on for a net control operator, a mobile
>operator, or other support operator to be messing with paths. It will
>be very obvious if there are holes in coverage.
I find that an amazing statement. How? How long to you stare at a blank
area of the map and how do you divine that the reason it is blank, is
because no one is in there? The power is out? Or the digi is down?
APRS is based on knowing who is on the air. And since DIGI's are the most
important aspect of the APRS infrastrucuture, they must ID to the users
that need to use them.
Once every 10 minutes local
Once every 30 minutes or so via WIDE
Once every N hours via something like 3-3
Im not trying to jam this down your throat, just hoping to prevent local
tweaks from overlooking some APRS fundamentals... If 3-3 is too much,
then 2-2, ok. But anything less, and you will have a blind network which
is practically useless when the lights go out...
>I disagree as stated before; this is overkill.
>
>>the power
>>goes out, turn on your laptop in the dark connected to an HT
>>on 144.39 and
>>see how much you would love to see what digis are STILL ON
>>THE AIR in real
>>time (remember they lose power too!)
>
>I won't be doing it that way. I will be firing up my Kenwood D7 and
>seeing if my packets are getting digipeated. If not, then the local
>digi is down. I don't need to hope to see a beacon from the digi to
>know whether the local digipeater is up or down.
What?!, we aren't talking about your local digi! You were arguing agaist
a once-every-3-hour W3-3 from other digis. How is your little D7 gonna
tell you how much of the surrounding DIGI infrastructure is still in
place???
>I am very familiar with emergency communications having been active in
>RACES and ARES since the early seventies in tornado alley. One thing
>that is very apparent from the emergencies that I have been involved
>with is the fact that radio communications are critical but are expected
>to be set up BEFORE the emergency occurs. Trying to modify paths, radio
>configurations, etc. during emergency communications only detract from
>the usability of amateur radio.
You still arent seeing the point. You have to know what is ON-LINE when
the emergency is called. Not what was on last week or last month which
was the last time you updated your static DIGI infrastructure map.
DIGI's are the key to the APRS network. You have to know in REAL TIME
which ones are on line...
de WB4APR, Bob
----------------------------------------------------------------------
Subject: Re: Abusive Digi id paths Was: Can someone contact this guy?
From: Mark Earle <wa2mct@mearle.com>
Date: Mon, 15 Sep 2003 20:23:51 -0500
X-Message-Number: 52
>DIGI's are the key to the APRS network. You have to know in REAL TIME
>which ones are on line...
>
>de WB4APR, Bob
Uhmm.. tweet tweet! (whistle sound).
I think your.. strong statements on both sides are because, Bob, you are
preaching the ideal, and Pete is preaching APRS as his group has decided to
use it. The two are not necessarily equal.
Also, at least from watching the Internet feeds, D7/700 users are the
minority of APRS users around Texas. So most users are NOT going to, in an
emergency, dynamically change the path of the tracker. Whatever is in there
before the emergency is called, is what is going to go on the air.
I am probably typical of this type of user. My Pic-E has wide3-3 as one
profile, and trace7-7 as the other. If it can't be done with one of those,
once the emergency hits, I am not going to have the time or resources to
mess with it. TinyTrack 2's do not have selectable profiles, and many TT
users have or won't move up to TT3's just to get this feature they may use
never or seldom use.
OK. my opinion.. as Pete notes, he can determine if his LOCAL digi is up or
down real time, even if it never IDs. Beyond that, what is he going to do
if the NEXT digi in the string is down? If it's not LOCAL to him, nothing.
It's up to someone LOCAL to the failed digi to go fix it, determine what's
wrong, etc. All any user can do at that point is change power, antenna,
and perhaps path. OR, "someone" if prepared, may throw up a temporary digi
to fill in the gap. But in the first few hours, I rather suspect voice
comms are going to be the priority. APRS can show the guys at NWS where the
spotters are, but if APRS goes totally away, the job of spotting storms can
still be done. If voice comms are working, NWS will get the reports with
sufficient geographic data to tell what is going on where. Even in
locations with APRS, every net control has a good street level map, and
every spotter knows how to convey his position accurately without a GPS or
APRS gadget. In the NWS storm spotter model, and many other disaster comms,
I do not see APRS as the primary or only mode of comms. It is an adjunct to
multiple voice comms (FM Simplex, repeaters, HF, VoIP linking).
And to address a side comment about 3 digis conveying a packet 90 miles in
TX: with wide3-3, my packets are seen routinely in Austin (I reside in
Houston). That's about 180 miles away. I go through AI5TX-2, WR5AAA-6, and
AI5TX-7. Likewise, I see stations in Austin via RF all the time (my main
APRS station at the apartment is RF only). Is this ideal? No, far from it..
it would be better to have a few more digis lower. But, these proposed
digis have to be higher than most home stations. So, we use what we have..
trying to obtain sites is difficult. As we get them, we'll change the
networks config, when it makes sense to do so. But it is not going to
happen very fast. So for now we are sort of stuck with a few higher digis.
While not ideal, even with high channel loading, we have more capability
now than we did without these 3 relatively wide/ high digis.
NOTE: I am biased because of having a hand in getting all 3 on the air.
) ) de WA2MCT Mark
( (
) ) You will be assimilated... oooh, coffee!!
_|****| http://www.findu.com/cgi-bin/find.cgi?wa2mct-8 Home
( | | http://www.findu.com/cgi-bin/find.cgi?wa2mct-9 Mobile
`|____| wa2mct@mearle.com wa2mct@juno.com www.mearle.com/mark
----------------------------------------------------------------------
Read previous mail | Read next mail
| |
