OpenBCM V1.13 (Linux)

Packet Radio Mailbox

DB0FHN

[JN59NK Nuernberg]

 Login: GUEST





  
ZL3AI  > APRDIG   17.11.03 11:50l 285 Lines 11632 Bytes #999 (0) @ WW
BID : 2292-ZL3AI
Read: GUEST
Subj: TAPR Digest, Nov 06, 1/5
Path: DB0FHN<DB0THA<DB0ERF<DB0FBB<DB0GOS<ON0AR<ON0AR<7M3TJZ<LZ3NP<KD7HAH<
      GB7BHX<GB7LGS<GB7BHM<ZL2BAU<ZL3VML
Sent: 031117/0851Z @:ZL3VML.#80.NZL.OC #:13002 [Chch-NZ] FBB7.00i $:2292-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To  : APRDIG@WW

TAPR APRS Special Interest Group Digest for Thursday, November 06, 2003.

1. SSID Conventions?
2. Re: SSID Conventions?
3. Re: SSID Conventions?
4. Re: SSID Conventions?
5. Re: DX cluster spots on APRS (the RIGHT way)
6. Re: SSID Conventions?
7. Re: DX cluster spots on APRS (the RIGHT way)
8. Re: DX cluster spots on APRS (the RIGHT way)
9. Re: SSID Conventions?
10. Re: SSID Conventions?
11. Re: SSID Conventions?
12. Re: [ Scott Miller ] Re: SSID Conventions?
13. Re: DX cluster spots on APRS (the RIGHT way)
14. Re: SSID Conventions?
15. Re: DX cluster spots on APRS (the RIGHT way)
16. Re: DX cluster spots on APRS (the RIGHT way)
17. Re: DX cluster spots on APRS (the RIGHT way)
18. Re: SSID Conventions?
19. "Paths" ?
20. Re: "Paths" ?
21. Clock chip for the T-238
22. Re: DX cluster spots on APRS (the RIGHT way)
23. Re: "Paths" ?
24. Re: DX cluster spots on APRS (the RIGHT way)
25. Re: Kenwood D-700 and KPC-9612
26. Re: SSID Conventions?
27. Re: SSID Conventions?
28. Re: DX cluster spots on APRS (the RIGHT way)
29. Re: SSID Conventions?
30. Re: Available TNC's
31. Re: DX cluster spots on APRS (the RIGHT way)
32. Re: SSID Conventions?
33. Re: DX cluster spots on APRS (the RIGHT way)
34. APRS+SA and PK12
35. aprs balloon tracking in Southern California
36. Re: SSID Conventions?
37. Where's Dad?

----------------------------------------------------------------------

Subject: SSID Conventions?
From: "Gary V. Smith" <gvsmith@locallink.net>
Date: Thu, 06 Nov 2003 08:04:11 -0500
X-Message-Number: 1

Awhile back someone listed what the SSID dash numbers conventions indicate 
about a station.  I thought I'd saved that list, but apparently I 
didn't.  Would someone please list them again?  And, specifically, what 
would a -7 indicate?  Thanks.

73,
Gary - W6GVS

----------------------------------------------------------------------

Subject: Re: SSID Conventions?
From: Joe Della Barba <joe@dellabarba.com>
Date: Thu, 6 Nov 2003 09:34:17 -0500
X-Message-Number: 2

-7 is an aircraft and -5 is a sailboat.
There is a file someplace that lists them all.
73
Joe N3HGB (-5,-7)

----------------------------------------------------------------------

Subject: Re: SSID Conventions?
From: "Tim Cunningham" <tim_cunningham@mindspring.com>
Date: Thu, 6 Nov 2003 08:56:17 -0600
X-Message-Number: 3

Download the APRS DOS documentation. The protocol and symbols are
all documented very well. The TAPR web site www.tapr.org also contains
the APRS specification for downloading.

The following came from the SYMBOLS.TXT in the APRS DOS README
directory:

AMBULANCE       (SSID = 1)
BUS             (SSID = 2)
FIRE TRUCK      (SSID = 3)
BIKE            (SSID = 4)
YACHT (sail)    (SSID = 5)
HELO            (SSID = 6)
Small AIRCRAFT  (SSID = 7)
SHIP (pwr boat) (SSID-8)
CAR             (SSID = 9)
Motorcycle      (SSID = 10)
BALLOON         (SSID = 11)
JEEP            (SSID-12)
REC. VEHICLE    (SSID = 13)
TRUCK           (SSID = 14)
VAN             (SSID = 15)

73's,
Tim - N8DEU
Huntsville, Alabama

----------------------------------------------------------------------

Subject: Re: SSID Conventions?
From: "Scott Miller" <scott@opentrac.org>
Date: Thu, 6 Nov 2003 08:17:45 -0800
X-Message-Number: 4

I've seen this before, and I still can't help thinking that it's totally
pointless.  I've got more than one station, so I have to choose one of the
other SSIDs.  Yet all of the non-zero SSIDs have other meaning attached to
them - meaning that's completely duplicated in the symbol system.  More
importantly, there's no way to indicate that the SSID is significant, so
even if you do have a tracker on an ambulance, how do you tell that apart
from hundreds of other -1 stations that AREN'T ambulances?  Is there
something I'm missing here?

Scott
N1VG

----------------------------------------------------------------------

Subject: Re: DX cluster spots on APRS (the RIGHT way)
From: "Gregg G. Wonderly" <gregg@skymaster.cytetech.com>
Date: Thu, 06 Nov 2003 10:27:10 -0600
X-Message-Number: 5

