| |
ZL3AI > APRDIG 19.11.03 20:03l 270 Lines 10942 Bytes #999 (0) @ WW
BID : 2324-ZL3AI
Read: GUEST
Subj: TAPR Digest, Nov 11, 4/6
Path: DB0FHN<DB0FOR<DB0SIF<DB0NHM<DB0ERF<DB0FBB<DB0GOS<ON0AR<ON0AR<7M3TJZ<
SP7MGD<VK3TE<ZL2TZE<ZL3VML
Sent: 031119/1729Z @:ZL3VML.#80.NZL.OC #:13137 [Chch-NZ] FBB7.00i $:2324-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
Subject: Re: APRS' Protocol Holes [was: APRS Icon statistics]
From: "Ev Tupis (W2EV)" <w2ev@arrl.net>
Date: Tue, 11 Nov 2003 17:32:56 -0500
X-Message-Number: 21
Steve Dimse wrote:
>Second, with this you make a value judgement in what is important, one that may
>not be true for all people, all areas, and all times. Is being an EOC more
>important thn being a digi? How about hospitals and xhelters? Granted, in
normal>configurations few of the will be WIDEs, but it is pretty easy to imagine
>disaster settings where these manned locations become critical in replacing
lost>unmanned digis.
The assumption is that those network appliances that add to the networks
infrastructure are the most important to know. That is what should
determine one's display icon. This is ok because...
By embedding additional network functions into the frame, clients can
quickly parse for that info and display it in accord with the client's
need.
Example:
W4XYZ-10 = Digipeater (W,T,Wn-n,Tn-n), Emergency Powered, WX station, IGate
and housed at an EOC.
Display icon = Star with "?" overlay
Now, an emergency hits.
To some users, they want to know where the EOC's are. Their
client-software receives the frame (which has the above info embedded
within in a standard format). The client (person) can then ask the
software to display EOC's. All other icons disappear from the screen,
leaving only EOC's (no matter what their display symbol is).
To other users, they want to know where the IGate's are. The client
(person) can ask the software to display IGate's. All other icons
disappear from the screen, leaving only IGates (no matter what their
display symbol is).
In the above case, W4XYZ-10's "?-Star" icon will display under either query.
I would propose (this ain't law...it's 'thinking out loud' <smile>) the
following order-of-importance in determining what icon to display:
1. Digipeaters (Star with appropriate overlay, including "?" if more than one
function)
2. IGates (IGate icon with same overlay sceme as above)
3. RF Gates (ditto comments from above)
4. All others may choose whatever icon they want from the table
Ev, W2EV
----------------------------------------------------------------------
Subject: Freq of Origination [was:APRS' Protocol Holes]
From: "Ev Tupis (W2EV)" <w2ev@arrl.net>
Date: Tue, 11 Nov 2003 17:37:30 -0500
X-Message-Number: 22
>>=== Frequency of TX ===
>>Adding a 2-byte frequency designation to the /PHGabcdefghi/ construct will
>>allow the identification of any frequency from 30-hz to 300-GHz (!).
>>Alternatively, a 1-byte frequency designation can identify any amateur
>>band presently in use, with room to expand.
>>
>I'm not sure I see the reason for this. APRS is purposefully designed to ignore
>the band a packet came in on, if people are coming in from other bands, their
>IGates sould automatically take care of getting a message back to them. Am I
>missing something?
>
>Furthermore, this proposal cuts out all those packets which do not use the PHG
>construct, for example weather @..._ format, Mic-E packets, and others.
SAR and network auditing almost demand the knowledge of frequeny of
origination. This proposal (to include frequency of origination) is no
different than any other APRS configuration-advertising protocol. If
unused, then it is unknown.
At this point, though, there is no APRS-recognized way to embed this
information if you wanted to. That's the only point here.
Ev, W2EV
----------------------------------------------------------------------
Subject: Re: Freq of Origination [was:APRS' Protocol Holes]
From: "Mike Yetsko" <myetsko@insydesw.com>
Date: Tue, 11 Nov 2003 17:47:51 -0500
X-Message-Number: 23
>>>=== Frequency of TX ===
>>>Adding a 2-byte frequency designation to the /PHGabcdefghi/ construct
will
>>>allow the identification of any frequency from 30-hz to 300-GHz (!).
>>>Alternatively, a 1-byte frequency designation can identify any
amateur
>>>band presently in use, with room to expand.
>>>
>>I'm not sure I see the reason for this. APRS is purposefully designed
to ignore
>>the band a packet came in on, if people are coming in from other
bands, their
>>IGates sould automatically take care of getting a message back to
them. Am I
>>missing something?
>>
>>Furthermore, this proposal cuts out all those packets which do not use
the PHG
>>construct, for example weather @..._ format, Mic-E packets, and
others.
>
>SAR and network auditing almost demand the knowledge of frequeny of
>origination. This proposal (to include frequency of origination) is no
>different than any other APRS configuration-advertising protocol. If
unused,
>then it is unknown.
>
>At this point, though, there is no APRS-recognized way to embed this
information
>if you wanted to. That's the only point here.
>
>Ev, W2EV
I've not followed this from the beginning, but it sounds like the old
arguments I put forth when I was thinking about getting a mic-e. If
there's a repeater with mic-e data ability, then knowing the frequency the
data originated on could make it real easy to find and talk with someone.
For example, if they were on 146.64 repeater, then the data would be
originating on 146.04. Since you know the area, and you know the
frequency, you would know that he's on a specific '64' repeater and if you
were in range you could just give the guy a voice call.
It would work the same way on simplex, but there probably wouldn't be near
as many listening stations on most simplex frequencies.
Mike
----------------------------------------------------------------------
Subject: Re: APRS' Protocol Holes [was: APRS Icon statistics]
From: "Ev Tupis (W2EV)" <w2ev@arrl.net>
Date: Tue, 11 Nov 2003 17:50:02 -0500
X-Message-Number: 24
Steve Dimse wrote:
>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!
Technically, yes, but the 'Wrath of Bob' is awoken should there be many who
actually use their 2m APRS station to launch a frame such as: R,W,G,G,W.
<smile>
Such appliances are designed to be HF to VHF. As such, the probability of
an HF station knowing that a VHFGate (from their perspective) is in range
is quite slim, based solely on the client-software's ability to sniff for
VHF-gated traffic on the HF frequency.
Ev
----------------------------------------------------------------------
Subject: Re: MULTI-ICON proposal
From: "Ev Tupis (W2EV)" <w2ev@arrl.net>
Date: Tue, 11 Nov 2003 17:40:15 -0500
X-Message-Number: 25
>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!
The 'better alternative' works only if there is a way to determine a
personality from a stations' transmission. I've already pointed out at
least one example where such is not the case.
APRS needs a way to allow savvy operators to manually embed information
into their transmissions. There's a reason that manual transmission
vehicles exist. <grin>
Ev, W2EV
----------------------------------------------------------------------
Subject: Re: APRS' Protocol Holes [was: APRS Icon statistics]
From: Steve Dimse <k4hg@tapr.org>
Date: Tue, 11 Nov 2003 17:58:31 -0500
X-Message-Number: 26
On 11/11/03 at 5:20 PM Ev Tupis (W2EV) <w2ev@arrl.net> sent:
>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.)
I don't agree that it is important for all RF users to know this, but it is
important for planners and managers to know this, so no big argument...
>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...
No argument on these two points...
>3. Encode this information into each TX frame
Why encode it when the data can already be deduced? Why use unreliable
self-reporting when you could use actual function-based determination (I
know K4HG-4 is an IGate, because it acts like an IGate, not because it
claims to be).
>How this is accomplished is really unimportant at this stage of the thread.
Actually, I think it is very important. Your proposal was to add it to the
PHG format, but as I said, many, if not most, packets cannot have a PHG
format. If you are now backing away from PHG and proposing something else,
then I think that something else is bery important to hear! To add this
info to every packet would be a large additional channel load, and I simply
do not believe there is any benefit, much less enough to justify using this
much bandwidth!
>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!
Not arguing that point, I'm saying self-reporting is not the best way to
accomplish this goal. Much, if not all of what you want, can be encoded
into any rf client program right now, without a change to the protocol.
Furthermore, I think a surprising amount could probably be deduced with a
little work entirely on the internet side, depending on how much of the
raw, non-dup-filtered data a program could get access to.
>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.
Actually, you probably haven't been following developments on the APRS
Internet System, between that and the information available on findU, it is
quite possible to track down anything you want to know. Maybe not simple,
but the people that have a need seem to learn to it without much
difficulty.
Steve K4HG
----------------------------------------------------------------------
Read previous mail | Read next mail
| |
