| |
ZL3AI > APRDIG 10.06.04 10:58l 761 Lines 29348 Bytes #999 (0) @ WW
BID : 3423-ZL3AI
Read: GUEST
Subj: TAPR Digest, Jun 04, 7/8
Path: DB0FHN<DB0FOR<DB0MRW<DB0WUE<DK0WUE<DB0RES<ON0AR<ZL2BAU<ZL2BAU<ZL3VML
Sent: 040610/0805Z @:ZL3VML.#80.NZL.OC #:25592 [Chch-NZ] FBB7.00i $:3423-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
Subject: Re: OPENtrack incompatibilities
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Fri, 04 Jun 2004 20:36:01 -0400
X-Message-Number: 149
>>>Jeff King <jeff@aerodata.net> 6/4/04 6:13:43 PM >>>
>Your such a wonderful person to work with Bob.
Thanks, you should really try working *with* me, for once, instead of
always against me. You would find that I am open to all kinds of new ideas
and like to find ways to integrate new things in to APRS or modify it to
fix any real problems or incorporate new needs.
I think just about anything can be done within the APRS spec, be compatible
with existing systems and still not break anything.
Bob
----------------------------------------------------------------------
Subject: Re: 30 Meter Policing needed.
From: James Smith <k9apr@sbcglobal.net>
Date: Fri, 04 Jun 2004 19:41:33 -0500
X-Message-Number: 150
Hi Scott,
I'm new to the 30 meter game, but I have observed a few things also like
the amount of VHF traffic on HF... I thought VHF traffic wasn't supposed
to be gated to HF or I'm wrong in assuming that?
Scott Weis wrote:
>OK One more thing, I have been keeping any eye on the frequency all day.. I
>now hear what appears to be a 1200 baud signal, with 1000 hz ship on the
>frequency. Please check your equipment.
>
>73,
>Scott KB2EAR
--
UI-Webserver http://k9apr.no-ip.org
73, James, K9APR
Chairman \ Coordinator
Tri-State APRS Working Group
http://www.tawg.org
mailto:k9apr@tawg.org
Run a APRS Website? Why not join the APRS Webring. http://www.tawg.org/join.htm
----------------------------------------------------------------------
Subject: RE: How about making OpenTrak part of APRS SPEC?
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Fri, 04 Jun 2004 20:57:23 -0400
X-Message-Number: 151
>>>"Scott Miller" <scott@opentrac.org> 6/4/04 5:07:18 PM >>>
>Dang near every innovation I've suggested for APRS
>has been shot down because Bob doesn't want it that
>way, or because it wouldn't work with the Kenwoods.
Nope, I dont shoot down anything. But when I see ideas that are not well
thought out, or that overlook common sense, or that are not aware that they
already are fully supported in APRS, I simply point that out. If that dose
of logic shoots it down, then it probably means it diserved it.
>Take the issue of static objects - mostly houses - everywhere.
>I proposed giving digipeaters enough smarts that you could
>hand over an object's position, with DNS-style expiration and rate
>parameters, and leave it up to the digi to handle announcing
>the object.
And there is nothing in the existing protocol that prohibits this. In
fact, it is fundamental to the protocl that anyone or thing can take over
reporting of an object. I only pointed out several reasons why it was a bad
idea:
1) Digis dont know what the intent of the originator is
2) It takes more traffic to hand off to the digi and more
traffic to communicate between the dumb digi and
the originator what is needed.
3) It takes more traffic to kill it or move it when the situation
changes.
4) If it is so static that it just sits there such that it is a
good idea to move it to the digi, then it seems to be
wasted air time and shouldnt be on APRS in the first place.
>Such a scheme would require defining some vocabulary
>to indicate the requested rate, expiration time, and so on.
>In APRS, adding these to existing formats isn't practical.
Yep, because its already there. Anyone can put in an expiration time. That
was added to APRS several years ago. And there IS NO RATE needed for
objects in APRS. The Decaying algorithm which is fundamental to ALL
situations is HIGH for new data and low for old data. There is no need to
define FIXED rates which are too INFREQUENT to be useful in real time or
are TOO VERBOSE all the rest of the time...
>That's why OpenTRAC is designed the way it is.
Why? Because you havent taken the time to see how to do these simple
things in APRS?
> In this example, you might tack on a digi service request
>element that says 'this object will be here for at least
>10 hours, and requests an update interval of 10 minutes.
You can tack that onto any existing APRS object just by including he EXP
extension...
>Two problems with doing this in APRS:
>It's impractical to add these parameters to existing formats.
>Bob doesn't want to do it that way.
Wrong on both counts:
1) it is trivial to add the parameters
2) Doesnt matter what I want or dont want, you can do it anway. The
existing APRS object format already INCLUDES these capabilities...
>Now, don't take this as a personal attack on Bob.
>But when it comes down to it, proposed changes to the
>existing formats will almost certainly come to nothing
>without his support. Adding new formats leaves
>'10,000 Kenwood users' out in the cold.
I just try to use common sense. Nothing in the above shows me any reason
to mess around with the SPEC, since you can do it all within the existing
protocol.
That's my job. TO keep APRS from splintering into a hundred different
directions when in most cases you just have to think a little to do what
you want within the existing spec. There is plenty of flexibility there...
And you get the added bonus of it being receivable on all other APRS
systems immediately! Wow, now that is progress!
Bob
----------------------------------------------------------------------
Subject: RE: the group...
From: blairhogg@comcast.net
Date: Sat, 05 Jun 2004 01:01:20 +0000
X-Message-Number: 152
Yeah, but this bickering back and forth is filling up my inbox - I'm about
to sign off the group for a week or two until it dies down.
Blair WB3AWI
>That's very true :)
>Julian
>Oh8gej
>
>-----Original Message-----
>From: "Rochte,
>everyone here is very passionate
>about APRS. And that can't be a bad thing, even if it does get a little
>ugly at times!
>
>Cheers,
>Robert
>KC8UCH
----------------------------------------------------------------------
Subject: Another tracker up and running
From: "Andrew Rich" <vk4tec@hotmail.com>
Date: Sat, 5 Jun 2004 11:03:54 +1000
X-Message-Number: 153
www.tech-software.net/
Runs on a 9volt battery
----------------------------------------------------------------------
Subject: Re: Sky Diamond 6 landing site prediction
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Fri, 04 Jun 2004 21:01:27 -0400
X-Message-Number: 154
>>>Jeff King <jeff@aerodata.net> 6/4/04 6:11:05 PM >>>
>>Since the GPS likely powered off during descent,
>>the OPENtracker will not be transmitting at all. The radio
>>and Opentracker are likely powered up right now
>>but sitting idle.
This is where the APRS vicinity tracking would at least show the closest
DIGI if it was still transmitting an occasional APRS status packet. Even
if the GPS data had quit.
Bob
----------------------------------------------------------------------
Subject: RE: OPENtrack verus APRS format example
From: "Scott Miller" <scott@3xf.com>
Date: Fri, 4 Jun 2004 18:13:58 -0700
X-Message-Number: 155
>Sure, That's easy. Here is the Mic-E version that is not
>only APRS, but is fully Kenwood compatible too:
>'h9"l!8v/]"4%}comment/12v 75F/DOP5/6 sats
>It shows no gobbledygook on the display and shows:
> "comment/ 12v 75F/DOP5/Sats=6"
And none of the stuff embedded in the comment is machine readable.
>Please, Lets see your OPENtrack version.
In hex:
0C 10 18 DC 17 7B AA 5D 7A D6 0F 89 BC 05 11 3E 38 3E 6E 05
34 D8 19 0D 15 07 16 E6 96 87 E5 AD 97 04 13 9C 04 57 83 05
00 0C 84 05 03 00 F0 04 12 41 42 43 03 14 00 0D
As decoded by listen:
fm N1VG to OPNTRK via WIDE ctl UI^ pid=77(OPENTRAC) len 56
OpenTRAC decode (56 bytes):.
EID 0x10 len 11: Position: Lat 34.959000 Lon -120.424000 Alt 183.000000
meters.
EID 0x11 len 4: Time: Wed Jan 29 12:49:50 2003
EID 0x34 len 4: GPS: 3D Fix Valid SPS, 8 sats HDOP=2.5 PDOP=1.3 VDOP=2.1.
EID 0x16 len 6: Display Name: ??
EID 0x13 len 3: Course: 312 Speed: 79.991997 kph.
EID 0x500 len 1: 12 Volts.
EID 0x503 len 2: 240 Kelvins.
EID 0x12 len 3: Text: ABC.
EID 0x14 len 2: Position +/- 13 meters.
I've stripped the Kanji from this decode, but if anyone cares to see a
screenshot of either a Windows or Linux box decoding it properly, let me
know. I've included a positional ambiguity element for good measure.
It's entirely machine-readable, and the client is free to display the
information in whatever way it wants to.
Yes, you can put human-readable text in the APRS comment field all day long,
but when we're talking about adding meaningful extensions, that only goes so
far.
Notice that APRS has defined methods to present the temperature and voltage
values, but you weren't able to use them here. What about a PHGR extension?
Can a DF bearing go in there too?
Lest someone think that big string of hex means a lot of bandwidth, that's
56 characters, equivalent to this string:
abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcd
Yeah, it sacrifices some bandwidth for element tagging, but you've got
position to the centimeter and time to the second, including year, plus all
the extra GPS data. And a Kanji display name.
Scott
N1VG
----------------------------------------------------------------------
Subject: Re: Solar tetroon Sky Diamond 6 aloft right now!
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Fri, 04 Jun 2004 21:09:45 -0400
X-Message-Number: 156
>>>Jeff King <jeff@aerodata.net> 6/4/04 6:20:11 PM >>>
>Fact is, it is incompatible.
>
>Again, show us your data. The more your weave and
>jive, the more shallow this whole exercise becomes.
Read the last 200 emails on the APRSSIG and you will get a better
description than I could ever provide..
Bob
----------------------------------------------------------------------
Subject: APRS additions to the spec
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Fri, 04 Jun 2004 21:23:48 -0400
X-Message-Number: 157
>>>"Andrew Rich" <vk4tec@hotmail.com> 6/4/04 6:25:02 PM >>>
>Why would you drive a spec to satisfy the commercial
>production of kenwood radios
We didnt. APRS existed long before Kenwood joined in.
It was because there was a well defined protocol that
they took the risk of investing millions to produce a radio
that was compatible with that spec.
>I have read the APRS spec back to front and buried in
>there is a "User defined payload"
>
>I don't see anyone else besides Scott having a go.
So why isnt he taking advantage of it instead of trashing everything and
trying to re-invent the wheel? Using the user defined protocols the
following additions have been implemented on APRS:
1) MITEL GPS data formats
2) Transmission of NASA one and 2 line Satellite Keps
3) two new Special weather formats
4) Special Appalachain trail emergency APRS communicators
5) Telemetry for PCSAT2 Solar Panel Experiments
That's pretty diverse stuff already using these user defined formats...
Again, I bet I can think of a way to do ANYTHING within the existing APRS
spec that will still be compatible with what is already on the air...
That's my job. I help people that ask or are looking for ways to add
things..
Bob
----------------------------------------------------------------------
Subject: Re: Solar tetroon Sky Diamond 6 aloft right now!
From: "Scott Miller" <scott@3xf.com>
Date: Fri, 4 Jun 2004 18:21:23 -0700
X-Message-Number: 158
>>The specs say nothing about how a PID is supposed to
>>be monitored in a TNC.
The specs don't say a TNC can't output everything in EBCDIC either, but that
would seem to be a bad idea as well.
>What is it exactly that you cant seem to understand?
What I can understand is why, given the PID filtering option, you'd choose
to allow non-APRS data into an APRS-only application, even if you DID have a
reasonable expectation that no one would ever deliberately transmit non-APRS
data on the channel.
Scott
N1VG
----------------------------------------------------------------------
Subject: Re: OPENtrack incompatibilities
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Fri, 04 Jun 2004 21:30:41 -0400
X-Message-Number: 159
>>>Jeff King <jeff@aerodata.net> 6/4/04 6:40:29 PM >>>
>>I'm not sure how you can claim "non-interfering" either.
>>Any packets that are not APRS compatible collide with
>>other legitimate APRS packets and do not seem to me
>>to be able to claim to be non-interfering...
>OpenTrak still uses CSMA. Basic layer one stuff Bob, just
>like APRS. TAB put out a really good book on packet radio...
Ah, so just like on a voice net that is set up for passing NTS traffic for
example, as soon as you hear the channel go silent for a second, you think
it is your RIGHT to just bust in and send your DX spots?
Its that kind of arrogance that is making OPENtrack unwelcome on APRS in
many users minds...
Bob
----------------------------------------------------------------------
Subject: RE: OPENtrack incompatibilities
From: "Scott Miller" <scott@3xf.com>
Date: Fri, 4 Jun 2004 18:41:23 -0700
X-Message-Number: 160
>1) store-and-forward: Not applicable on APRS which
>is a real-time system for tactical real-time local events.
Not a problem, because OpenTRAC's not APRS. See, I couldn't have done that
at all in staying within APRS. Consider the example of multiple SAR teams
covering their assigned search areas. Thanks to the terrain, they're out of
direct contact 80% of the time. With this implemented, they'd be able to
forward on track histories of their out-of-contact time - possibly through
another team as relay - back to the command post for continuous tracks, not
in real time but as close to it as possible. Useful, yet not within the
bounds of what you'll allow in APRS.
>2) backbone routing: No one ever opposed this.
>APRS can do this just fine. In fact, we have propsed
>many methods that will work. In fact, Steve's APRS-IS
>does that very well right now...
Can it allow digis to negotiate filtered links along RF backbones? Or allow
a station to request that it be gated to a given geographic area?
>3) digipeater-maintained objects: Crazy idea. OBJECTS
>in APRS are supposed to be live, vibrant, moving things
Bob, how many of the things on your APRS screen are moving right now? How
many of them never move at all? This is EXACTLY why I can't work within the
framework of APRS, because if it doesn't have your stamp of approval, we
can't even experiment with it.
>same non-moving objects, then they probably shouldnt
>be APRS objects but should be map features that should
>be applied with local map overlays.
And then you get to distribute to everyone (including out-of-area
responders) map overlays (that work with their chosen client) to include
things like your repeaters, EOC, and so on. What happened to
come-as-you-are?
>the latest info post it. The last thing we need are
>digipeaters spewing out more non-real-time packets.
They're going to spew out this information whether you want it or not. The
masses have spoken, and they like seeing icons on their maps. No, it's not
what you want for APRS, but it's reality. This scheme means far LESS
traffic generated by these stations.
>Not vehement opposition, just common sense in good network design...
Your opinions. Not necessarily bad ones, but opinions that mean I can never
reasonably expect to try the things I want to try within APRS.
Scott
N1VG
----------------------------------------------------------------------
Subject: OPENtrack APRS comparison
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Fri, 04 Jun 2004 21:44:15 -0400
X-Message-Number: 161
>>>"Scott Miller" <scott@opentrac.org> 6/4/04 7:35:53 PM >>>
>>4) APRS allows extensions just just fine
>
>And they're severely limited for the reasons I've already
>given.
Nope, not at all. And I still have not seen anything in OPENtrack that you
could not already easily do in APRS if you just took the time.
>>what kind of gobbldygook is this. In the first paragraph
>>you make all kinds of claims for OPENtrack and in the
>
>I asked you to show me an APRS packet that does this.
I have: 'h9"l!8v/]"4%}comment/12v 75F/DOP5/6 sats
This fully compatible APRS packet shows no gobbledygook on the display and
shows everything you requested: LAT/LONG/CSE/SPD/ICON/comment/Voltage/Temp/DOP
and number of satellites... AND it displays on the EXISTING kenwoods just
fine...
>I have no intention of doing anything with any Kenwoods.
>I'm making a point about the lack of extensibility in APRS..
You're not making that point at all. What you are showing is that you
havent taken the time to see how easy it is to include just about anything
you want in the existing protocol.
>>I never intended to imply anything otherwise. You are a
>>fantastic programmer and asset for the community, I
>>only said you were new to APRS.
>And you know this how? I first touched APRS in the
>mid-late '90s. DOS maps and TAPR Mic-E's didn't impress
>me much, and I didn't get into it heavily until 2002.
Yep and that was only a few months ago. It takes getting "into it heavily"
in order to be able to understand how to take advantage of it. It is very
easy to just invent a new protocol and always harder to dig in and
understand an existing one...
Bob
----------------------------------------------------------------------
Subject: Re: OPENtrack incompatibilities
From: "Scott Miller" <scott@3xf.com>
Date: Fri, 4 Jun 2004 19:05:20 -0700
X-Message-Number: 162
>APRS is a distributed network, with everyone on the
>channel sharing tactical-real-time data of value to
>everyone on the net. It is not a me-first-screw-everyone-
And in that sense, how is sending an OpenTRAC packet any different from
sending a user-defined APRS format that no one knows how to decode?
>stated purpose of the net, or which is encoded such as
>to deny others on the net to see it.
Again, it's not in any way obfuscated. I like to think the protocol is
fairly clearly laid out.
>That is pure OPENTRAK propaganda. Please show me
>your packet that contains LAT/LONG/CSE/SPD/ICON
>and does it in less than the 25 byte APRS packet below:
>K4HG>SN0YX2:'abcdef/>
Mic-E is a contrived format that sacrifices resolution, ease of decoding,
and established uses of the TOCALL field to save space. As I mentioned
earlier, I've considered a separate PID for this sort of use that'd
eliminate element overhead, but the increased efficiency isn't worth the
trouble. I think I figured the payload required at 9 bytes for the
equivalent of your Mic-E packet.
Next, that's hardly an average APRS packet. When I look at my console, I
see NMEA and regular uncompressed format. I see only one guy running Mic-E
without an absurd comment string. That's an 11-byte payload. 10 bytes in
OpenTRAC gets you position to 1 centimeter, with no data in the AX.25 header
so it's transport-independent. Altitude adds 3 bytes vs. 9 for a regular
APRS packet.
Yes, it's possible to construct smaller APRS packets. I didn't say it
wasn't. I'm saying that the average packet is going to be more compact.
>None of those have anything to do with running
>incompatible OPENtrack protocol on the APRS system.
Why do I feel like we're going in circles? Now is when I say "it's not
incompatible", and we start over with that debate again.
>No it was not. There is nothing in the APRS protocol
>that permits non APRS PID packets on the national APRS
>channel. Inventing your own non-APRS-FLAG and
Not my flag, yours. And the standard method of protocol identification in
AX.25. And then there's the TOCALL. To quote the spec:
"Any other destination address not included in the specific generic list or
the other categories mentioned above may be used in Alternate Nets
(ALTNETs) by groups of individuals for special purposes. Thus they can use
the APRS infrastructure for a variety of experiments without cluttering up
the maps and lists of other APRS stations. Only stations using the same
ALTNET address should see their data."
So I don't see how we have a problem. According to the spec you ratified,
it's solely an opt-in thing.
>When you start throwing binary data onto a channel
>that has a clear protocol, then almost any possible
AX.25 is not a clear protocol. It's binary, and one of many possible PIDs
commonly carries text.
>There aren't any incompatibilities. Sure people can
How is the non-printable filter requirement (needed to avoid mangling
posits) any different than the need to set the PID filter option?
Scott
N1VG
----------------------------------------------------------------------
Subject: RE: OPENtrack verus APRS format example
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Fri, 04 Jun 2004 22:05:07 -0400
X-Message-Number: 163
>>>"Scott Miller" <scott@3xf.com> 6/4/04 9:13:58 PM >>>
>The APRS version: "comment/ 12v 75F/DOP5/Sats=6"
>
>And none of the stuff embedded in the comment
>is machine readable.
Shucks, I can do that in about 3 lines of BASIC. I would think anyone
could do it... And besides it is HUMAN READABLE! APRS is supposed to be
for human to human communication. I'd take the HUMAN readable 28
characters above over the MONSTOROUS VERBOCITY you are touting in the 56
character OPENtrack below:
>The OPENtrack version:
>0C 10 18 DC 17 7B AA 5D 7A D6 0F 89 BC 05 11 3E 38 3E 6E 05
>34 D8 19 0D 15 07 16 E6 96 87 E5 AD 97 04 13 9C 04 57 83 05
>00 0C 84 05 03 00 F0 04 12 41 42 43 03 14 00 0D
>As decoded by listen:
>
>fm N1VG to OPNTRK via WIDE ctl UI^ pid=77(OPENTRAC) len 56
>OpenTRAC decode (56 bytes):.
>EID 0x10 len 11: Position: Lat 34.959000 Lon -120.424000 Alt
183.000000
>meters.
>EID 0x11 len 4: Time: Wed Jan 29 12:49:50 2003
>EID 0x34 len 4: GPS: 3D Fix Valid SPS, 8 sats HDOP=2.5 PDOP=1.3
VDOP=2.1.
>EID 0x16 len 6: Display Name: ??
>EID 0x13 len 3: Course: 312 Speed: 79.991997 kph.
>EID 0x500 len 1: 12 Volts.
>EID 0x503 len 2: 240 Kelvins.
>EID 0x12 len 3: Text: ABC.
>EID 0x14 len 2: Position +/- 13 meters.>
>
>It's entirely machine-readable, and the client is free to
>display the information in whatever way it wants to.
APRS was designed around the simple printable ASCII character set so that
it was human and machine readable and so that it could EASILY be described
in text format and could fit in Email.
>Yes, you can put human-readable text in the APRS
>comment field all day long, but when we're talking
>about adding meaningful extensions, that only goes so
>far.
So far, I have seen that it goes far enough for anything that has been
requested...
>Notice that APRS has defined methods to present the
>temperature and voltage values, but you weren't able
>to use them here.
Didnt need to. You asked for a position report with temperature and
voltage. No need to send an entire telemetry protocol...
>What about a PHGR extension?
Not needed on a moving vehicle with course and speed. In fact, it makes no
sense...
>Can a DF bearing go in there too?
Yes, the standard APRS DF report can be on any position report, fixed or
moving. No problem..
>Lest someone think that big string of hex means a lot
>of bandwidth, that's 56 characters, equivalent to this string:
>
>abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcd
But why not compare it to the APRS actual packet that only took 28:
"comment/ 12v 75F/DOP5/Sats=6"
>Yeah, it sacrifices some bandwidth for element tagging,
>but you've got position to the centimeter and time to the
>second, including year, plus all the extra GPS data.
>And a Kanji display name.
Thanks, dont need it. If I need that stuff, I can send it in APRS too...
though not to the centimeter. That just seems a waste of bandwidth to
me...
Bob
----------------------------------------------------------------------
Subject: OPENtrack PID complaints
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Fri, 04 Jun 2004 22:09:31 -0400
X-Message-Number: 164
>>>"Scott Miller" <scott@3xf.com> 6/4/04 9:21:23 PM >>>
>What I can understand is why, given the PID filtering
>option, you'd choose to allow non-APRS data into an
>APRS-only application, even if you DID have a reasonable
>expectation that no one would ever deliberately transmit
>non-APRS data on the channel.
Because we didnt "choose" anything:
1) Its a TNC function and not part of the APRS protocol and beyond our control.
2) APRS never was designed to be compatible with OPENtrack. It was
invented 12 years ago, long before OPENtrack was a gleam in your eye...
Bob
----------------------------------------------------------------------
Subject: Too many personalities
From: Wes Johnston <wes@johnston.net>
Date: Fri, 04 Jun 2004 22:07:27 -0400
X-Message-Number: 165
Bob, I can remember a ham in Chaleston tell me, why do we need faster
packet? I can only type with two fingers. Yes, GPS can't do CM accuracy
_today_, but what about tomorrow... what about objects placed on a map by
hand which I don't want to jump 60 feet as soon as they go out on the
air? There is a valid reason to use CM accuracy in altitude and
position.... it is just not apparent _today_. Odds are that it will be
appreciated sometime in the next several years.
As much as it will probably upset you (and I really wish it wouldn't), you
are right ... open track is full of 20/20 hind sight... and we have aprs to
THANK for that... We know better now how a local tactical asset tracking
protocol can be used and we have learned lots of lessons in the past (ahem)
26 years... grin.... It's time to stop shoe horning more and more into the
comment field. Now the comment field has to use contextual clues to decode
a packet.
Perhaps APRS should be locked down and no further changes made. Perhaps we
are better served to put our efforts into a system which solves the
multiplicity of WX station data and unknown icons (open trac uses a
hierarchical tree to resolve icons, so if you don't know a specific icon,
you can back up one branch on the tree and take a best guess). Open trac
also strives to not use any ax25 tricks (like longitude in the TOCALL of
mic-e packets) - because it is intended to be easily transported over
TCP/IP or ax25, or the Next Big Thing. APRS on the other hand, is stuck to
portions of ax.25 like glue.
Jeff King bought up an analogy last night about race... asking something to
the effect "what color is your APRS". Along those lines, it seems that
everyone is taking sides and failing to see just how similar we (races of
people and/or flavors of APRS) are. In the case of people, we all have
arms and legs, breathe air and put our pants on one leg at a time. In the
case of APRS, I will define what aprs is... It is a real time, tactical
asset tracking system which uses unconnected frames and redundancy to
convey information. Open trac is the same... it uses unconnected frames to
convey the same information that APRS can. The devil is in the details of
course, but there is a way to stop these packets from being misinterpreted
by aprs clients. Simply make a simply software adjustment on your TNCs to
stop the monitoring of non 0xF0 packets until the client you are running
can handle strange packets without choking. That should have been done the
entire time, but no one caught it. To say that APRS always sends packets
with F0, but that doesn't mean it has to only RX 0xF0 packets is crazy. I
am appalled that all these defensive and egotistical attitudes have
surfaced as a result of this issue. This thread has gone on so long that it
has turned into a personality conflict which needlessly persists long after
a solution was presented.
Additionally, as kc4pl brought up in a conversation with me tonight, what
is the difference between an open track packet (which at this time is not
aprs compatible per the aprs spec) and a packet received by a TNC with an
error in it? There isn't!! APRS clients have to accept bad or malformed
packets gracefully. If any don't, they needed to have been fixed long
before open trac came along. Let's not shoot the messenger here, let's
address the real problem.
What's really going to hurt my feelings is that if Steve and James
Jefferson decide to exclude opentrac packets from findu and aprsworld
instead of writing parsers for them. That is of course their prerogative.
And those of us who think these packets don't belong on APRS... if a packet
can't be decoded by every client, does that mean it does not belong on
APRS? My kenwood won't display NMEA 2.0 dumb trackers or compressed posit
objects, but yet those packets exist on the air and simply show up as ?? on
my display. Are we to raise all kinds of hell about that and crucify the
people sending those packets? Just as the APRS spec has evolved to include
new methods and compressed position reports, so can it take in and include
opentrac when OT is mature and settled enough to have worked out all or
most of the kinks. I say again: There is no reason APRS SPEC cannot
include opentrac elements and the two live side by side. There is no
reason a tracker or any clientsoftware cannot be made to decode or ignore both.
And in closing, my usual disclaimer... Hope I haven't hurt any feelings...
Hope this is simply a frank discussion of the issues.
Wes
----------------------------------------------------------------------
Read previous mail | Read next mail
| |
