| |
ZL3AI > APRDIG 19.11.03 19:59l 332 Lines 13652 Bytes #999 (0) @ WW
BID : 2322-ZL3AI
Read: GUEST
Subj: TAPR Digest, Nov 11, 2/6
Path: DB0FHN<DB0FOR<DB0SIF<DB0EA<DB0RES<ON0AR<IK1ZNW<ZL2TZE<ZL3VML
Sent: 031119/1729Z @:ZL3VML.#80.NZL.OC #:13135 [Chch-NZ] FBB7.00i $:2322-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
Subject: Re: What Symbol? [was: APRS Icon statistics]
From: Bob Bruninga <bruninga@usna.edu>
Date: Tue, 11 Nov 2003 09:00:50 -0500 (EST)
X-Message-Number: 8
On Tue, 11 Nov 2003, Chris Rose wrote:
>Why not use the different buffers in a KPC3+ to send
>different strings of data to identify different
>aspects of your station. Would the LT buffers work?
>Enter different data to ID at intervals to highlight
>whatever is going on with your station.
As I have said before, APRS wont work that way. Each different report
would be treated as a CHANGED position and APRS is supposed to treat NEW
AND CHANGED data differently and more timely than OLD data and logged as a
change. Such a technique is NOT backwards compatible with all existing
code...
de WB4APR, Bob
----------------------------------------------------------------------
Subject: RE: APRS Icon statistics
From: Steve Dimse <k4hg@tapr.org>
Date: Tue, 11 Nov 2003 09:17:40 -0500
X-Message-Number: 9
>In your case, what does your station do the most? What is it's greatest
>function? It would be nice to have all sorts of map symbols to represent
>every possibility but we don't....and it would look goofy watching a station
>change from one to the other.
Something people should keep in mind...there are ways to tell what function
a station has, other than the symbol. Furthermore, the presence of a symbol
does not guarantee the function represented is actually present.
For example, if a station is a digi, a user will see digipeated packets
coming from the station. If it is an IGate, its call will appear after the
q construct (on the internet side and . If it is a weather station, it will
send weather data. If it a mobile, it will move.
This is why to me, "symbols" are not the way to transmit station
capabilities, any more than SSIDs were the way to send symbols. Rather, I
believe station capabilities should be determined by the actual function.
Not only is the self-reporting of function prone to errors caused by over
and under-reporting of capabilities, but it also fails to detect changes in
connection capabilities. An example, an IGate stations whose internet
connection is down.
Steve K4HG
----------------------------------------------------------------------
Subject: Re: MULTI-ICON proposal
From: Steve Dimse <k4hg@tapr.org>
Date: Tue, 11 Nov 2003 09:46:17 -0500
X-Message-Number: 10
On 11/11/03 at 8:55 AM Bob Bruninga <bruninga@usna.edu> sent:
>MULTI-ICON proposal:
>
>If other authors could support it, I would support an added construct that
>could say handle up to 8 additional ICONS per station. THey could be
>arranged in a BLOCK (thats why 9)... We would do it this way:
I see a couple problems with this.
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.
Most importantly, what is the need? What data are you thinking needs to be
transmitted that cannot be determined by other means? All of the things I
can think of have a means of determining them from data already being
transmitted. If there is something else, might it not be better to create a
way for it to be determined rather than have a user throw up a bunch of
icons?
Note...there is nothing that prevents this from being done as a UI element
on any particular client...if a client detects IGate packets coming from a
station, it could throw up an extra icon signifying IGate, same with digi
packets, and anything else an author wishes. I personally think I would
find this annoying, and I hope no program I use implements this, but it
still is a choice available to each individual author. I just think letting
people pick 8 additional icons to throw up on every APRS map is asking for
trouble!
Steve K4HG
----------------------------------------------------------------------
Subject: APRS' Protocol Holes [was: APRS Icon statistics]
From: "Ev Tupis (W2EV)" <w2ev@arrl.net>
Date: Tue, 11 Nov 2003 10:14:51 -0500
X-Message-Number: 11
This been brought up in the past, and there didn't appear to be any
interest in looking into it any more deeply then. Yet, I simply feel
compelled to bring it up one more time.
There are two significant holes in the APRS spec:
o Easy identification of a Network Appliance's personality when it displays
multiple personalities
- This thread has already established two things:
+ Bob would like WideN-N digipeaters to be labled correctly so that the
network resource is easily and quickly identified by other RF users
+ It is impossible to provide a rule-of-thumb to do so, given the use of
symbols as they are today when a digi may also be WX, IGate, etc.
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?
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.
Alternatively, add to the /PHGabcdefghijklmn/ construct to include multiple
appliance personalities.
=== 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've offered suggestions along these lines in the past and am happy to
recopy them to the list if Bob has any interest in revisiting this. If
not, I won't clutter the list with the text.
With Regards from the basement hack,
Ev Tupis, W2EV
----------------------------------------------------------------------
Subject: Re: MULTI-ICON proposal
From: "Ev Tupis (W2EV)" <w2ev@arrl.net>
Date: Tue, 11 Nov 2003 11:05:18 -0500
X-Message-Number: 12
Steve Dimse wrote:
>>MULTI-ICON proposal:
>>
>>If other authors could support it, I would support an added construct that
>>could say handle up to 8 additional ICONS per station. THey could be
>>arranged in a BLOCK (thats why 9)... We would do it this way:
>>
>I see a couple problems with this.
>
>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.
Regards,
Ev, W2EV
----------------------------------------------------------------------
Subject: RE: APRS Icon statistics
From: "Ev Tupis (W2EV)" <w2ev@arrl.net>
Date: Tue, 11 Nov 2003 11:16:32 -0500
X-Message-Number: 13
Steve Dimse wrote:
>Something people should keep in mind...there are ways to tell what function a
>station has, other than the symbol. Furthermore, the presence of a symbol does
>not guarantee the function represented is actually present.
In fact, this is where I applaud Roger and UI-View. At a glance, I know
who the IGates are. He tests the traffic coming from a given station and
then places a blue-box around those exhibiting IGate characteristics.
The same could be done for any flavor of N-N digipeater, HFGate, etc I
suppose.
Looking forward ...
A simple client-side pull-down menu like this would be interesting to
persue: Display Only...
And a check-box selection screen with the following...
[] Relay Digipeaters
[] WideN-N Digipeaters
[] TraceN-N Digipeaters
[] IGates
[] HF Gates
[] SatGates
[] WX Stations
[] Mobile
Display symbols could continue to be expressions of personal choice --
though users would be encouraged to always display star-digis whenever any
digi function is present (since that forms the foundation of RF-side
operation).
Ev, W2EV
----------------------------------------------------------------------
Subject: Re: APRS' Protocol Holes [was: APRS Icon statistics]
From: Steve Dimse <k4hg@tapr.org>
Date: Tue, 11 Nov 2003 11:35:40 -0500
X-Message-Number: 14
On 11/11/03 at 10:14 AM Ev Tupis (W2EV) <w2ev@arrl.net> sent:
>There are two significant holes in the APRS spec:
>
>o Easy identification of a Network Appliance's personality when it displays
> multiple personalities
> - This thread has already established two things:
> + Bob would like WideN-N digipeaters to be labled correctly so that the
> network resource is easily and quickly identified by other RF users
> + It is impossible to provide a rule-of-thumb to do so, given the use of
> symbols as they are today when a digi may also be WX, IGate, etc.
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.
The APRS IS is not the ideal base for such a system (for the same reason it
is lacking for prop-net, namely the removal of duplicate payloads), better
would be a system that sits on the rf network. For example, say even one
IGate capable client abcAPRS implements an analysis on what it is hearing
on RF, and once an hour generates a user-defined packet on internet
indicating those digis it hears and how they are configured. Maybe once a
day, in the wee hours, send out one or more carefully crafted test packets
with TRACE and other discouraged paths in order to better define the
topology. Piece of cake to the develop a findU web page to sort this data
into a list of the different types of digis, and identify those with gross
errors.
And, while the APRS IS would not be ideal for hosting such a system, it
certainly could be used for developmemt and testing, and might well give
results for the majority of digis anyway.
Hosting this code (at least the received part of ot) with the hubs would be
another possibility, since any hub has access to more duplicate packets
than any client would.
>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!
>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.
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.
>Alternatively, add to the /PHGabcdefghijklmn/ construct to include multiple
>appliance personalities.
With this, you are depending on people correctly setting the beacon to
match the function. Some things could be set automatically by software, but
others, like digipeater configuration, are commonly set as TNC parameters,
not necessarily by the software. How can you be sure the PHG matches the
actual configuration?
Don't you think it would be better to have client software automatically
determine the true function of the station? Wouldn't that be much more
reliable???
>=== 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.
Steve K4HG
----------------------------------------------------------------------
Read previous mail | Read next mail
| |
