| |
ZL3AI > APRDIG 20.11.03 20:09l 236 Lines 9670 Bytes #999 (0) @ WW
BID : 2336-ZL3AI
Read: GUEST
Subj: TAPR Digest, Nov 13, 6/14
Path: DB0FHN<DB0FOR<DB0SIF<DB0FSG<DB0RGB<OK0PPL<DB0RES<ON0AR<7M3TJZ<IK1ZNW<
GB7CRV<GB7CIP<GB7YFS<GB7BHM<ZL2BAU<ZL3VML
Sent: 031120/1713Z @:ZL3VML.#80.NZL.OC #:13186 [Chch-NZ] FBB7.00i $:2336-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
Subject: Re: Station attributes -was- RE: APRS Icon statistics
From: Bob Bruninga <bruninga@usna.edu>
Date: Wed, 12 Nov 2003 18:25:48 -0500 (EST)
X-Message-Number: 31
On Wed, 12 Nov 2003, Tyler Allison wrote:
>believe that will give the edge their users want fine. If someone wants
>to write a weather ONLY APRS display system...fine. There should be
>absolutely ZERO requirements on how to display the data. There should be
>100% requirements on how/what/when/why to transmit said data.
We disagree. Weather objects in APRS are supposed to be DEADRECKONED on
all displays. That is, a MOVING object placed on a map by anyone and
transmitted to the group MUST MOVE ON EVERYONE ELSE's display too, else
you have different people looking at "the same thing" and seeing TOTALLY
DIFFERNET things.. ALso the display MUST convey OLD objects from new
ones. Else again, people see different things.
What I am upset about is NOT HOW this information is displayed, but the
fact that many CLIENT programs do not differentiate between an OBJECT and
a station, a MOVING object and something fixed, an OLD object or a NEW
one, etc. I dont care how they display it, just that that information
must be present....
>Note: Im just an APRS user...what turned me off of the APRSdos, UI-View
>GUI's of this world was it took a Phd and 14 months of studying to learn
>how to view something specific I wanted. I bring up Xastir and I can
>filter to my hearts content and see the data *I WANT* in a single view.
Absolultely! That is exactly the kind of flexibility and end user
functionality we all want APRS to bring to the end user. And Xastir is
one of the clients that does try to display these attributes so that
there is no confusion between end users...
>Im not saying it cant be done in the other systems...*I* found it easier
>in Xastir. Im not going to be a happy camper if someone tries to tell
>*ME* how Im suppose to view the data and the only reason they give is
>"because I know better".
Then you are missunderstanding the whole debate. NOthing is limiting how
clients display the data, just that client programs must differentiate
the fundamental attributes associated with ICONS so that you can tell the
difference between a symbol:
1) that is moving or not
2) thta is an OBJECT or not
3) that was posted with position ambituity or not
4) that has been dead-reckoned or not
5) that is current or not
And you must be able to describe by "range scale" to someone of a
different platform so that he can zoom to the same range scale you have
and see the SAME situation
That is the only thing I am asking of client programs
And is what is MISSING in many!...
de WB4APR@amsat.org, Bob
----------------------------------------------------------------------
Subject: Re: Adding Frequency of TX to the Protocol[was:APRS'Protocol Holes]
From: "Ev Tupis (W2EV)" <w2ev@arrl.net>
Date: Wed, 12 Nov 2003 18:35:50 -0500
X-Message-Number: 32
Steve said:
>Then all you need to do is announce a user-defined paket format, and let people
>code it if they desire. This is exactly the situation for which I fought to
>include this format in the spec.
>
>Define it however you want, and if it proces to be useful THAT is when it gets
>added to the spec.
So...one can use a user defined packet format with every type of APRS frame,
then? Mic-e, compressed, etc?
Ev, W2EV
----------------------------------------------------------------------
Subject: Re: Deduced *and* Declared Personality [was: APRS' ProtocolHoles]
From: "Ev Tupis (W2EV)" <w2ev@arrl.net>
Date: Wed, 12 Nov 2003 18:37:47 -0500
X-Message-Number: 33
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. Your proposal doubles the channel traffic. Mine doesn't.
What am I missing in your position?
Ev, W2EV
----------------------------------------------------------------------
Subject: Re: MULTI-ICON proposal
From: Bob Bruninga <bruninga@usna.edu>
Date: Wed, 12 Nov 2003 18:41:53 -0500 (EST)
X-Message-Number: 34
On Wed, 12 Nov 2003, Mark Earle wrote:
>But. I am tired of the cry that everything must work as it does in APRSDos,
Then you are listening to some lunatic somewhere (not me) and you have not
heard or comprehended much about the issues I have been presenting...
>or, it must fit on a tiny HT display or it's broke, or, we can't send
>more than a few messages of some type because of limited buffer in a
>Kenwood mobile.
I never said that. What I say is that there are 10,000 kenwood users out
there. If YOU want them to read what you send on APRS and fully
understand it on receipt, then you cannot transmit a line that contains
more than 64 characeters in a message. Now, how can we operate an APRS
COMMUNICATIONS SYSTEM if we just blindly transmit something that MOST Of
our mobile users cannot see?
>In other words.. there are more than 3 products out there that folks are
>using. They are not all equal in all areas.
No, but there MUST BE a COMMON DENOMINATOR! Without a common baseline
then we will guarantee an inability to talk cross platform. APRS is
supposed to be something that allows people to communicate (end human to
end human). How can we encourage people to transmit message lines that
are LONGER than the standard when we KNOW that other end users will not
RECEIVE the meaning???
Designing a communications system with no common denominator is ludicrous!
>BUT, without too much trouble, [I] have set up and used UIView and
>WinAPRS also. It's not that big a deal. The menus are sensible enough to
>make it possible.
And that is the beauty and joy of having APRS client software standardized
to the spec. Isnt it great? and the only reason they work well together
is because they all try to follow the spec and to work together to be sure
that the end users get the same information when looking at the same
situation on their maps..
>APRSDos is OK but certainly I would not put it in front of a volunteer
>and expect results. I have done this with two of the 3 above programs,
>and in 15 minutes the volunteer had on the map the desired data.
Plese get out of your mind that I expect ANYONE to use APRSdos these days.
I dont know where in the world you get that idea... Your focus on this
indicates you are not following the issues. The issue is that many client
programs FAIL to show the FUNDAMENTAL information content that is supposed
to be on an APRS map:
1) Standard Symbology (icons)
2) The ATTRIBUTES associated with that symbology
3) A consitent means of communicating between end users the area of
interest (Range scale) across platform...
No more, no less. APRSdos does that. That is the ONLY reason I raise
APRSdos as an example. ALl the other programs give much better GUI and
much better about everything. BUT many do NOT display #2 and #3, and so
they make it IMPOSSIBLE for cross platform users to get the same
information when they both look at the same situation on their different
systems..
That is what we must work towards fixing...
Bob, WB4APR
----------------------------------------------------------------------
Subject: Re: MULTI-ICON proposal
From: "Ev Tupis (W2EV)" <w2ev@arrl.net>
Date: Wed, 12 Nov 2003 18:42:15 -0500
X-Message-Number: 35
Steve Dimse wrote:
>Absolutely this information is useful to network designers, maintainers, and
>managers, but I do not believe it needs to built into every APRS client. Again,
>whether any particular client implements this (or the parsing of an every frame
>add-on for that matter) is a choice for each author, as dictated by the needs
of>their users.
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?
Ev, W2EV
----------------------------------------------------------------------
Subject: Re: Sniffing for WideN-N's? [was: APRS Icon statistics]
From: "Ev Tupis (W2EV)" <w2ev@arrl.net>
Date: Wed, 12 Nov 2003 18:49:38 -0500
X-Message-Number: 36
Steve Dimse wrote:
>
>On 11/12/03 at 7:33 AM Ev Tupis (W2EV) <w2ev@arrl.net> sent:
>
>>>A Widen-N digi doesn't have any packet present identifying artifacts does it?
>>
>>In the absence of an embedded tag (and no known artifacts to judge it's
>>personality) how would one go about identifiying a WIDEn-N, NOID digi with
your>>proposal of simple personality observing, Steve?
>>
>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?
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.
Your solution seems more convoluted as your arguments against my proposal
are floated. :)
Ev, W2EV
----------------------------------------------------------------------
Read previous mail | Read next mail
| |
