| |
ZL3AI > APRDIG 09.06.04 08:31l 402 Lines 16361 Bytes #999 (0) @ WW
BID : 3416-ZL3AI
Read: GUEST
Subj: TAPR Digest, Jun 03, 6/6
Path: DB0FHN<DB0FOR<DB0MRW<DB0ERF<DB0FBB<DB0GOS<ON0AR<ON0AR<LU6DTS<JE7YGF<
HA3PG<ZL2TZE<ZL3VML
Sent: 040609/0503Z @:ZL3VML.#80.NZL.OC #:25540 [Chch-NZ] FBB7.00i $:3416-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
Subject: How about making OpenTrak part of APRS SPEC?
From: Jeff King <jeff@aerodata.net>
Date: Thu, 3 Jun 2004 21:43:09 -0400
X-Message-Number: 110
On Thu, 03 Jun 2004 19:23:48 -0400, Robert Bruninga wrote:
>>>>"Curt, WE7U" <archer@eskimo.com> 6/3/04 4:42:22 PM >>>
>>Because the protocol identifier byte is supposed to allow multiple
>>protocols (AX.25 and others) to co-exist on the same channel. Let's
>>find out which ones don't and get the manufacturer to issue a
>>firmware upgrade so that they operate properly on the network.
>
>That will never be successful. It is better to simply keep the APRS
>network for APRS and not start hosing it up with non-compatible
>protocols.
But Bob, there is a mechanism for changes to APRS. It is called the APRS-WG
and it is clearly outlined in the APRS-WG charter.
IMHO, APRS has to grow and adapt, and more importantly, be open to others
ideas besides your own. OpenTrak was specifically created to address
shortcomings in APRS.
So, what do you say Bob? How about being a sport here, and drop the NIH (Not
Invented Here) attitude? Give Scott the chance to work within the agreed
upon and adopt method for change in APRS, and please follow the charter you
yourself signed back in 1999. Can't say for sure if he would propose it, but
most certainly he won't if you continue to lock others ideas out of APRS.
Without change and progress, APRS will eventually die.
----------------------------------------------------------------------
Subject: Re: Solar tetroon Sky Diamond 6 aloft right now!
From: "Scott Miller" <scott@3xf.com>
Date: Thu, 3 Jun 2004 18:58:50 -0700
X-Message-Number: 111
>You have excellent talents and motivation, rather than
>trying to tear down something that is working, you
>could focus more on all the positive things that you
>could contribute... Three is just so much that needs
>to be done...
I'm not trying to tear down anything.
I DO have a lot to contribute, but I discovered early on that it's just not
going to happen within the framework of APRS. I was hopeful when I first
read in the spec that it allows user-defined formats. But it turns out that
for all practical purposes, they're worthless. If you create one, you take
on the monumental task of trying to get every author to support it, or you
won't get so much as a position parsed out of your format. And even if you
manage that, you've committed the mortal sin of creating something
incompatible with the Kenwoods.
Put something in the comment field? We've already got a ton of garbage
shoehorned in there, each with a different parsing rule. Pack it
efficiently, and you've got Kenwood users with little LCD screens full of
unreadable garbage they don't want to see.
More importantly, my original goal of an efficient local-area mesh network
for reliable SAR tracking, command, and control would have been too much of
a strain to force into the framework of APRS to make it worth trying. It
made more sense to start from scratch and try to learn from the past.
And for the record, I like to think that I've done at least a little bit to
help out APRS, as well. For one, I designed and now sell the least
expensive commercially available APRS tracker kit (not counting illegal
TinyTrak knockoffs from South America), it's completely open source, and has
a number of features not found in any other trackers. I've put many, many
hours of work into the project, and all of that work is available to benefit
the community at no cost - I've already got at least one person building
their own boards completely independently of my kit sales.
I may be a relative newcomer on the scene, and I may not see things the same
way as you, but I'm in no way 'tearing things down'. I'd like to think that
all I've contributed to the community might at least make up for a few
corrupted packets in FindU.
Scott
N1VG
----------------------------------------------------------------------
Subject: Re: Solar tetroon Sky Diamond 6 aloft right now!
From: Jeff King <jeff@aerodata.net>
Date: Thu, 3 Jun 2004 22:06:30 -0400
X-Message-Number: 112
A little reality check here....
On Thu, 03 Jun 2004 20:10:03 -0400, Robert Bruninga wrote:
>>>>"Scott Miller" <scott@opentrac.org> 6/3/04 4:00:28 PM >>>
>>The point is, it should NOT hear this. The only way this is going
>>to happen is if someone disregards the PID or the TNC is broken and
>>shows non-text traffic in converse mode.
>
>Sorry Scott that you have to re-learn what people who have been in
>packet for the last 26 years have always known about TNC's and
>AX.25.
AX.25 wasn't created until ~1982, and PID was a integral part of it since
about that time.
http://www.tapr.org/tapr/html/pktf.html
2004-1982 = 22 years, not 26. Packet (ascii) wasn't legal in the U.S. 26
years ago.
>You cannot use PID's as discriminants on an AX.25 network with come-
>as-you-are TNC's without all kinds of unpredictible results. This is
>common knowledge.
But the whole point of PID's is to PREVENT unpredictable results. Your 180
degrees out of phase with reality here.
>It is also why 12 years ago when we invented APRS that we could not
>use PID's then, nor plan on expecting everyone on the planet to
>upgrade their TNC's so that we could use it at any conceivible time
>in the future.
That is not what the spec says. The spec, in the appendix, references AX.25
UI frames in the TAPR AX.25 specification. Crystal clear.
Or is the APRS specification/charter a work of fiction that can be
disregarded anytime it seems prudent?
>Yes, KNOWING this, we did declare that APRS would use the F0 PID on
>TRANSMIT, but that in no way implies that it can be used as a filter
>on receive by every TNC on the air. We receommended that you not
>attempt this on the APRS network.
Sorry, but you referenced the AX.25 spec which says just that. Maybe you
should amend the APRS spec to not reference the ax.25 spec?
>Believe me, in the past 26 years of AX.25
You mean 22 years?
>The APRS infrastructure was build by thousands of volunteers in
>response to their enjoyment of the APRS protocol. I think many of
>them welcome new things but they dont like to see their hard work
>and existing system threatened by incompatible procotols.
How exactly is "their hard work" threatend? Don't confuse progress with being
threatned, unless progress is considered a threat in APRS.
Be clear here, who and what is threatned? All this chicken little stuff is
growing old.
----------------------------------------------------------------------
Subject: Re: Balloon and Aircraft Paths
From: "Joe Della Barba" <joe@dellabarba.com>
Date: Thu, 3 Jun 2004 22:17:16 -0400
X-Message-Number: 113
I operate airmobile and I would never use wide,wide.
One wide is PLENTY from altitude.
73
Joe N3HGB
----------------------------------------------------------------------
Subject: Re: Solar tetroon Sky Diamond 6 aloft right now!
From: Steve Dimse <k4hg@tapr.org>
Date: Thu, 3 Jun 2004 22:21:12 -0400
X-Message-Number: 114
On 6/3/04 at 8:58 PM Wes Johnston <wes@johnston.net> sent:
>Steve, does this mean that you invented a system and now no one else can
>play unless they follow your rules?
Bob, myself, and the other early shapers of APRS created a system, and then
we codified the rules, the APRS spec. I fought hard during the spec writing
to include a way for anyone to experiment, this is called the user defined
format. In fact, all of the opentrack protocol could be used as is, simply
by inserting three bytes at the front of every packet. Were it done this
way, it would be fully compatible with everything APRS, and pose no risks
to the existing system.
Instead, the creators of opentrack chose a mechanism that is incompatible
with APRS, where a packet can have too meanings different in the two
different systems.
It is perfectly fine that they chose this path, but in making the choice,
they knowingly made themselves incompatible with APRS. Now, they want
everyone to change for them.
Look, there is a basketball league near me. If I want to play, I agree to
play by their rules. If I want, for example, to play a game where I can
hold the ball and run with it, and I can get enough people to play the game
with me, I certainly can do that, but it isn't basketball, and we can't
play in their league. I can't go to the courts on league day and demand
they let me play my new game, even if my friends and I thing our game is
better. I have to use their rule book.
The APRS Spec is the APRS rule book. It was created so people could write
their parsers to the same set of rules, and know they would work. Sure, the
APRS protocol is a maze of special cases, sure any one of us could do
better if we could start from scratch, but guess what, we can't start from
scratch. Backward compatibility is important to APRS users. Opentrack is
not compatible with the rule book. No one is saying people can't deveop
opentrack, no one is saying people can't use opentrack. All I am saying is
opentrack should not be on 144.39. it is not APRS.
Steve K4HG
----------------------------------------------------------------------
Subject: Re: Solar tetroon Sky Diamond 6 aloft right now!
From: Jeff King <jeff@aerodata.net>
Date: Thu, 3 Jun 2004 22:23:13 -0400
X-Message-Number: 115
On Thu, 3 Jun 2004 17:59:08 -0700, Scott Miller wrote:
>I think today's balloon adventure demonstrates this pretty clearly.
>We've had hundreds of OpenTRAC packets heard by many, many stations
>across a wide area, and no reports of mass client failures.
I didn't think of that, but your right, no complaints from the peanut
gallery. It was at peak altitude in early evening half way between
Pittsburg and Cleveland. One would thing the SIG would be alive with
complaints of the corrupted packets.... At least half the northeast part of
the U.S. should have been hearing it, with a RF radius in the range of 360
miles at altitude.
>In
>fact, I'm not aware of any corrupted positions received anywhere but
>FindU. And had this not been a publicized event, I doubt the
>corruption would have attracted any notice at all.
Good point.. I was thinking this was a good time to bring this issue to a
head, that is, the complete failure of the APRS specification process
consider change/progress from 'outsiders', but maybe going back to a
stealth mode/ "build it and they will come" is better.
The protocol problems being beat to death here, are (almost) a non-issue.
----------------------------------------------------------------------
Subject: Re: Solar tetroon Sky Diamond 6 aloft right now!
From: Steve Dimse <k4hg@tapr.org>
Date: Thu, 3 Jun 2004 22:26:40 -0400
X-Message-Number: 116
On 6/3/04 at 5:59 PM Scott Miller <scott@3xf.com> sent:
>It is NOT incompatible with APRS. It's just not compatible with converse
>mode on some TNCs.
Are you denying there are textual representations of packets in opentrack
that have a completely different meaning in APRS?
Are you denying that as it exists now, there are no opentrack packets that
could be transmitted on 144.39 and be interpreted with an incorrect meaning
by some APRS users?
I'm not denying that if some authors updated his software to one degree or
another, if all affected APRS users upgraded, and if every IGate changed to
KISS that it could not be made compatible. I AM saying that as things exist
now, it is not compatible.
Steve K4HG
----------------------------------------------------------------------
Subject: Re: Solar tetroon Sky Diamond 6 aloft right now!
From: Ernie Howard <w8eh-Ernie@cinci.rr.com>
Date: Thu, 03 Jun 2004 22:33:55 -0400
X-Message-Number: 117
Scott and other pro-opentrack ops,
How about stepping back, take the blinders off for a minute and look at
this argument from a slightly different prospective.....
Gentleman's agreements and band plans.
There are gentleman's agreements and band plans in place for a lot of
frequencies. Two meters and APRS is one of them. 144.39 is recognized
nationwide as the APRS frequency. You would not run APRS on 146.52, a
recognized FM voice calling channel. You would not run FM voice on 144.200,
the SSB calling channel. If you run a non APRS function on 144.39 and cause
disruption, would that not risk potentially invoking the wrath of Riley?
Back in the heyday of packet, we had very good band plans and agreements
that segregated different types of packet uses. Keyboard contact on one
frequency; dxcluster on another; bbs systems on several; tcp/ip on
another. These uses were incompatible most of the time. We all played
nice and got along, except for a few who marched to their own tune to
the detriment of all others. They got lid listed out of the networks
until they figured out the benefit of following the plans.
Scott Miller wrote:
>It is NOT incompatible with APRS. It's just not compatible with converse
>mode on some TNCs.
From what I've read here, it sounds incompatible with MOST TNCs.
Ernie
Ernie Howard, Jr W8EH Middletown, Ohio
----------------------------------------------------------------------
Subject: Re: Solar tetroon Sky Diamond 6 aloft right now!
From: "Richard Amirault" <ramirault@erols.com>
Date: Thu, 3 Jun 2004 22:37:03 -0400
X-Message-Number: 118
On this page (APRS World...) the date/time stamp seems to be off by an hour.
I assume that it is UTC time listed, but (by my clock) it is about one hour
"slow"
Or am I not seeing something..?
Richard Amirault N1JDU Boston,
MA, USA
www.erols.com/ramirault "Go Fly A Kite"
----- Original Message -----
From: "Jeff King"
Subject: [aprssig] Re: Solar tetroon Sky Diamond 6 aloft right now!
>Here is a ongoing track of the flight:
>
>http://maps.aprsworld.net/datamart/track.phtml?call=KC8UCH-11&hours=72
----------------------------------------------------------------------
Subject: Re: Solar tetroon Sky Diamond 6 aloft right now!
From: Neil Johnson <njohnsn@njohnsn.com>
Date: Thu, 3 Jun 2004 22:32:35 -0500
X-Message-Number: 119
What about all of us who have old KPC 3+ 's or run aprsd which pretty much
precludes running a TNC in KISS mode.
Kantronics KPC's are not flash enabled. Don't expect many of us to splurge
$10-$20 (plus shipping and handling) for a new eprom.
I thought in the APRS spec there was an APRS message type for non-standard
messages ? That seems the appropriate way to experimental posit and telemetry
formats.
As for routing: One has to remember that APRS tries to implement layer 3
(network) functionality using layer 2 (data link) functionality. An ingenious
solution by Bob, but it has it issues.
The true way to fix APRS short comings is to develop a separate more robust
layer 3 protocol. That helps APRS remain true to its "tactical" roots, but
reduces (I'm not going to say eliminate) the traffic issues we have now.
Neil Johnson
http://www.njohnsn.com
PGP key available on request.
----------------------------------------------------------------------
Subject: Re: Solar tetroon Sky Diamond 6 aloft right now!
From: "James Jefferson" <jj@aprsworld.net>
Date: Thu, 3 Jun 2004 22:41:12 -0500 (CDT)
X-Message-Number: 120
>have to give the definitive answer as to how he is filtering them out,
>my guess he is filtering on the OPNTRK ALTNET. However, as Scott points out,
>this is a completely legal ALTNET address, and the infrastructure is not
>supposed to filter based on ALTNETs, it is up to the clients to do so.
There are two things on aprsworld that are preventing the OpenTrac packets
from getting into the data as Base-91 APRS packets.
1) I am dropping anything that is to the OPNTRK destination address. There
are certain addresses that get dropped already (all the no archive stuff)
so I added another one to the list.
In general, as a software developer, I hate having "magic" constants like
this in software. But in this case dropping the opntrk packets wil fix the
problems being seen and will really not effect anyone besides those
sending opentrac packets.
2) I don't insert position packets that are at 0,0 or where absolute
latitude is greater than 90 degrees or absolute longitude is greater than
180 degrees. I've been doing this forever because there are way too many
broken stations.
fwiw,
-Jim KB0THN
---
END OF DIGEST
Read previous mail | Read next mail
| |
