| |
ZL3AI > APRDIG 10.06.04 11:00l 855 Lines 29659 Bytes #999 (0) @ WW
BID : 3422-ZL3AI
Read: GUEST
Subj: TAPR Digest, Jun 04, 6/8
Path: DB0FHN<DB0FOR<DB0SIF<DB0EA<DB0RES<ON0AR<ZL2TZE<ZL3VML
Sent: 040610/0801Z @:ZL3VML.#80.NZL.OC #:25591 [Chch-NZ] FBB7.00i $:3422-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: Fri, 04 Jun 2004 17:25:52 -0500 (CDT)
X-Message-Number: 125
Quoting Robert Bruninga <bruninga@usna.edu>:
>>>>Jeff King <jeff@aerodata.net> 6/4/04 12:39:09 PM >>>
>>Ahh... but I used the word eventually. Here we are, 5
>>years after the SPEC was adopted, and things are static.
>
>Really?
Read the APRS charter. Static as in nothing has happened with progress, as you
agreed to in writing. "Static" in other words, which means, not moving.
>>Pete, like it or not, there has to be a mechnism for change
>>in APRS. It has to be fair..
>
>It is. Anyone can introduce new formats using the experimental
>extensions. It only costs them 2 bytes. And no one has been
>refused.
So your saying that the APRS-WG charter is not the proper mechnism?
Why don't you just cut through all the shucking and jiving here Bob, and
declare yourself the absolute dictator of APRS. I really don't think there is
anything wrong with this, it really brings some clarity to something that
otherwise is really just anarchy.
I'm serious, think about it.
----------------------------------------------------------------------
Subject: Re: Fw: RE: How about making OpenTrak part of APRS SPEC?
From: "Andrew Rich" <vk4tec@hotmail.com>
Date: Sat, 5 Jun 2004 08:25:02 +1000
X-Message-Number: 126
Why would you drive a spec to satisfy the commercial production of kenwood
radios
Thats seems silly. Yeah make that one of your considerations.
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.
Andrew Rich (VK4TEC)
www.tech-software.net
vk4tec@hotmail.com
space - electronics - radio - aviation
----------------------------------------------------------------------
Subject: Re: Sky Diamond 6 landing site prediction
From: "Scott Miller" <scott@opentrac.org>
Date: Fri, 4 Jun 2004 15:24:52 -0700
X-Message-Number: 127
>Well, no, even with a digipeat you can localize the area. CWID you'd have
to be
>close enough to hear it....
True... a TRACE might help in that department...
>Also, any way you can store the last valid fix? Last I saw it, it was falling
>south of Pittsburg.
Last-fix handling needs some work. In fact, it got a lot of work last
weekend, but it needs more. For one, I need to find RAM for a fix age
counter. And I really need to come up with a formal state chart that
defines the fix / transmit behavior - it's critical to reliable operation
and it's getting a bit complicated.
I did a quick attempt at a powersave mode last night, too. Seems to work -
I think it drops the average power consumption by 30 - 40%. That's in
'wait' mode - I'm having trouble with the 'stop' mode. If I can get that to
work right, it ought to reduce power consumption even more. All this comes
at the expense of timing accuracy and a slowdown in response time.
Scott
N1VG
----------------------------------------------------------------------
Subject: RE: How about making OpenTrak part of APRS SPEC?
From: Jeff King <jeff@aerodata.net>
Date: Fri, 04 Jun 2004 17:31:28 -0500 (CDT)
X-Message-Number: 128
Quoting Steve Dimse <k4hg@tapr.org>:
>On 6/4/04 at 11:39 AM Jeff King <jeff@aerodata.net> sent:
>
>>>This is not a matter of NIH, but a matter of trying to modify the spec
>>>to incorporate a completely different protocol.
>>
>>I understand that. But how does one do this? That is what the "NIH" was
>about.
>I already answered this. ANYONE can create a new APRS format message with the
>User Defined protocol. If you do so, and submit it to Bob, it goes up on
>the errata page.
OK, thanks, so then Bob is indeed the absolute dictator of APRS, and the
mechnisms the APRS-WG put into place, as clearly defined in the charter,
should be disregarded?
>If they wanted to be part of APRS, they shouldn't have ignored the
>options built into the protocol to accomodate them!
You mean like the APRS Charter & spec? If you care to read it, you'll see a
mechnism exists to accept things like OpenTrak just like MIC-E and Base91 was
included.
http://www.tapr.org/tapr/html/Faprswg.html
I don't think you should fault anyone for believing the people that signed this
document where sincere....
----------------------------------------------------------------------
Subject: Re: OPENtrack incompatibilities
From: Jeff King <jeff@aerodata.net>
Date: Fri, 04 Jun 2004 17:40:29 -0500 (CDT)
X-Message-Number: 129
Quoting Robert Bruninga <bruninga@usna.edu>:
>>>>"Scott Miller" <scott@opentrac.org> 6/4/04 2:16:26 PM >>>
>>Maybe I should clarify. By compatible, I mean non-
>>interfering as defined by the spec, not interoperable.
>
>I'm not sure how you can claim "non-interfering" either.
>The National APRS channel is already totally saturated.
>Any packets that are not 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, I think it was called "Packet Radio" that
explains some the basic stuff in packet, much better then current books.
http://www.amazon.com has some used copies available. Much recommended.
The Packet Radio Handbook by Mayo, Jonathan L TAB books
Packet Radio by Robert Rouleau TAB books (I think this is the one)
----------------------------------------------------------------------
Subject: Re: Solar tetroon Sky Diamond - signal loss????
From: "Bill Diaz" <william.diaz@comcast.net>
Date: Fri, 4 Jun 2004 17:50:28 -0500
X-Message-Number: 130
The OpenTrac'rs are demanding that the perpetrators be praised and the
victims be punished.
They are using a protocol that is not fully defined, and obviously never
tested in the real world until now. Unfortunately the test platform and
path they used caused us to be bombarded. So bear with them while they
re-invent the wheel. Hopefully, they will do this on another frequency to
minimize the harm to others, but don't count on it.
Bill KC9XG
----------------------------------------------------------------------
Subject: Re: TNC vs PID
From: Jeff King <jeff@aerodata.net>
Date: Fri, 04 Jun 2004 17:59:39 -0500 (CDT)
X-Message-Number: 131
Reality check
Quoting Steve Dimse <k4hg@tapr.org>:
>On 6/4/04 at 12:46 PM Scott Miller <scott@opentrac.org> sent:
>
>>> So the point of filtering them is toooo..... drop them??????
>How
>>>will they get anywhere near the network that way????
>>
>>That's exactly the point. The protocol is not compatible with the APRS
>IS.
>>We're only interested in using the digipeater infrastructure.
>>
>It is just as incompatible with RF APRS clients, unless they implement
>the changes you mandate!
Wrong.
http://www.tapr.org/tapr/html/Faprswg.html
>Perhaps because the APRS IS is of no use to you, you will encourage
>people to
>block the traffic, maybe in the hope of avoiding future arguments like
>this.
Scott, didn't you tell me you pilot a black helicopter for the Army? I'd like a
ride if so.
>On the other hand, you do wish to use the RF APRS network, but you do
>not seem care about forcing changes on APRS users,
What changes is he forcing?
/\/\/\/\/\/ (ascii image of me twiddling my thumbs waiting for a answer)
Yeap, that is what I thought.
>Pretty selfish attitude, if you ask me!
I was telling Scott off list that he will be drawn and quartered at the next
DCC. Did you ever see the movie "The last passion of Christ"? I didn't, but I
hear it was very gruesome. Maybe you can get some tips from it?? ;-)
----------------------------------------------------------------------
Subject: RE: How about making OpenTrak part of APRS SPEC?
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Fri, 04 Jun 2004 19:00:56 -0400
X-Message-Number: 132
>>>"Scott Miller" <scott@opentrac.org> 6/4/04 4:47:41 PM >>>
>Please, provide me with an example of an APRS
>packet that includes:
<snip>
>And:
>- Is readable by Kenwoods
>- Doesn't clutter up the Kenwood's screen
>- Doesn't introduce additional parsing rules for clients
>- Allows for more data to be added later without breaking anything
More OPENTRACK propaganda. Open track doesnt do any of those:
1) It is not readable by Kenwoods
2) It doesnt clutter, because they cannot even see it!
3) Opentrack introduces an entire protocol! what do you mean it
doesnt introduce new parsing rules!
4) APRS allows extensions just just fine.
Yes, Ill answer your challenge, but you post your OPENTRACKpacket first. Im
not even gonna waste my time until I see whether its worth it...
>For those who haven't looked at the OpenTRAC spec,
>my point is that even though the protocol is still in its
>infancy, it already does this. It's not readable by
>Kenwoods, of course, but if they'd been programmed
>for it...
what kind of gobbldygook is this. In the first paragraph you make all
kinds of claims for OPENtrack and in the second one you say that of course
it wont work unless Kenwood recalls all their radios and changes them to
match your new and better protocol.
>And for the record, this newbie programmer is well into
>his second decade of 'real' programming
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.
I just wish you were using your excellent tallents to make positive
contributions to the APRS that is, rather than trying to obsolete
everything so that it looks clean on paper..
There is so much you could do that would benefit everyone, instead of
trying to wreck the train so that you can re-build a network of your own
fancy...
Bob
----------------------------------------------------------------------
Subject: Re: Solar tetroon Sky Diamond 6 aloft right now!
From: Jeff King <jeff@aerodata.net>
Date: Fri, 04 Jun 2004 18:15:47 -0500 (CDT)
X-Message-Number: 133
Quoting Curt Mills <archer@eskimo.com>:
>On Thu, 3 Jun 2004, Robert Bruninga wrote:
>>protocols... Please dont trash ours...
>
>I kept thinking of this all day today as this thread was
>progressing: "It locks up our Vic-20's and C64's, so TCP/IP is
>evil and shouldn't be allowed on our packet frequencies". The
>Commodore computer problem used to be a real problem for some
>people. Somehow we got past that.
WOW.... catching up on some of the posts, and talk about DejaVu! Those are
EXACTLY some of the complaints when our group first started running TCP/IP
on the amateur bands back in the mid to late 80's, using Phil Karn's "NET"
and then later NOS and all its varients.
Somehow, we got by all that, and the hobby was much better because of it.
This exercise (NET/NOS) even spawned quite a few commercial spin-off's,
such as Tetherless access, numerous PPP stacks, and other things that hams
gave back to the world.
What heady days!!
All I can say, to Scott, Robert, you and all the other experimenters, is
keep at it! This is what this hobby is all about, experimenting and
advancing the state of the art.
73
Jeff wb8wka
----------------------------------------------------------------------
Subject: The new MicroTrak project based on the SMT TinyTrak3!
From: "Dave Anderson" <dave@aprsfl.net>
Date: Fri, 4 Jun 2004 19:27:16 -0400
X-Message-Number: 134
Hi everyone,
We've been beta testing the Surface Mount version of the TinyTrak3 for Byon
for some time.
We've built this into yet another project, and put a website about it up.
We've called this one the Microtrak.
http://www.aprsfl.net/microtrak
If you have questions about the design, let me know.
Seeya,
Dave
KG4YZY
www.aprsfl.net
----------------------------------------------------------------------
Subject: Re: OPENtrack incompatibilities
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Fri, 04 Jun 2004 18:39:13 -0400
X-Message-Number: 135
>>>"Scott Miller" <scott@opentrac.org> 6/4/04 4:17:59 PM >>>
>>Any packets that are not compatible collide with other
>>legitimate APRS packets and do not seem to me to be
>>able to claim to be non-interfering...
>
>I can send out a packet announcing where I am, so my
>family can watch online as I'm backpacking, driving
>around, or whatever. I don't care if anyone else on the
>local RF network can see me or not.
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- else channel....
>What difference does it make to anyone whether that
>packet is APRS or OpenTRAC?
Because it is just not gentlemanly behavior on established networks to just
jump in and start transmitting data that is not for the general benefit of
the net or within the stated purpose of the net, or which is encoded such
as to deny others on the net to see it.
>Other than the fact that the OpenTRAC packet is only
>going to take 60% of the bandwidth, that is.
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/>
>>Why should all APRSdom be prepared to handle
>>incompatible NON-APRS packets on the univerasal
>>APRS channel?
>
>1. Not everyone runs APRS on 144.39. APRS
> beacons on BBSs, for example.
>2. Sh*t happens. People QSY accidentally, or start
> the wrong program.
>3. People run TCP/IP to reconfigure remote servers.
None of those have anything to do with running incompatible OPENtrack
protocol on the APRS system.
>In short, it's poor engineering practice to do otherwise.
>Would you use a SSB radio that shut down whenever
>it heard an AM transmission?
No, but I would NOT WELCOME an SSB station on a designated National AM
channel!
>1. The packet was already explicitly flagged as
>non-APRS.
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 then complaining that people dont recognize it as a non-APRS-FLAG is
not fair to your fellow hams.
>2. An APRS packet needs a lot more than a single
>matching byte to be properly considered a valid packet.
When you start throwing binary data onto a channel that has a clear
protocol, then almost any possible occurrence of valid bits can occur. It
is for this reason that we receommended that you not use Binary and that
you not transmit incompatible protocols on the National APRS channel.
>So tell me again why Mic-E was considered a good
>idea? Widespread TNC incompatibilities didn't slow
>you down then.
There aren't any incompatibilities. Sure people can screw up just about
anything. But there are no TNC's that don't pass Mic-E packets just fine
when properly configured to pass standard ASCII.
Bob
----------------------------------------------------------------------
Subject: Re: OPENtrack incompatibilities
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Fri, 04 Jun 2004 18:19:13 -0400
X-Message-Number: 136
>>>"Scott Miller" <scott@opentrac.org> 6/4/04 4:03:05 PM >>>
>It's not all about the simple protocol vocabulary.
>As I've said repeatedly, the OPENtrak protocol is
>intended to support features like store-and-forward
>operation, backbone routing, digipeater-maintained
>objects, and so on.
Yes, all of which are incompatible with the very fundamnental basis of
APRS. Hence our suggestions to not try to shoehorn it on to the existing
APRS structure but to begin a parallel network which can then efficiently
support your ideas instead of being encumbered by all the problems you
claim the APRS network has.
>Stuff that'd be hard to do in APRS, and that you've
>vehemently opposed when it's been brought up
>within the context of APRS.
I wouldnt say "vehemently opposed", but simply "vehemently explained" why
it is a bad idea or won't work:
1) store-and-forward: Not applicable on APRS which is a real-time system
for tactical real-time local events.
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...
3) digipeater-maintained objects: Crazy idea. OBJECTS in APRS are
supposed to be live, vibrant, moving things like everything that is moving
at an event but doesnt have a tracker. If they are so static that you can
upload them to a digipeater so that it can keep repeating the same
non-moving objects, then they probably shouldnt be APRS objects but should
be map features that should be applied with local map overlays.
It is poor design to take up air time repeating the same non moving,
non-changing objects over and over again on the air? Put them on the map.
Or let the person with the latest info post it. The last thing we need
are digipeaters spewing out more non-real-time packets.
Not vehement opposition, just common sense in good network design...
de WB4APR, Bob
----------------------------------------------------------------------
Subject: Fw: RE: How about making OpenTrak part of APRS SPEC?
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Fri, 04 Jun 2004 19:04:39 -0400
X-Message-Number: 137
>>>"Andrew Rich" <vk4tec@hotmail.com> 6/4/04 5:03:30 PM >>>
>Why is the SPEC property of BOB ?
>
>I know he invented it, but surley it is for the good of the hobby.
>
>Why cannot there be a vote for additions or subtractions to a proposal
?
We welcome additions to the protocol that are intended to provide new
positive aspects to APRS and that dont instantly obsolete thouands of users
overnight...
That is what is good for the hobby. If APRS was not a standard, then
nothing would work and no one could write compatible code because it would
always be changing to the latest whims...
Bob
----------------------------------------------------------------------
Subject: Re: Solar tetroon Sky Diamond - signal loss????
From: Steve <s.jones@rogers.com>
Date: Fri, 4 Jun 2004 19:40:06 -0400
X-Message-Number: 138
On Jun 4, 2004, at 1:23 PM, Curt, WE7U wrote:
>
>You have the advantage of the HamHud software being easily upgraded,
>with several active developers. Use that advantage.
Could probably be upgraded to even handle the Opentrac format as well
as regular APRS.
--
Steve <s.jones at rogers.com>
----------------------------------------------------------------------
Subject: Re: Solar tetroon Sky Diamond - signal loss????
From: "hasan schiers" <schiers@netins.net>
Date: Fri, 4 Jun 2004 18:36:31 -0500
X-Message-Number: 139
Bravo and Mega-dittos, Bill.
All RF networks are local. If forced to, we can eliminate the intruders as
needed. We can prevent their access to the infrastructure. No digipeating,
no network.
Others (who manage and maintain) can and will decide for themselves.
At worst this is an attempted hijacking, at best it is a parasitic
infection. It contributes nothing to the aprs network, it merely steals the
resources of the infrastructure, for its own self-serving ends. Go
experiment somewhere else. Some (perhaps most) of us who built and now
maintain these networks are not interested in being "used" as a test bed by
a non-APRS compliant protocol. It's just that simple.
Get over it.
....hasan, N0AN
(On its own network, I would consider OpenTrack a an interesting and even
worthy innovation.)
----------------------------------------------------------------------
Subject: RE: How about making OpenTrak part of APRS SPEC?
From: "Scott Miller" <scott@opentrac.org>
Date: Fri, 4 Jun 2004 16:35:53 -0700
X-Message-Number: 140
>More OPENTRACK propaganda. Open track doesnt do any of those:
>1) It is not readable by Kenwoods
Didn't say it was. But IF you did implement it...
>2) It doesnt clutter, because they cannot even see it!
Additional data doesn't go in the comment field, or any other place with a
pre-defined meaning.
>3) Opentrack introduces an entire protocol! what do you mean it
> doesnt introduce new parsing rules!
I'm saying you can add all the additional data elements you want, without
having to add a rule to parse curly braces here, square brackets there, /A=
someplace else, and so on. You've got one rule to follow and that's it.
>4) APRS allows extensions just just fine
And they're severely limited for the reasons I've already given.
..
>Yes, Ill answer your challenge, but you post your
>OPENTRACKpacket first. Im not even gonna waste
>my time until I see whether its worth it...
No problem. I've got all of those pieces available in various combinations
in assorted demo packets. I'll put one together shortly with all of them.
>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.
>second one you say that of course it wont work unless
>Kenwood recalls all their radios and changes them to
>match your new and better protocol.
I have no intention of doing anything with any Kenwoods. I'm making a point
about the lack of extensibility in APRS, despite what's in the spec. You're
not going to ask them to recall all those radios either, are you?
>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. I just wish you were
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.
Scott
N1VG
----------------------------------------------------------------------
Subject: RE: How about making OpenTrak part of APRS SPEC?
From: "DG2JW" <dg2jw@privateasylum.com>
Date: Sat, 5 Jun 2004 02:54:34 +0300
X-Message-Number: 141
try to consider these three words gentlemen.
Julian
oh8gej
One entry found for innovation.
Main Entry: in=B7no=B7va=B7tion
Pronunciation: "i-n&-'vA-sh&n
Function: noun
1 : the introduction of something new
2 : a new idea, method, or device : Novelty
- in=B7no=B7va=B7tion=B7al /-shn&l, -sh&-n&l/ adjective
Main Entry: ad=B7ap=B7ta=B7tion
Pronunciation: "a-"dap-'tA-sh&n, -d&p-
Function: noun
1 : the act or process of adapting : the state of being adapted
2 : adjustment to environmental conditions: as a : adjustment of a sense
organ to the intensity or quality of stimulation b : modification of an
organism or its parts that makes it more fit for existence under the
conditions of its environment
3 : something that is adapted; specifically : a composition rewritten
into a new form
- ad=B7ap=B7ta=B7tion=B7al /-shn&l, -sh&-n&l/ adjective
- ad=B7ap=B7ta=B7tion=B7al=B7ly adverb
Main Entry: 1com=B7pro=B7mise
Pronunciation: 'k=E4m-pr&-"mIz
Function: noun
Etymology: Middle English, mutual promise to abide by an arbiter's
decision, from Middle French compromis, from Latin compromissum, from
neuter of compromissus, past participle of compromittere to promise
mutually, from com- + promittere to promise -- more at promise
1 a : settlement of differences by arbitration or by consent reached by
mutual concessions b : something intermediate between or blending
qualities of two different things
2 : a concession to something derogatory or prejudicial <a compromise of
principles>
----------------------------------------------------------------------
Subject: OPENtrack verus APRS format example
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Fri, 04 Jun 2004 20:00:45 -0400
X-Message-Number: 142
>>>"Scott Miller" 6/4/04 4:47:41 PM >>>
>Please, provide me with an example of an APRS
>packet that includes:
-Time/Position/Course/speed/Altitude
- Comment/Display name (in Kanji)/Battery voltage
- Temperature/GPS DOP and # of sats
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"
Please, Lets see your OPENtrack version.
Oh, it doesnt do it in kanji, but if you use an off-the shelf Japanese
Kenwood TH-D7 or D700, it CAN display in KANJI uising the aprs compatible
$PNTS protocol that is supported by all kenwoods and all APRS software that
I know of...
So lets see your OPENtrack version...
Thanks
Bob, WB4APR
----------------------------------------------------------------------
Subject: Re: The new MicroTrak project based on the SMT TinyTrak3!
From: "Andrew Rich" <vk4tec@hotmail.com>
Date: Sat, 5 Jun 2004 10:06:12 +1000
X-Message-Number: 143
Put me down for one
----------------------------------------------------------------------
Subject: Re: Solar tetroon Sky Diamond - signal loss????
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Fri, 04 Jun 2004 20:06:54 -0400
X-Message-Number: 144
>>>Jeff King <jeff@aerodata.net> 6/4/04 4:31:04 PM >>>
>>And why in this gentlemens service called Amateur Radio
>>does someone think he can transmit packets that are
>>NOT compatible with the present use of a national channel,
>>and then insist that all 20,000 existing users have to
>>CHANGE their receivers to ignore him?
>Can you name 3 people that had a problem?
You can do it yourself easily. Just do a scan of the APRS-IS and capture
every digipeater that is running UIDIG code. That will give you a list of
many dozens if you want one.
Or scan for all kenwoods, That should give you about 3 thousand on any
given day... is that enough?
Bob
----------------------------------------------------------------------
Subject: Re: Solar tetroon Sky Diamond 6 aloft right now!
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Fri, 04 Jun 2004 20:15:23 -0400
X-Message-Number: 145
>>>"Scott Miller" <scott@opentrac.org> 4:28:57 PM >>>
>"APRS is a registered trademark of APRS Software... Other
>software engineers desiring to include APRS protocols
>in their software for sale... will require a license from
>the author....
That was 1998. Few authors honored that request so I gave up and teamed
with TAPR to help write the spec so that others COULD implement APRS in a
STANDARD way so that ALL would benefit...
And I even released my SOURCE!
And since you can do just about anything within the APRS protocol, I dont
see why you need to invent your own and insisit on obsoleting everyone on
the air...
Bob
----------------------------------------------------------------------
Subject: Re: Solar tetroon Sky Diamond 6 aloft right now!
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Fri, 04 Jun 2004 20:23:50 -0400
X-Message-Number: 146
>>>Jeff King <jeff@aerodata.net> 6/4/04 4:42:43 PM >>>
>>The specs say nothing about how a PID is supposed to
>>be monitored in a TNC.
>
>Those nasty web links again:
>http://www.tapr.org/tapr/html/Faprswg.html
>Do note the section on page 12 and how it references
>the AX.25 specification. Ain't committing something to
>paper, and signing it, a bear?
Yes, too bad you can't seem to understand it.
READ THE SPEC and read my lips:
>>The specs say nothing about how a PID is supposed to
>>be monitored in a TNC.
>>The specs say nothing about how a PID is supposed to
>>be monitored in a TNC.
>>The specs say nothing about how a PID is supposed to
>>be monitored in a TNC.
>>The specs say nothing about how a PID is supposed to
>>be monitored in a TNC.
>>The specs say nothing about how a PID is supposed to
>>be monitored in a TNC.
>>The specs say nothing about how a PID is supposed to
>>be monitored in a TNC.
>As well as the ability to have a selective memory.
Nothing selective about it: And I say again:
>>The specs say nothing about how a PID is supposed to
>>be monitored in a TNC.
>>The specs say nothing about how a PID is supposed to
>>be monitored in a TNC.
>>The specs say nothing about how a PID is supposed to
>>be monitored in a TNC.
What is it exactly that you cant seem to understand?
Bob
----------------------------------------------------------------------
Subject: Re: Solar tetroon Sky Diamond 6 aloft right now!
From: Doug Bade <dbade@clecom.com>
Date: Fri, 04 Jun 2004 20:28:34 -0400
X-Message-Number: 147
At 06:21 PM 06/04/2004, Jeff King wrote:
>Quoting Doug Bade <doug@clecom.com>:
>
>Doug, what are the exact problems you encountered? What damage or mis-display
>did you encounter?
None as I was not running a client at the time, maybe my D700, but
I was not mobile.
I have constrained my discussion to subjects relative to impact on
existing infra-structure hardware, I do not intend to get into a
dissertation regarding coulda woulda mighta dida relative to what happened.
I am not critiquing the Balloon flight I am critiquing the entire concept
of the non-APRS overlay..The balloon flight merely brought it all to the
top of the list..
Doug
KB8GVQ
----------------------------------------------------------------------
Subject: OPENtrack arrogance
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Fri, 04 Jun 2004 20:31:40 -0400
X-Message-Number: 148
>>>Jeff King <jeff@aerodata.net> 6/4/04 6:13:43 PM >>>
>>1) No it is not. As Jeff clearly points out, the spec says
>>APRS packets are to be transmitted with the PID of F0.
>
>Excuse me? I was saying it shouldn't cause a problem
>BECAUSE it was compliant with the APRS spec, in that
>APRS demands a PID of F0, where as OpenTrak uses 77.
Sorry, thats about as logical as saying that because all CARS are required
to have wheels, that since your JET FIGHTER doesnt use wheels, that it can
do anything it wants on the public highways...
What arrogance!
Bob
----------------------------------------------------------------------
Read previous mail | Read next mail
| |
