| |
ZL3AI > APRDIG 20.11.03 20:13l 235 Lines 9123 Bytes #999 (0) @ WW
BID : 2337-ZL3AI
Read: GUEST
Subj: TAPR Digest, Nov 13, 7/14
Path: DB0FHN<DB0FOR<DB0SIF<DB0EA<DB0RES<ON0AR<IW8PGT<IK1ZNW<GB7CRV<GB7CIP<
GB7KHW<GB7YFS<GB7BHM<ZL2BAU<ZL3VML
Sent: 031120/1713Z @:ZL3VML.#80.NZL.OC #:13187 [Chch-NZ] FBB7.00i $:2337-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
Subject: Re: Station attributes -was- RE: APRS Icon statistics
From: "Scott Miller" <scott@opentrac.org>
Date: Wed, 12 Nov 2003 15:50:25 -0800
X-Message-Number: 37
>I can give you ALL KINDS of examples of your examples below, where WITHOUT
>THE ABOVE INFORMATION, most of the operators are operating in the BLIND,
>and the resulting CONFUSION adds to the problems not solves them!
This brings up one of my pet peeves with all the APRS software I've tried
so far - this information is available, but you've got to (at least in
UI-View and Xasitr) click on the icon and bring up a new window to see it.
Xastir does a great job with the dead reckoning display, but the info
window sucks. At least give me status text and speed at the top, in nice
big print.
Better yet, set aside a corner of the display for that information, and let
me see it when I mouse over the station. No clutter on the main display,
and I don't have to open a new window or dialog. Or put the information
around the symbol/icon when I mouse over it. Whatever. You don't have to
have it on the screen all the time, but don't make me dig for it.
Scott
N1VG
----------------------------------------------------------------------
Subject: Re: Station attributes -was- RE: APRS Icon statistics
From: "Ev Tupis (W2EV)" <w2ev@arrl.net>
Date: Wed, 12 Nov 2003 19:02:38 -0500
X-Message-Number: 38
Steve Dimse wrote:
>People's needs are just not the same. I feel like I have failed to get this
>point across very well, let me try an example requiring a real time tactical
>system, a toxic spill.
I was quite surprized to see this comment, Steve. It seems that you've
taken on the very role that you accuse Bob of taking. :)
On the subject of Band-of-Origination and Network Personality flags, here's
a perspective that you may have not considered: APRS is more than what
happens on 144.39 MHz. Once you realize that, you also must realize that
APRS has grown beyond it's initial purpose. As such, new needs emerge. Not
addressing them begs APRS to fracture into incompatible parts.
Ev, W2EV
----------------------------------------------------------------------
Subject: Re: Adding Frequency of TX to the Protocol[was:APRS'Protocol Holes]
From: Steve Dimse <k4hg@tapr.org>
Date: Wed, 12 Nov 2003 19:00:44 -0500
X-Message-Number: 39
On 11/12/03 at 6:35 PM Ev Tupis (W2EV) <w2ev@arrl.net> sent:
>So...one can use a user defined packet format with every type of APRS frame,
>then? Mic-e, compressed, etc?
No, they are a separate packet. There is no way you can add something to
every packet without breaking every program that is out there.
Steve K4HG
----------------------------------------------------------------------
Subject: Bob...cutting to the chase on Frequency-of-TX & Network Personality
From: "Ev Tupis (W2EV)" <w2ev@arrl.net>
Date: Wed, 12 Nov 2003 19:11:32 -0500
X-Message-Number: 40
Bob,
I've outlined the need for somehow embedding frequency of operation and
network personality into an APRS frame. I would suggest that it be part of
the PHGabcdefg/ construct as this construct works perfectly with the work
I've undertaken with both the PropNET project and the HamIM project (the
?what? <smile>).
Simple question, please.... (after which I will wind-down my participation
on this thread [the list applauds <grin>])...
To what level do you support this proposal?
Ev, W2EV
----------------------------------------------------------------------
Subject: Re: MULTI-ICON proposal
From: "Tyler Allison" <tyler@allisonhouse.com>
Date: Wed, 12 Nov 2003 20:16:22 -0400 (GMT+4)
X-Message-Number: 41
>Only that the SHOULD DISPLAY the fundamental APRS
>information:
>
>1) Map symbology (the symbols and ICONs in the standard)
>2) The ATRIBUTES associated with that symbology
>3) A consistent means of describing across platform the same area of
> interest (Range Scale).
I can agree as as user that all symbols should 'mean' the same on all APRS
applications. Symbols should be part of the standard. I thought they were
when I got into APRS...now it's sounding like that isnt the case.
However, maybe I dont care about *ANY* attributes. I only want to see the
map and the symbol. Should I be forced to have the attributes of that
symbol displayed? I didnt say 'available for me to see by using some kind
of gui construct like "right click" ' I said always displayed.
Im not real concerned with range scale....most all the APRS functions I've
looked at use some kind of background map which uses lon/lat which forces
a scale upon the viewer.
And Bob...you seem to be able to communicate via email as well as I ;)
-Tyler
----------------------------------------------------------------------
Subject: Re: MULTI-ICON proposal
From: Steve Dimse <k4hg@tapr.org>
Date: Wed, 12 Nov 2003 19:28:59 -0500
X-Message-Number: 42
On 11/12/03 at 6:42 PM Ev Tupis (W2EV) <w2ev@arrl.net> sent:
>Why are you placing yourself in the position of knowing what is and isn't
useful
>and to whom this information applies? Isn't is possible that APRS has a
broader
>appeal than what appeals to you?
I'm very explictly stating no one person's opinion is more important. I'm
very forcefully arguing for the freedom of every developer to respond to
their own vision and the needs of their users, rather than follow a
dictatorial user interface! Do these words sound familiar?
Steve K4HG
----------------------------------------------------------------------
Subject: Re: Deduced *and* Declared Personality [was: APRS' ProtocolHoles]
From: Steve Dimse <k4hg@tapr.org>
Date: Wed, 12 Nov 2003 19:42:14 -0500
X-Message-Number: 43
On 11/12/03 at 6:37 PM Ev Tupis (W2EV) <w2ev@arrl.net> sent:
>Steve Dimse wrote:
>>You are completely free to do create a protocol with the user defined format.
I
>>will continue argue strongly against anything that adds a significant amount
to
>>the channel load though, especially when you propose to add it to every
frame,
>>that is a huge amount of additional channel load, even if I were to accept
your
>>position on its benefit.
>
>Yet, you've advocated the use of the status frame to communicate this
>information.
I said you can use either status or user-defined. The user defined format
has the advantage of being completely unused otherwise (meaning whatever
specific UI prefix you use is unused, not ui as a whole), so you can
essentially do anything you want, human readable or not. On the other hand,
the status message will appear in client programs, so a human readable
format could give info to users of programs that have not explicitly
supported your format.
>Your proposal doubles the channel traffic. Mine doesn't.
I'm not for a second proposing one status message or user-defined format
get sent with every packet other packet, and even then because these are
shorter they would not double the load. As I said, I do not see any reason
that every packet need be indentified, at most I'd say only those stations
that are not on usual frequencies, like the local 2 meter freq or 10.151 on
HF, need send these packets, and then only at a rate equal to position
rate.
Which proposal of yours are you comparingto mine? First you added
characters to PHG, but then you backed away from that, and then said
details didn't matter but you wanted it on every packet. You never gave a
reason for needing it on every packet. I argued back that details matter a
lot, and every packet does not need this info, which could not be added to
every packet in a backward compatible manner anyway. You never responded to
this...
Steve K4HG
----------------------------------------------------------------------
Subject: Re: Sniffing for WideN-N's? [was: APRS Icon statistics]
From: Steve Dimse <k4hg@tapr.org>
Date: Wed, 12 Nov 2003 19:47:24 -0500
X-Message-Number: 44
On 11/12/03 at 6:49 PM Ev Tupis (W2EV) <w2ev@arrl.net> sent:
>>You should read more carefully, included in the my discussion was the use of
>>probe packets with different paths, sent in the wee hours when there would be
>>the lightest load on the system. Using these, it would be possible to
>determine
>>the network configuration.
>
>So, in order to use the system as you propose, I must now stay active during
the
>wee hours of the morning?
No, what I am saying is those people interested in network configuration
could have any probing done automatically at times when network load was
low, like the middle of the night.
>On the other hand...my proposal of adding a few attributes to an existing
system
>by expressly including a full Station Attributes (or Configuration Code) in
each
>frame, there's no delay. Emergency hits, power-up, in moments you have a full
>understanding of the local network's operation.
As I said, most users have no need of knowing precise configurations. They
do need to know their packets get through, and if not what the paths of
packets are which are getting through. This is something that can easily be
implemented to occur passively, and at power up.
Steve K4HG
----------------------------------------------------------------------
Read previous mail | Read next mail
| |