>I do understand this is the way you set up APRSdos, but to developers and 
users
>of other systems, it makes no sense. In a windowing environment, it makes much
>more sense to be able to point at an object and get all the details, rather 
than
>to try to convey a few of bits of information with color. Monochrome icons
>(excuse me, symbols) just won't fly in a windowed environment. There is a 
reason
>no other APRS program implements your color symbol plan, and I think you need 
to
>accept that.

Steve, I don't think that you can speak for all developers with this kind
of snotty nosed expert talk.  I think that this kind of carrying on about
your opinion regarding Bob's design is what continues to fragment the
software that tries to support APRS from being what it really could be.  It
may be hard to implement, but that does not make it bad.  I find it to be
really amazing how easy it is for Bob to do what he has done in APRS Dos,
with basic, and no Object Oriented support.  He has created a object system
(apparently) and managed all the facets.  I don't know how his software
works, but I still find it refeshing to see how much attention he has paid
to the real details and how effective such a simple graphical system can be
at depicting so much information.

It appears that many of the APRS software packages have failed to carry all
of the facets around and use them effectively.  There is no reason that the
rendering can not happen as Bob suggests in any 'windowing' environment.
The software development environments that many packages use may make it
easier to use an Icon.  I've used VC++, and the drawing libraries are very
tedious. But, that does not, make it impossible to draw multi-faceted
symbols.

Java makes it much easier.  You can create Swing Icon implementations that 
have their own rendering routine and report their size dynamically.  You
can then put these Icons into JLabels, and place those onto a JDesktopPane.
What this means is that they are now distinct objects in the system.  Thus,
they are painted in an optimized way that I don't have to implement.  I
don't have to watch the clipping rectangle and draw half of objects etc.
The Swing rendering takes care of that for me (on all OSes).

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.  With some interfaces between the
Symbols and the map implementation that is plugged in as the render for the
JDesktopPane, you can make the ambiguity circles only be visible when you 
mouse over the symbols.  Thus, confining the information visible at any
time to just what the user is interested in.  You could make this an option
to turn on and off under user control.

>As to plotting ambiguity circles, fortunately virtually no one transmits
>ambiguous positions, if they did I can imagine the mess that would make on you
 r
>map!

I don't transmit them because none of the popular software packages support 
them correctly.  Otherwise, I would use them to spot areas where severe 
weather predictions need spotters to be.

It may be that the idea doesn't work or scale in some of the applications
that you think about.  Fine, don't use it for those applications.  That
does not at all mean that the concept is useless.

I am still trying to find time to work on JeAPRS to make it do all of the 
things above.  The map rendering is really the hardest part.  I have most
of the rest of APRS working.  Yes, it is a hard road.  Yes, it can be
trying on the patience.  But, that does not mean that these ideas are
worthless or useless.

If this stuff wears you out, makes you frustrated and mad, then perhaps
this is not the game you should play in life.  This stuff is about learning
and having fun, not about being a slave and having a stressful life.

-----
gregg@cytetech.com  (Cyte Technologies Inc)

----------------------------------------------------------------------

Subject: Re: SSID Conventions?
From: Mark Cheavens <mcheavens@usa.net>
Date: Thu, 06 Nov 2003 10:46:47 -0600
X-Message-Number: 6

YES, Read the aprs specification for packet construction. SSID's are used 
as the designator IF NO OTHER means are used! It is the LAST fall back that 
is used. (as previously stated...For REALLY dumb trackers!)

Reading and understanding the entire specification clears of most of these 
questions.

http://www.tapr.org/tapr/html/Faprswg.html

Mark Cheavens
KC5EVE

----------------------------------------------------------------------

Subject: Re: DX cluster spots on APRS (the RIGHT way)
From: "Phil Pacier, AD6NH" <ad6nh@arrl.net>
Date: Thu, 6 Nov 2003 10:48:27
X-Message-Number: 7

On 11/05/03, "Steve Dimse <k4hg@tapr.org>" wrote:
>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.

Perhaps one solution (after all these bugs are dealt with) for the DX 
cluster objects is to create another parallel network, such as been done 
for APRS FIRENET.  This way, users can connect to a special server or port 
that allows for the displaying of the DX cluster objects (and perhaps even 
the IRLP objects that are now all over the place).  It's just an idea, but 
it worked for the FIRENET concept by offering an expanded feed with many 
types of objects to users who want to see them, while keeping the main 
APRS-IS intact with what you see on it today.

I have been involved in several "heated" discussions about various APRS 
topics, and if I've learned nothing else, I have learned one thing - we 
need to grow as the APRS user base grows.  I have changed my mind on some 
views I had a year ago due to the changing nature of the network.  The 
bottom line is, there are so many different uses for APRS that I no longer 
believe it is possible for a single program to work great for everyone 
(although I do have my favorite).  Also, as was seen with FIRENET, a single 
network is no longer going to make everyone happy.  I have tried to keep an 
open mind about the changes, and I think there are some on this list who 
need to consider that as well.  Many know how opposed I was to the original 
FIRENET objects being on the main APRS-IS, but I myself connect to the 
parallel FIRENET server from time to time when I want to see those objects. 
 It is possible to make this work, but I hate to see ego so heavily 
involved.  If one person wants to take credit for any fact of APRS, from 
its inception to software to networking, then you should have taken out a 
patent on it and commercialized it.  Many APRS users have developed tools 
and concepts and have never received any recognition - because it really 
should be necessary in this kind of a network.

The soapbox is buckling under me, so I'll get off - and I don't really have 
a right to be on it in the first place.  I just don't want to see the 
future of APRS jeapordized by discussions that have gone awry.

(Comments not directed at any recipient who might be listed in the header 
nor any recipient who happens to take the time to read this).

73
Phillip Pacier - AD6NH
http://www.aprsca.net

----------------------------------------------------------------------




Read previous mail | Read next mail


 23.10.2026 12:35:05lGo back Go up