| |
ZL3AI > APRDIG 16.11.03 10:52l 266 Lines 11380 Bytes #999 (0) @ WW
BID : 2279-ZL3AI
Read: GUEST
Subj: TAPR Digest, Nov 05, 2/3
Path: DB0FHN<DB0RGB<OK0PPL<DB0RES<ON0AR<7M3TJZ<JE7YGF<LU6DTS<ZL2TZE<ZL3VML
Sent: 031116/0831Z @:ZL3VML.#80.NZL.OC #:12925 [Chch-NZ] FBB7.00i $:2279-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
Subject: RE: Available TNC's
From: "Joe B. Dorn" <joedorn@stonemedia.com>
Date: Wed, 5 Nov 2003 18:26:40 -0600
X-Message-Number: 14
Even as we speak I have my Peet Brothers Weather Station running to a KPC3+
using the dual port capabilities driving a Yaesu FT-1500... You can see it
at:
http://www.findu.com/cgi-bin/wxpage.cgi?call=W5VEX-1&radar=ewx&last=120
The missing data is due to being offline for a month while I replaced
equipment after a lighting strike. I was using a MFJ data radio that is
being repaired at this time. I intend to make a tracker for my ATV
(four-wheeler) out of this radio after I get the data radio back. I have
also purchased two more for utility purposes. It seems to be a very rugged
small radio, currently available at a very good price.
I see no reason it would not work with the Tinytrak and/or the TigerTronics
units also, which is in my plans after the lightning recovery is recovered
from...
Joe Dorn, W5VEX, Belton, Texas
Bell County ARES AEC
(254) 939-5918
Instructor & Mentor ARRL EC Courses (all levels)
Instructor USPS Weather Course
----------------------------------------------------------------------
Subject: DX cluster spots on APRS (the RIGHT way)
From: Bob Bruninga <bruninga@usna.edu>
Date: Wed, 5 Nov 2003 19:56:30 -0500 (EST)
X-Message-Number: 15
On Wed, 5 Nov 2003, Steve Dimse wrote about F1NWC DX spots:
>I agree. What he does is use a single position for each call prefix, and
>place everything on that point. I asked F1NWC to reconsider his actions
>,but when he failed to respond, I decided to filter out all the DX
>spots he posts from findU, which is why those people looking for these
>positions on findU didn't see them!
This is not a fault of F1NWC. I believe he is transmitting a VALID APRS
DX cluster spot. (though I erased this thread until now when I see the
issues inbvolved and so I dont have his original packets)...
What the station was seeing is the failure of HIS APRS client software to
properly implement DX cluster spotting and/or 4 digit position
ambiguity...
This is exactly why APRS from day one has had 4 digit position ambiguity
and why APRSdos defined the plotting of DX cluster spots as RANDOMLY
within the 4 digit ambiguity circle. AND every such spot so plotted
appears (as designed in APRSdos from day one) as a DX spot symbol randomly
within about 60 miles around the center of the callsign area with a
surrouinding purple circle 250 miles in diameter so that there is no
ambiguity whatsoever to any observer that this is an estimated postion no
more accurate than several hundred miles. ANd because of the randomness,
by zooming in, you can resolve all the separate callsigns...
The fact that someone is seeing all DX spots from the same CALLSIGN area
at one exact location is the fault of their client software, not the
sender...
I dont know of any APRS clients other than APRSdos that properly
implemented DX cluster spots nor properly convey the proper display to the
end user. No I dont think these details are in the spec, becuase since
only the original APRSdos had it, the other authors who had not
implemented it would not sign the spec if these kinds of specific
display details were in there... THey claim that DISPLAY is totally their
option, and cannot be in the spec.
SO you see why we have the mess we have...
1) If all the ICONS are at exaclty the same place, then the CLIENT
software does not support POSITION AMBIGUITY which is supposed to randomly
place the ICON within the ambiguity circle..
2) If the ICONS are not surrounded by a 250 mile ambiguity circle then the
CLINET software does not support the proper display of a DX SPOT ICON...
Bob, WB4APR
----------------------------------------------------------------------
Subject: Re: DX cluster spots on APRS (the RIGHT way)
From: Steve Dimse <k4hg@tapr.org>
Date: Wed, 5 Nov 2003 20:32:14 -0500
X-Message-Number: 16
On 11/5/03 at 7:56 PM Bob Bruninga <bruninga@usna.edu> sent:
>This is not a fault of F1NWC. I believe he is transmitting a VALID APRS
>DX cluster spot. (though I erased this thread until now when I see the
>issues inbvolved and so I dont have his original packets)...
>
>What the station was seeing is the failure of HIS APRS client software to
>properly implement DX cluster spotting and/or 4 digit position
>ambiguity...
No. He is taking DX spots, and turning them into APRS objects, with no
ambiguity.
Regardless, even if they did have ambiguity, or if they were just the DX
spots being sent, the problem remains for findU. It's never been a secret
that I object strongly to ambiguity, and this is a good example of why.
The objects sent by F1NWC became my problem because I was getting dozens of
complaints, some were that near.cgi was worthless to some people, because
if you happen to be near the point chosen for a prefix, your near list was
crammed full of these converted dx spots.
Your solution to ambuiguity (place randomly within the area of ambiguity,
and disappear when zoomed in too close) is perhaps acceptible for maps, but
breaks down utterly on a table structure like near.cgi.
Worse, I was targeted by a number of people who had spots placed on the
network, claiming someone was pirating their call, or demanding I remove
them from the web.
>The fact that someone is seeing all DX spots from the same CALLSIGN area
>at one exact location is the fault of their client software, not the
>sender...
Again, in this case, the positions are sent as APRS objects with no
ambiguity, but again, your solution only applies to maps, and has no value
with other forms of data.
Also, this example has yet another deficiency. The maximum ambiguity
possible in APRS is one degree, 60 nm or less in lat and lon. Yet the area
covered by, for example the K4 prefix is 400 or 500 miles, so there is no
way within APRS to convey the ambiguity. Also, no callsign area has an
ambiguity that is a circle, so you cannot get across what you are really
aiming for.
Steve K4HG
----------------------------------------------------------------------
Subject: Thanks
From: Wes Johnston <wes@johnston.net>
Date: Wed, 05 Nov 2003 21:13:48 -0500
X-Message-Number: 17
Thanks for the acme maps and the miles/kilometers/nautical units.
Wes
----------------------------------------------------------------------
Subject: Re: DX cluster spots on APRS (the RIGHT way)
From: Bob Bruninga <bruninga@usna.edu>
Date: Wed, 5 Nov 2003 22:02:25 -0500 (EST)
X-Message-Number: 18
Bob Said:
>>What the station was seeing is the failure of HIS APRS client software
>>to properly implement DX spotting and/or 4 digit position ambiguity...
On Wed, 5 Nov 2003, Steve Dimse wrote:
>It's never been a secret that I object strongly to ambiguity, and this
>is a good example of why.
No, sorry, it is a perfect example of why the ability to tag a position
with Position-Ambiguity (or lack of precision) is fundamentally essential
in any situational position data program!, And why it was FUNDAMENTAL in
the definition of APRS in the first place, ANd why the failure to implement
it leads to ALL KINDS of problems...
>Your solution to ambuiguity (place randomly within the area of
>ambiguity, and disappear when zoomed in too close) is perhaps acceptible
>for maps, but breaks down utterly on a table structure like near.cgi.
Not if the data structure recognized the position ambiguity attribute and
acted appropriately. Every POSITION in APRS is supposed to be tagged with
its original precision (which I call ambiguity). In the case of a table
presentation of the data, the ambiguity attribute has to be considered in
any application of the data... In this particular case, The simplest
thing could be to ignore any position that is transmitted and marked with
ambiguity in your "nearness" table... But that robs users of fundamental
data that was intended by the sender...
It might be better to do the right thing and consider the ambiguity field
and present the data properly to the user with that taken into
consideration in any such presentation... such as maybe listing them at
the bottom separately with their level of ambiguity... THis way the user
is aware of the data that he is NOT getting from that given client
program...
>Worse, I was targeted by a number of people who had spots placed on the
>network, claiming someone was pirating their call, or demanding I remove
>them from the web.
All of these problems could be fixed if client APRS software simply
recognized and properly implemented the recognition of position anmbiguity
as an attribute that is fundamental to any position reporting system...
>>The fact that someone is seeing all DX spots from the same CALLSIGN area
>>at one exact location is the fault of their client software, not the
>>sender...
>Again, in this case, the positions are sent as APRS objects with no
>ambiguity,
*** Then I apologize and I agree COMPLETELY that the sender is at fault...
sorry, but since I didnt see the original packetss, I assumed they were
properly sent...
>but again, your solution only applies to maps, and has no
>value with other forms of data.
Not true. if the data was stored "as it should be in APRS", then the data
for a position report is *not* just a LAT/LONG. It has many attributes..
one of those has *always* been the additional FIELD of AMBIGUITY (which
was my choice of words to describe lack-of-precision of data). APRS was
designed absolutely from the very first day in 1992 and before it was even
a working program with the concept of POSITION ambiguity as fundamental.
THe fact that this attribute of a position report was not properly
implemented in some client programs is a flaw in those implementions.
THe concept of "degree-of-precison" of data must be conveyed from the
sender to the receiver in ANY reliable position reporting system such as
APRS as originally conceived and designed.
>Also, this example has yet another deficiency. The maximum ambiguity
>possible in APRS is one degree, 60 nm or less in lat and lon. Yet the
>area covered by, for example the K4 prefix is 400 or 500 miles, so there
>is no way within APRS to convey the ambiguity. Also, no callsign area
>has an ambiguity that is a circle, so you cannot get across what you are
>really aiming for.
Ah, but the definition of the DX SPOT ICON is what includes the 250 mile
callsign-prefix-plotting ambiguity circle of a DX spot, not the official
"position ambiguity concept". (which does only go to 60 miles)...
Remember, the concept of "ICON" never entered into APRS until WinAPRS used
them as a simplistic approach to APRS displays. Thus overlooking the fact
that APRS "SYMBOLS" also have many ATTRIBUTES. Here are some of the
ATTRIBUTES of an APRS SYMBOL that are left out of MOST CLIENT PROGRAMS:
1) Message capable or not (White or Gray)
2) Digipeating or not (Green or not)
3) Dead reckoned (CYAN or not)
4) Moving (light Blue or not)
5) SOmeone elses Object (Purple)
6) Your own OBJECT (yellow)
7) Ambiguity circle around it proportional to ambiguity
8) Emergency or unrecognized symbol (Red)
9) 250 mile circle if a DX spot symbol
etc...
I am not trying to point any fingers, just trying to make sure that all
authors understand this fundamental principle...
thanks
Bob, WB4APR
----------------------------------------------------------------------
Read previous mail | Read next mail
| |
