| |
ZL3AI > APRDIG 11.06.04 10:03l 280 Lines 13281 Bytes #999 (0) @ WW
BID : 3432-ZL3AI
Read: GUEST
Subj: TAPR Digest, Jun 05, 8/8
Path: DB0FHN<DB0RGB<DB0MRW<OK0PPL<DB0RES<DK0WUE<HA3PG<7M3TJZ<F6KMO<EA5DVS<
EA5RQ<VK7AX<ZL2BAU<ZL2BAU<ZL3VML
Sent: 040611/0701Z @:ZL3VML.#80.NZL.OC #:25633 [Chch-NZ] FBB7.00i $:3432-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
Subject: RE: How about making OpenTrak part of APRS SPEC?
From: Jeff King <jeff@aerodata.net>
Date: Sat, 5 Jun 2004 23:26:42 -0400
X-Message-Number: 139
On Sat, 5 Jun 2004 21:53:07 -0500, Neil Johnson wrote:
>
>(I know I'm going to regret responding to you Jeff, but here it
>goes).
Then why do it? More importantly, why color a response with a statement like
that? Seems to me a good way to achieve exactly what you fear.
>Now one may think that means
>that Digi and Igate owners should fix their software, but since APRS is the
>existing infrastructure, the pressure is on open track to transmit packets
>that conform to that existing infrastructure.
OpenTrak does conform to the APRS spec, in that it should be treated as a
alien format (non 0xF0 PID), and discarded.
>I think it is great that people are looking into ways to improve
>APRS, but it shouldn't cause problems for the existing protocol.
What problems, that you observed first hand, were caused by OpenTrak other
then a massive increase in traffic on the APRSSIG?
>What should (and will most likely happen) is that when the "new,
>improved" APRS protocol arrives, as people realize that it is
>significantly better than the existing one, they will begin to
>migrate over slowly at first, and then as the "network effect" kicks
>in much more quickly.
That seems to be what I think also.
But do let me know what firsthand issues you observed on Thursday with the
OpenTrak. So what is to regret? (and you did know I would ask this, just as
I have asked every other person making such claims....)
----------------------------------------------------------------------
Subject: Re: The OpenTrac Debate and BS!
From: "Christensen, Eric" <CHRISTENSENE@MAIL.ECU.EDU>
Date: Sat, 5 Jun 2004 23:29:31 -0400
X-Message-Number: 140
I agree... I am in the process of reading the OT Spec (I have already read
the APRS Spec v. 1.0 many times). If what I have heard is, in fact,
accurate and OT is simpler to implement code-wise, then why not support
authors implementing the OT code in their own program and start a transition
over to a better code (I think Bob said that it had 20-20 hindsight). We
keep worrying about backwards compatibility when it really shouldn't be an
issue. The most popular "brands" of software are typically being updated
quite frequently (Xastir and UI-View) and it shouldn't take long before most
users to be compatible. As for the D700s/D7s, these units were flawed from
the day they hit the shelves and continue to be a thorn in the sides of
designers and code writers today. I don't know who uses these units to
monitor the area traffic, but I find it quite useless to "see" who is around
me. I DO use mine to send and receive messages and to act as a tracker. If
I can't decode an OT tracker next to me because the Kenwood won't do it, so
be it! I'll hook up a laptop to it and run a software decoder to "see" it.
AND, with hind sight being 20-20, I won't buy the next Kenwood APRS radio or
any other APRS radio in the future that won't support flash upgrades to
update it to the current spec.
Now, I CHALLENGE all the APRS brains out there to think twice before sending
another piece of crap to the SIG. I would love to have the five or ten
brains out there get together and come up with some hard data on the
advantages and disadvantages of OT and APRS and come up with the best
possible outcome for the future... I guess that is what the APRS-WG was
supposed to be doing, but if it is so difficult to get any ideas to them,
then what's the point. Anyone should be able to go to the WG with a
presentation and give good reason for additions and/or changes to the spec.
Lets stop all this bickering and work together for the best outcome of APRS.
If we do nothing but tread water then we won't get anywhere.
73s,
Eric KF4OTN
kf4otn@amsat.org
-----Original Message-----
From: Danny [mailto:danny@messano.net]
I think we have seen years of ideas coming to the table and constantly being
told what is good for the interests of APRS. This is per the small
"privledged" few that are the supposed knights templar of the APRS Spec.
I would need to search the archives to find how many things even WB4APR has
come up with over the years since 1.0 that he finally had to back down and
find a way to "work around" the spec to make them happen.
There are flaws in the APRS system. Much of it could be improved with an
APRS Spec 2.0. Perhaps it would be incompatible with APRS 1.0. Perhaps
authors would have to do some rewrites for 2.0. If the changes were
profound enough, then the users would follow.
Maybe it is time for an OpenTrac to come along and shake things up. Maybe
me need another APRS variation that lets the users decide what they want,
instead of the few "writers of the code" that would decide things for us.
Look at what happened to WinAPRS after UI-View came along.
Danny Messano
KE4RAP
----------------------------------------------------------------------
Subject: Re: [ Neil Johnson ] RE: How about making OpenTrak part of APRS SPEC?
From: "Gregg G. Wonderly" <gregg@skymaster.cytetech.com>
Date: Sat, 05 Jun 2004 22:29:11 -0500
X-Message-Number: 141
>Unfortunately APRS straddles both Layer 2 (Data Link) and Layer 3 (Network) of
>the standard network model. In a perfect world there would be separation of
>two, but that is the legacy of APRS.
Hi Neil! I think that you are mixing two things together here. APRS
specifies some things about attributes of the fields inside the AX.25 header
that it uses for routing on TNCs. But, these things do not dictate the
structure of the APRS data except a packets total length. If it was truely
intertwined, we could not send ASCII'zed versions of packets into the APRS-IS
which does not use AX.25 for transport.
>In fact, the reason the APRS protocol is the way it is is because Bob was
>making it COMPATIBLE with the AX.25 network protocols.
>
>Imagine were APRS would be today if Bob had used a completely different packet
>format, and told us all that we would have to "fix" (buy) completely
>different hardware in order to run APRS. It would have died on the vine.
>
>By making APRS so it could run on EXISTING packet technology WITHOUT causing
>problems is an important reason why APRS is where it is today.
The AX.25 protocol is first about signals that cause modulation to produce the
'bits' that make up the data inside the packets. Then, the AX.25 protocol
further specifies some structure to those bits by saying that there are
several fields.
o A TO-CALL with an SSID
o 7 PATH-CALLS with SSIDs
o a flags field
o a PID field
o data to the end of the packet.
o a two byte CRC
There are further statements about how the path calls are shifted one bit to
the left and the last used path element has the least significant bit set.
Plus, there are many other interesting details that are quite lengthy to
discuss here. It might be good to read the AX.25 spec to get the nitty-gritty
if you are interested.
What APRS does is specify how to use the data transported by this transport
protocol when the PID field is set to 0xf0.
The opentrac spec specifies how to use the data transported by this transport
protocol when the PID field is set to 0x70.
There are, as have been mentioned here, other protocols that use this
transport layer and specify another PID besides 0xf0 and 0x70. This is what
makes AX.25 so useful, and is why so many different uses have occured over the
years.
>As for the frequency thing. I seem to remember that we grudgingly but
>appropriately moved our frequency to 144.39 after complaints from satelite
>users about us INTERFERING with their operations.
This frequency change was necessary because of the highly different use that
the satellite crowd had with their very specific needs for non-interfering
comms. Packet radio applications have facilities to retransmit and guarentee
reception because they are digital modes with compute assistance that can do
things like check the checksum on the packet and make sure that only the data
that is needed gets through. Data and phone use on the same QRG doesn't mix
well.
>You don't see Internet users proposing a different Layer 3 protocol (IP) and
>demanding that all users replace/fix/upgrade their existing equipment to
>accommodate it. No, for the most part they run their protocol INSIDE the
>existing IP protocol (i.e. using the user defined APRS packet), OR they set
>up separate networks to implement ( IP V6 ) and provide conversions between
>the two (separate frequency).
IP V6 runs alongside IP V4 just fine because there is a protocol and version
number (just like the PID in AX.25) present in the IP datagrams, and the V4
only devices will outright ignore those packets. This is the great thing
about the design of IP. The design team knew the protocol would evolve, and
they accounted for that from the beginning. The network manufacturing
community has made sure that the equipment and software is ready for IP V6 to
coexist. They've been running both protocols together using IPV6 to
encapsulate IP V4 etc. Its been a long road to get everyone ready for IPV6,
but its is now really present everywhere from a supported perspective. As the
back bones roll over to using IP V6 with IP V4 encapsulation, the leaf nodes
will be able to convert too.
With OpenTrac, we could define an APRS encapsulation element that would allow
OpenTrac only networks to transport APRS packets into environments where that
is the only accepted format of telemetery data.
>In fact, one of the unwritten rules of Internet Protocols is "be strict in
>what you send, but liberal in what you receive". Now one may think that means
>that Digi and Igate owners should fix their software, but since APRS is the
>existing infrastructure, the pressure is on open track to transmit packets
>that conform to that existing infrastructure.
As software developers and manufactures are requested to repair their
implementations of AX.25, we will see a better opportunity to explore the
world of digital communications using AX.25 as a transport. Based on Curt's
work to determine how to make converse mode filter out non-0xF0 packets, it
looks like there are very few pieces of hardware that actually have problems.
Instead, we have some software configurations that need to be updated. Then,
we'll have no more issues with different protocols running on the digipeater
infrastructure.
>I think it is great that people are looking into ways to improve APRS, but it
>shouldn't cause problems for the existing protocol.
>
>What should (and will most likely happen) is that when the "new, improved"
>APRS protocol arrives, as people realize that it is significantly better than
>the existing one, they will begin to migrate over slowly at first, and then
>as the "network effect" kicks in much more quickly.
And luckily, we don't really have any issues that will keep this from
happening. OpenTrac may not be the one that does it, but we now all see that
there are existing AX.25 implementation details that make it possible for
everyone to try something different if they feel a different protocol is
required. If they want, they can use APRS for any TEXT based
experimentations. But, as has been pointed out, converse mode will be
impacted by any user defined packet that uses binary data formats that contain
carriage control characters.
-----
gregg@cytetech.com (Cyte Technologies Inc)
----------------------------------------------------------------------
Subject: Re: OPENtrack incompatibilities
From: "Gregg G. Wonderly" <gregg@skymaster.cytetech.com>
Date: Sat, 05 Jun 2004 22:36:23 -0500
X-Message-Number: 142
>Then what does this buy you ?
>
>If everyone is dropping OpenTrack packets. They won't be Digipeated or picked
>up on the APRS-IS.
>
>All you will be doing is tying up local bandwidth with worthless packets.
I don't think the primary mission goal of OpenTrac is to put packets on the
APRS-IS. Instead, I think it is intended to provide a locally used, compact
telemetry capability. Now, if at some point, someone sees some benefit to
archiving this data, as Steve Dimse did for APRS, then there might be some
IGATEs set up that do understand this PID, and that do send the data someplace
to be archived.
One thing that comes to mind is to standardize archived telemetry data into a
protocol agnostic format. Someone mentioned XML earlier. That might not be a
bad choice since there are tons of tools that easily understand XML, and that
would allow position reports, that currently arrive on the APRS-IS in many
different formats to be standardized. Thus, MIC-E to XML, base-91 compression
to XML, $GPRMC to XML and standard location to XML conversions could be
provided through a web server that would allow a wide range of new
applications to be created with a standard data format in place that would
eliminate all the rewritting of software to parse new types of data to use the
APRS-IS data or APRSworld data.
Humm, lots of possibilities...
-----
gregg@cytetech.com (Cyte Technologies Inc)
---
END OF DIGEST
Read previous mail | Read next mail
| |
