| |
ZL3AI > APRDIG 19.11.03 19:59l 217 Lines 9170 Bytes #999 (0) @ WW
BID : 2323-ZL3AI
Read: GUEST
Subj: TAPR Digest, Nov 11, 3/6
Path: DB0FHN<DB0FOR<DB0SIF<DB0MRW<OK0PPL<DB0RES<ON0AR<EB2BJX<ED1ZAC<ZL2TZE<
ZL3VML
Sent: 031119/1729Z @:ZL3VML.#80.NZL.OC #:13136 [Chch-NZ] FBB7.00i $:2323-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
Subject: Re: MULTI-ICON proposal
From: Steve Dimse <k4hg@tapr.org>
Date: Tue, 11 Nov 2003 11:38:04 -0500
X-Message-Number: 15
On 11/11/03 at 11:05 AM Ev Tupis (W2EV) <w2ev@arrl.net> sent:
>>This suffers from the problem I previously mentioned, namely it depends on
>>self-reporting, there is still no guarantee the advertised functionaly is
>>present and active.
>
>Unfortunately, almost everything that is APRS 'suffers' from this symptom. At
>any instant in time the "correctness" of the presented data is something other
>than 100% whenever humans are involved.
>
>Even so, there is merit in the proposal. Though there may be differing opinion
>as to how the solution is eventually applied, the need is real and the
>discussion is worthwhile.
I never said the disussion was not worthwhile, I'm proposing a better
alternative. Software to determine digi configuration would not be
difficult to write, and would provide this information in a reliable
fashion not dependent on self-reporting!
Steve K4HG
----------------------------------------------------------------------
Subject: Re: APRS' Protocol Holes [was: APRS Icon statistics]
From: "Ev Tupis (W2EV)" <w2ev@arrl.net>
Date: Tue, 11 Nov 2003 16:05:21 -0500
X-Message-Number: 16
>>There are two significant holes in the APRS spec:
>>
>>o Easy identification of a Network Appliance's personality when it displays
>> multiple personalities
>The bottom line is you cannot depend on user-defined capabilities for things
>like this. The configuration of a digi is already complex, and it is commonly
>gotten wrong. Even if everyone who thinks they are a widen-n sends an icon
>indicating they are an n-n, it does not mean they have the configuration
>correct.
>
>The correct way to answer this is with analysis software that looks at the
>packets within a network to determine how the a digi is configured.
I'm assuming that by 'digi', you are referring to any network appliance.
This only works as long as all of the possible personalities are evident to
a client 'within a network'.
Where aren't they? HFGates on the HF frequency. HFGates are supposed to
be one-way: HF to VHF. From a 30m station's perspective, how will they
know that an HF->VHF Gate exists then? There is nothing for the 30 meter
station's client to decode to tell them. Such information needs to be
embedded by the human operator.
There _must_ be room for humans to manually inject information where
appropriate.
Ev, W2EV
----------------------------------------------------------------------
Subject: Re: APRS' Protocol Holes [was: APRS Icon statistics]
From: "Ev Tupis (W2EV)" <w2ev@arrl.net>
Date: Tue, 11 Nov 2003 16:14:49 -0500
X-Message-Number: 17
>>o Identifying the launch-frequency of an APRS frame
>> - Given activity on 2m, 20m and 30m in the RF-APRS world...
>> - Given the ability to be an Internet-only APRS participant...
>> - Given the inability to know the posit's TX frequency...
>> DFing and SAR activities quickly become problematic. Could lives someday
>> be at stake?
>>
>This presumes a fixed transmit rate, but don't forget about logarithmic decay
>rates, power off mode switching, and smart beaconing, the transmit rate from
>many stations is not constant!
I'm not understanding the relationship between TX interval and the need to
identify frequency of operation in a TX frame. What am I missing?
If I see a distress call injected into the APRS network, I need to know
that it got there on 20 meters. When I get close enough, one of the tools
in my arsenal becomes the use standard RF-based DF techniques to find a
signal that may be too weak to make it to the HF Gate by the time rescue
teams arrive.
If I don't know that it came from HF (and which HF band in particular), I
can show up with 2m DF equipment only to find nothing to DF.
This is such a simple addition to the /PHGabcdefg/ protocol, it's hardly
worth debating. The advantages of including such information far outweigh
the continued lack of having it.
Ev, W2EV
----------------------------------------------------------------------
Subject: Re: APRS' Protocol Holes [was: APRS Icon statistics]
From: Steve Dimse <k4hg@tapr.org>
Date: Tue, 11 Nov 2003 17:03:05 -0500
X-Message-Number: 18
On 11/11/03 at 4:05 PM Ev Tupis (W2EV) <w2ev@arrl.net> sent:
>I'm assuming that by 'digi', you are referring to any network appliance. This
>only works as long as all of the possible personalities are evident to a client
>'within a network'.
>
>Where aren't they? HFGates on the HF frequency. HFGates are supposed to be
>one-way: HF to VHF.
Huh? HF gateways have always been bidirectional!
Steve K4HG
----------------------------------------------------------------------
Subject: Re: APRS' Protocol Holes [was: APRS Icon statistics]
From: "Ev Tupis (W2EV)" <w2ev@arrl.net>
Date: Tue, 11 Nov 2003 17:20:38 -0500
X-Message-Number: 19
>>The solutions seems simple (though they still may need a little tweaking)...
>>
>>=== Multiple Network Appliance Personalities ===
>>Digipeating is the top dog (it has the most direct impact on the local RF
>>traffic). Use a Star icon. If your appliance has more personalities, then
use>>the "?" overlay and embed information as to the other personalities in your
>>posit frame.
>>
>First, I'm hoping you mean digis that respond to WIDE, and are not advocating
>those that digi to the alias RELAY, GATE, ECHO, and so on, all of which are
>digipeaters.
I am advocating the idea that it is important for RF users to know what
network appliances exist in their RF network -- on two levels because...
....there are two types of Network Appliance:
A. Those that establish the network service (digipeaters, RF Gateways, IGates)
B. Those that consume the network service (WX, home, mobile, objects, etc.)
It would be advantageous to the APRS network to:
1. Identify all of the possible "Type A" network appliance personalities
(Including R,W,T,Wn-n,Tn-n,E,G,etc.)
2. Identify which of these personalities is exhibited by each APRS device
Maybe client-side software presents an operator with a window that
includes check-boxes with each personality. The operator checks all
that is appropriate and the client-software correctly...
3. Encode this information into each TX frame
How this is accomplished is really unimportant at this stage of the thread.
Presenting a mechanism will allow someone to find some secondary point of
an unconnected thought that doesn't make sense and kill the whole idea.
Instead, think of the APRS coolness that would be engendered if we could
identify every station that exhibits a particular network personality!
On the other hand...think of the problems we'd have in the data world if
(when) we have a problem and are unable to identify all of the devices on
our subnet! :) This is the norm on the APRS network because we have no
standardized way of device personality identification and broadcast.
Ev, W2EV
----------------------------------------------------------------------
Subject: Re: APRS' Protocol Holes [was: APRS Icon statistics]
From: Steve Dimse <k4hg@tapr.org>
Date: Tue, 11 Nov 2003 17:24:52 -0500
X-Message-Number: 20
On 11/11/03 at 4:14 PM Ev Tupis (W2EV) <w2ev@arrl.net> sent:
>If I see a distress call injected into the APRS network, I need to know that it
>got there on 20 meters. When I get close enough, one of the tools in my
arsenal
>becomes the use standard RF-based DF techniques to find a signal that may be
too
>weak to make it to the HF Gate by the time rescue teams arrive.
You will certain know it came from some HF gate (because the GATE callsign
in the path has been used). For this scenario to occur, a bunch of things
have to be true: HF Gate networks exist on different frequencies (there
don't), rescue teams had access to HF DF gear (I don't know any, though
perhaps the coast guard might), and someone actually relied on HF APRS to
get an emergency message through (a very long shot, as no one acts on APRS
emergency beacons, doing so would require a working computer, HF rig, and
TNC vs just the HF rig...I'd sure get on an HF voice net!).
>If I don't know that it came from HF (and which HF band in particular), I can
>show up with 2m DF equipment only to find nothing to DF.
>
>This is such a simple addition to the /PHGabcdefg/ protocol, it's hardly worth
>debating. The advantages of including such information far outweigh the
>continued lack of having it.
I could not disagree more. The danger in adding something like this is
subtle, but real. Once a means exists to tabulate something, no matter how
inexact it is, people will do so, and start basing decisions on it. Bad
data is MUCH more dangerous than no data.
Please, don't forget, that no matter what, this is not compatible with many
APRS stations out there. PHG cannot appear in compressed position reports
including Mic-E, position+weather format (@.....lat/lon_spd/crs....) and
many other APRS packet formats. You are proposing something which could
never give the desired result!
Steve K4HG
----------------------------------------------------------------------
Read previous mail | Read next mail
| |
