| |
ZL3AI > APRDIG 17.11.03 11:48l 326 Lines 13871 Bytes #999 (0) @ WW
BID : 2300-ZL3AI
Read: GUEST
Subj: TAPR Digest, Nov 07, 1/5
Path: DB0FHN<DB0FOR<DB0SIF<DB0FHK<DB0FBB<DB0GOS<ON0AR<WB0TAX<VK7AX<ZL2BAU<
ZL3VML
Sent: 031117/0851Z @:ZL3VML.#80.NZL.OC #:13009 [Chch-NZ] FBB7.00i $:2300-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
TAPR APRS Special Interest Group Digest for Friday, November 07, 2003.
1. Where's Dad?
2. Re: "Paths" ?
3. Re: APRS+SA and PK12
4. Re: DX cluster spots on APRS (the RIGHT way)
5. ICON faults of some clients
6. APRS Range Scale Standardization
7. Re: ICON faults of some clients
8. Re: SSID Conventions?
9. Re: SSID Conventions?
10. Re: DX cluster spots on APRS (the RIGHT way)
11. Re: Where's Dad?
12. Re: ICON faults of some clients
13. Re: SSID Conventions?
14. Re: SSID Conventions?
15. Re: DX cluster spots on APRS (the RIGHT way)
16. Re: "Paths" ?
17. Re: "Paths" ?
18. Re: "Paths" ?
19. Re: DX cluster spots on APRS (the RIGHT way)
20. Re: DX cluster spots on APRS (the RIGHT way)
21. Re: ICON faults of some clients
22. Kind of strange question...but
23. Re: Kind of strange question...but
24. ax25 utils and OS X
25. Re: ax25 utils and OS X
26. Re: Re: "Paths" ?
27. Re: ax25 utils and OS X
28. Re: ICON faults of some clients
29. Re: ax25 utils and OS X
30. Re: ax25 utils and OS X
31. Re: Kind of strange question...but
32. Re: SSID Conventions?
33. NSTAR 03-F scheduled for Sunday, 9 Nov
34. WinAPRS and Precision Mapping 3.5
35. RE: WinAPRS and Precision Mapping 3.5
----------------------------------------------------------------------
Subject: Where's Dad?
From: Bob Bruninga <bruninga@usna.edu>
Date: Thu, 6 Nov 2003 23:51:12 -0500 (EST)
X-Message-Number: 1
Placing an ICON on your KIDS PC desktop to shown them "where DAD is" only
takes 3 clicks of a mouse and is so easy I cant believe I just got around
to it!
Yea, I know, I'm too dumb to own a PC....
But bring up MAP.FINDU.COM/YOURCALL and when the page appears:
Right click, select CREATE SHORTCUT
Click on "this will create a shortuct on your desktop"
Then click on the ICON and change its name to "Where's Dad"
wow, that was easy...
We have had APRS in the family for many years, and yet the kids and MOM
have never used it to find dad because "you can take a horse to water but
you can't make him drink..."
But having just ONE desktop ICON click do the whole thing should raise the
ease-of-use factor.
I'm embarassed that I didnt know that configuring a desktop shortcut to
bring up a specific web page was so trivial until now! duh...
bob
----------------------------------------------------------------------
Subject: Re: "Paths" ?
From: Bob Bruninga <bruninga@usna.edu>
Date: Fri, 7 Nov 2003 00:01:45 -0500 (EST)
X-Message-Number: 2
On Thu, 6 Nov 2003, Robert Mitchell / KD4PBC wrote:
>Before I had it set to relay, wide7-7 I was told that this would
>guarantee that my location made it to the APRS-IS network.
Yes, sort of like the advice that standing naked on the Whitehouse lawn
will get you on TV... it works, but might not be the best way...
My recommendation has always been RELAY,WIDE,WIDE. (but that wont work in
SOuthern California, (and I think maybe Arizona or NM or any area where
RELAY is not supported). In vast regions which are totally WIDEN-N, then
you can use RELAY,WIDE2-2, but that wont work well in some older areas of
the country that have a lot of WIDE-only digis.
It is trivial to tell. Just look at any APRS map fo the areas you travel,
display only digipeaters (reduces map clutter) so you can see the digi
ICONS better, and if all you see are green stars with the "N, U, S"
overlays, then do it RELAY,WIDE2-2. If you see a lot of "W"'s then stick
with the R,W,W...
Bob
----------------------------------------------------------------------
Subject: Re: APRS+SA and PK12
From: "Tim Cunningham" <tim_cunningham@mindspring.com>
Date: Thu, 6 Nov 2003 22:33:48 -0600
X-Message-Number: 3
I would highly recommend putting the PK12 in the KISS mode and set
APRS+SA to work with the KISS mode. This will eliminate the CMD
interface nuances.
Tim - N8DEU
----- Original Message -----
From: "Joe Della Barba" <joe@dellabarba.com>
To: "TAPR APRS Special Interest Group" <aprssig@lists.tapr.org>
Sent: Thursday, November 06, 2003 9:47 PM
Subject: [aprssig] APRS+SA and PK12
>Anyone know why the TNC seems to be constantly setting Unproto?
----------------------------------------------------------------------
Subject: Re: DX cluster spots on APRS (the RIGHT way)
From: Bob Bruninga <bruninga@usna.edu>
Date: Fri, 7 Nov 2003 00:16:02 -0500 (EST)
X-Message-Number: 4
Yes, a great idea for client programs but doesnt necessarily solve the
FINDU problem.. but good thinking...
bob
On Thu, 6 Nov 2003 BobDonnell@arkalmus.com wrote:
>Perhaps a different solution makes more sense - set a radius around the
>current station location where if the DX spot is within the circle
>defined by that radius, the DX spot will be ignored - not considered as
>DX. And let the user decide what's not DX for them.
>
>73, Bob, KD7NM
----------------------------------------------------------------------
Subject: ICON faults of some clients
From: Bob Bruninga <bruninga@usna.edu>
Date: Fri, 7 Nov 2003 00:28:45 -0500 (EST)
X-Message-Number: 5
Part 1:
On Thu, 6 Nov 2003, Steve Dimse wrote about the APRSdos SYMBOL attributes
that were never implemented in many client programs (that use ICONS):
>It certainly is not out of ignorance. Bob has been pushing this since
>MacAPRS came out [WITHOUT THEM] nearly 10 years ago, and early GUI APRS
>developers like the Sprouls, myself, and Brent all were APRSdos users
>first, if for no other reason than there was no other choice.
>
>I maintain it is because this is simply not useful to most users, who
>would rather have symbols that are easy to identify (and yes, even
>pretty) than to have three bits of information conveyed by symbol color.
RESPONSE:
I will use some CAPITAL letters to emphasize some words that I think are
critical to UNDERSTANDING the important points involved here, I am not
shouting... But after 8 years of debating this, most people have not seen
this recently... Here is my response:
Yes, because "most users" dont care how it works (and dont know what they
are missing) as long as it looks pretty... I'd challenge ANYONE who wants
to use APRS as a real live "situational awareness display" to admit to me
that they don't care if an ICON on a map conveys the following information
IMMEDIATLY to the observer (without having to go CLICK on it):
Is it moving?
If moving is it more than 1 minute old?
Is it an OBJECT from someone else?
Is it one of the OBJECTS I am responsible for?
Is it an OLD ICON more than 80 minutes old?
Is it the old position of an object that just this instant moved?
Is it Message capable?
Is it ambiguous? What is the size of the ambiguity?
Is it marked with one of the 36 OVERLAY characters possible?
Is it also a digipeater? (even if it is not using the DIGI ICON?)
(APRSdos conveys all this info by the color of the ICON or a circle around
it)
>Not everything needs to be done as Bob does. In fact this is a wonderful
>thing, I wouldn't want to be using APRSdos for Macintosh. APRS has
>benefited greatly from the freedom to do things differrently than Bob.
And this "differently" has so crippled the concept of APRS that MOST Users
these days are not aware of how APRS is supposed to work and is supposed
to be used for REAL-TIME tactical stressful situations where operators
dont have time to be mousing around the display constantly clicking on
every ICON just to figure out what is happeing THIS INSTANT.
Sure these client programs are pretty and look cute when one browses the
global APRS system and looks at all the thousands of ICONs from all over
the world, and in that environment from one's shack, 99.999% of APRS
users could care less about these attributes on every ICON. But THAT IS
NOT APRS. That is a nice global view for fun... that keeps APRS
interesting.. (I love it too) But it is NOT what APRS was designed to
do...
HIDING IMPORTANT REAL-TIME INFORMATION IS NOT HOW TO DO TACTICAL REAL-TIME
SITUATIONAL DISPLAYS. Such displays MUST present to the user all of the
important attributes about each ICON visually (and efficiently) WITHOUT
operators haveing to CLICK on each ICON every few minutes!
Maybe not every atribute needs to be always displayed, but every atribute
that has to do with TIMELINESS and PRECISION OF the ICON. Look at the
list above of these atributes and you will notice that most of them are
necessary for the viewer to grasp the timeliness and precision of what he
is seeing.
Try projecting a typical MAP at an EOC from one of these deficient client
programs. NO ONE IN THE ROOM has a clue about ANY of the attributes
above on ANY of the projected ICONS!!! Only the operator, and HE has to
CLICK on every single ICON on the map one at a time to get the info by
personal interpretation of the raw packet in some cases.
This is NOT what I call tactical-real-time human engineering... and it is
the MAJOR failure of many client programs that call themselves "APRS".
>What is needed is certain commonality. For example, whether a station
>can accept messages is something that does need to be passed on to the
>user. It is fine to require that that information be made available to
>the user. However, to dictate that it must be made through the color of
>the symbol is counter-productive in my opinion.
And in ABSOLUTELY EVERY POST I HAVE EVER MADE ON THIS SUBJECT, I HAVE SAID
OVER AND OVER that I do not expect authors to use colors. How they
present the atributes is THEIR OPTION. I only use APRSdos's colors for
an EXAMPLE as how the information IS CONVEYED to EVERY VIEWER. (though I
cannot think of an easier or better way that does not introduce more
clutter).
If I was a Winders programmer, I would do it easily by simply placing the
small ICON in a small surrounding circle of the DOS color attribute. It
is so simple to do, and being COMMON to DOS use of color it could become
common to all client programs as well. Wouldn't that be neat.
Cross-platform information transfer! Wow, what a concept! (sarcasm
intended)...
>On the other hand, in Mac and other windowing environments, this
>[clicking on something] is a normal action. So, if I need to know if
>station can accept a message, it is trivial to double click on the
>station and bring up a window, containing this (and tons of other
>information).
But again, requires a thoroughly one-on-one engaged operator willing to
click on every ICON on the map to find out what it is doing there and
whether it is new, recent, old, precise, an object or moving, etc...
On an APRSdos projected display, ANYONE IN THE ROOM can look up at the
large display and see INSTANTLY if there is a message capable mobile in an
area!
Without these atributes the ICON means only one thing: At some time since
this PC was brought on line, something placed an ICON there... what it
means "NOW" you have to go click on it to find out... This was never the
intent of APRS...
>Furthermore, in javAPRS (and in findU for that matter), you never had
>the ability to send a message to a station anyway, so why should I be
>forced to place this information on my display???
Well, Here is an example: Say, I may have a Kenwood HT in my office, and I
may use FINDU to see what is going on across the country in an area of
immediate interest. And when I zoom in, I see someone I'd like to talk to
in real time. I cannot send a message in FINDU, but I can key it into my
HT, and if APRS-IS works like it is supposed to, I can communicate real
time with that person... using the HT for comms and FINDU to see the
world!
>What I was claiming was that it wasn't done because it didn't make sense
>to the developers of the programs, and further wasn't demanded by their
>users. There is a big difference here!
And that is what has totally crippled APRS in their implementations.
APRSdos was written from the ground up by a Naval Officer who spent his 20
year naval Career as a combat systems officer in the tactical-real-time
situational displays of the US Navy. At the time of the writing of
APRSdos, it took advantage of the entire legacy of military
tactical-real-time displays and in fact, when released, APRSdos did BETTER
at most MAP displays than the billion dollar all-seeing-all-knowing Aegis
Class Crusiers that were/are the mainstay and newest technology of the US
fleet. It is absolutly amazing how much of the FUNDAMENTALS of APRSdos
were omitted from most follow-on CLINET programs for expediency..
>>I can define popup menus trivially for each symbol, specific to the top
>>of object it is and what facets it's carrying. I can use the built in
>>drag and drop to relocate them, with 'drop' actions causing the new
>>positions to be transmitted for object that I own.
>
>Yes, you can, and that is nice idea. Problem is, this is exactly what
>Bob is arguing AGAINST! Bob wants to take away your freedom to do this
>sort of innovative design, instead just show the symbol with those 8
>colors he dictates to show those three bits of information! No pop up
>menus allowed!
Absolutely not. I WELCOME the presentation of these ICON ATTRRIBUTES in
ANY WAY THEY CHOSE and WOW, I wish I could do that in DOS. But you are
absolutely right that I am TOTALLY FRUSTERATED by some of the major
authors NOT doing ANYTHING to convey this information.
For 8 years, I have pointed out how the failure to convey these ICON
attributes is killing the useability of APRS in real-time use. And
conveying to the MASSES that APRS is just stagnant ICONS on stagnant
maps. No wonder 98% of the rest of HAM radio sees APRS this way... these
days, none of them hve seen APRSdos and so they dont know that ICON's
have many other atributes...
In the same 8 years time that we have debated this, only a few of the
authors have taken the time to innovate their own solution. Instead, they
just complain about how APRSdos did it...
Bob
----------------------------------------------------------------------
Read previous mail | Read next mail
| |
