| |
ZL3AI > APRDIG 10.06.04 10:40l 781 Lines 29179 Bytes #999 (0) @ WW
BID : 3420-ZL3AI
Read: GUEST
Subj: TAPR Digest, Jun 04, 4/8
Path: DB0FHN<DB0FOR<DB0SIF<DB0EA<DB0RES<ON0AR<ZL2TZE<ZL3VML
Sent: 040610/0800Z @:ZL3VML.#80.NZL.OC #:25589 [Chch-NZ] FBB7.00i $:3420-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
Subject: Re: Solar tetroon Sky Diamond - signal loss????
From: "Scott Miller" <scott@opentrac.org>
Date: Fri, 4 Jun 2004 10:55:11 -0700
X-Message-Number: 70
I just glanced over the HH2 source code, version 2.7.001d, and it looks like
it's not using KISS. Is this right? I could've sworn I heard that it
worked ONLY with KISS TNCs. Seems odd to be developing new stuff for
converse mode when we've had KISS for so many years, and now at least a few
KISS-only TNCs.
Anyway, if this is the case, it's just a matter of setting the PID filter
option appropriately. This should be done whether you're around OpenTRAC
packets or not - there's always the possibility of stray TCP/IP traffic on
the channel, accidentally QSY'ing to a non-APRS channel, and so on.
Scott
N1VG
----------------------------------------------------------------------
Subject: Re: TNC vs PID
From: Doug Bade <doug@clecom.com>
Date: Fri, 04 Jun 2004 13:59:54 -0400
X-Message-Number: 71
At 12:05 PM 6/4/2004, Scott Miller wrote:
>>So, how does the TNC know which PID to accept and which to reject?
>
>According to the KPC-3+ manual, the PID filter option filters all but 0xF0,
>which should be exactly what we need to avoid problems on those stations not
>running KISS.
So the point of filtering them is toooo..... drop them?????? How
will they get anywhere near the network that way????
I cannot see that this does anything FOR opentrack, but sure would
allow the rest of us not to have to see/hear them..... sounds good to me...
Doug
KB8GVQ
----------------------------------------------------------------------
Subject: OPENtrack incompatibilities
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Fri, 04 Jun 2004 14:01:02 -0400
X-Message-Number: 72
>>>"Scott Miller" <scott@opentrac.org> 6/4/04 11:48:40 AM >>>
>First, as Wes pointed out OPENTRACK is exactly compliant
>with both the APRS spec and the AX.25 spec.
1) No it is not. As Jeff clearly points out, the spec says APRS packets
are to be transmitted with the PID of F0.
>And as an added bonus, OPNTRK is an altnet that should be
>filtered by many stations by default anyway.
2) NO, it is not an APRS ALTNET, because it is not an APRS compatible
packet. See #1.
OPENtrack is not APRS compatible and so it causes unpredictible results
exactly as we have said all along.
>Second, we've established two actual problems caused
>by yesterday's events -both apparently caused by
>non-compliant parsers...
totally bogus propoganda.
OPENtrack is not transmitting the APRS compatible PID.
Thus it is not APRS, BUT it is using characters in the APRS format
positions that APRS parsers attempt to parse. They are COMPLIANT.
>and both should be easy to fix.
When is it fair for a newcommer to spew incompatible packets onto an
existing net and then say that everyone else has to fix all the problems he
is causing?
>These are very MINOR issues, not worthy of the massive
>debate that's been going on here for the last 24 hours.
>The two can coexist with very little difficulty.
Minor to you, beause you are the one causing all the problems and insisting
that everyone else must change to your new protocol.
We have a vested interst in seeing that the APRS network is not brought to
its knees everytime a new hacker wants to introduce new incompatible
packets. APRS allows for experimental packets as we have been tellling you
for months.
I dont see anything in OPENtrack that can not be done within the existing
APRS protocol. Why all this bother?
Bob
----------------------------------------------------------------------
Subject: Re: Solar tetroon Sky Diamond - signal loss????
From: "Scott Miller" <scott@opentrac.org>
Date: Fri, 4 Jun 2004 11:03:06 -0700
X-Message-Number: 73
>killer packet (what I call it), need to be handled by the software.
>Period. I've handled quite a few of them, spending a great deal of
>time capturing them and then finding out which part of the code was
>deficient. Every one that I managed to capture ended up being fixed
Shhh, don't tell them that, Curt! You're going to spoil my master plan!
You know, the one where on a specified date all of the OpenTrackers out
there send packets to exploit buffer overflows in poorly-written APRS
parsers, and cause them to download patches that automatically convert them
to OpenTRAC operation! And after that, world domination! Muhahahahahah!
Hopefully the evil volcanic island lair will be done by then, but these
environmental impact reports are a bitch.
Maybe I'll just go with a timeshare condo on Hawaii. I hear they're pretty
evil.
----------------------------------------------------------------------
Subject: Re: Solar tetroon Sky Diamond - signal loss????
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Fri, 04 Jun 2004 14:06:38 -0400
X-Message-Number: 74
Sorry Jason,
I think I was agreeing with you. There have been so many messages, I dont
enven know what you are referring to, but I have nothing but respect for
Hamhud and all the other experiments going on on the APRS channel that
respect others and do it within the experimental protocol included in the
spec...
Bob
----------------------------------------------------------------------
Subject: Re: Solar tetroon Sky Diamond 6 aloft right now!
From: "Curt, WE7U" <archer@eskimo.com>
Date: Fri, 4 Jun 2004 11:08:55 -0700 (PDT)
X-Message-Number: 75
On Fri, 4 Jun 2004, Doug Bade wrote:
> That is not totally true.... The trashed packets into the APRS-IS
>stream came from somewhere, are you trying to say all the digi's and I
>gates worked correctly??? I doubt it.... there are many non-KPC3+ digi's
>and I-Gates out in the network. Are they all supposed to change to kpc3+ or
>Kiss mode with computers just to comply with your packets???
How about, if they continue to run in converse mode, that they set
their TNC parameters properly? Would that be such and evil thing?
Here's what I came up with from google searches and talking to my
local AEA expert:
Kantronics: PID OFF
Paccomm: PIDCHECK or perhaps MNOAX25 if it's very old
TAPR2: MNOAX25
AEA: MPROTO OFF
Kenwood: ??
I'm making these changes to the Xastir startup files. I would appreciate
it if someone with real manuals could come up with the proper settings for
PIDCHECK and MNOAX25 to make the TNC only show 0xf0 packets. I haven't
been able to determine that yet from my searches.
--
Curt, WE7U http://www.eskimo.com/~archer
"Lotto: A tax on people who are bad at math." -- unknown
"Windows: Microsoft's tax on computer illiterates." -- WE7U
"The world DOES revolve around me: I picked the coordinate system!"
----------------------------------------------------------------------
Subject: Re: Solar tetroon Sky Diamond 6 aloft right now!
From: Robbie - WA9INF <mwrobertson@comcast.net>
Date: Fri, 04 Jun 2004 13:08:13 -0500
X-Message-Number: 76
I cannot find any similar control command in the MFJs that I have. Could
it be under a different command?
Robbie
----------------------------------------------------------------------
Subject: Re: Solar tetroon Sky Diamond 6 aloft right now!
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Fri, 04 Jun 2004 14:14:26 -0400
X-Message-Number: 77
>>>Jeff King <jeff@aerodata.net> 6/4/04 12:41:40 PM >>>
>>Sure, you can dictate that no one will use any TNC except
>>the JEFF and SCOTT approved models, but that is not
>>HAM radio. You have to make systems work with what
>>hams have on hand if you want to make maximum use
>>of volunteers tallents at special events etc,...
>I guess I just expected them to follow the published specs.
The specs say nothing about how a PID is supposed to be monitored in a TNC.
>Silly me
Yep, Sometimes common sense is more important.
Bob
----------------------------------------------------------------------
Subject: Re: Solar tetroon Sky Diamond 6 aloft right now!
From: "Scott Miller" <scott@opentrac.org>
Date: Fri, 4 Jun 2004 11:21:19 -0700
X-Message-Number: 78
> That is not totally true.... The trashed packets into the APRS-IS
>stream came from somewhere, are you trying to say all the digi's and I
>gates worked correctly??? I doubt it.... there are many non-KPC3+ digi's
>and I-Gates out in the network. Are they all supposed to change to kpc3+ or
>Kiss mode with computers just to comply with your packets???
As I said, the digipeaters worked fine. The problem is IGates with TNCs in
converse mode without PID filtering set. It takes a single command to fix.
APRS packets, by definition, use PID 0xF0. TNCs not filtering on PID in
converse mode are accepting non-APRS packets, and the clients and IGates
connected to them need to be prepared to handle non-APRS packets.
Again, it's not just an OpenTRAC thing. Any non-APRS traffic is going to
cause problems. Weird stuff shows up on 144.39 from time to time, and not
everyone runs APRS solely on 144.39.
Scott
N1VG
----------------------------------------------------------------------
Subject: Re: OPENtrack incompatibilities
From: "Scott Miller" <scott@opentrac.org>
Date: Fri, 4 Jun 2004 11:16:26 -0700
X-Message-Number: 79
>OPENtrack is not APRS compatible and so it causes
>unpredictible results exactly as we have said all along.
Maybe I should clarify. By compatible, I mean non-interfering as defined by
the spec, not interoperable. You said yourself the spec requires APRS
packets to be transmitted with PID 0xF0. If clients choose to receive
non-APRS packets - no one has presented a TNC yet that doesn't have a PID
filtering option - then they should be prepared to handle those non-APRS
packets gracefully.
>Thus it is not APRS, BUT it is using characters in the
>APRS format positions that APRS parsers attempt to
>parse. They are COMPLIANT.
Did you read my messages about this? It CANNOT generate a valid APRS
message. If your base91 processor just says 'x - 33' to get the encoded
value of x, without first checking to see that x is a valid base91
character, you're asking for trouble. Where in the APRS spec are these
non-printable characters permitted?
>Minor to you, beause you are the one causing all the
>problems and insisting that everyone else must change
>to your new protocol.
I am NOT asking ANYONE to change ANY protocol! I have taken pains to follow
the AX.25 specification, and to avoid conflicts with the APRS specification.
I am, however, more than happy to help those with incorrectly configured
systems rectify the problem. No one has come forward with a TNC yet that
can't be properly configured.
Scott
N1VG
----------------------------------------------------------------------
Subject: Re: Solar tetroon Sky Diamond 6 aloft right now!
From: "Scott Miller" <scott@opentrac.org>
Date: Fri, 4 Jun 2004 11:23:42 -0700
X-Message-Number: 80
>Ill make a deal with you. You can transmit OPEN track
>on the APRS channel **WHEN** you have accomplished
>your objective of getting everyone to replace all of their TNC's.
You mean after they already did that once for Mic-E support?
What, they didn't? And APRS hasn't collapsed yet?
Scott
N1VG
----------------------------------------------------------------------
Subject: Re: Solar tetroon Sky Diamond 6 aloft right now!
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Fri, 04 Jun 2004 14:29:03 -0400
X-Message-Number: 81
>>>Jeff King <jeff@aerodata.net> 6/4/04 12:45:20 PM >>>
>>But [PID's are not usable as disciriminants on APRS]
>>as was just clearly demonstrated and has been KNOWN
>
>But what was clearly demostrated? So far, as of this
>reading, two individials have reported a problem,
>Facts Bob, not wives tales.
Fact is, it is incompatible.
Anyone with an ounce of communications savy would not intentionally
introduce incompatible protocols on an existing protocol driven network.
Why force incompatibilities on the national APRS channel when APRS already
allows for any kind of experimental protocol you want and it only takes 2
bytes.
Bob
----------------------------------------------------------------------
Subject: RE: How about making OpenTrak part of APRS SPEC?
From: Steve Dimse <k4hg@tapr.org>
Date: Fri, 4 Jun 2004 14:35:03 -0400
X-Message-Number: 82
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.
The fact is opentrack could have used this to accomplish their "new and
improved" protocol and remain a part of APRS. They chose instead to develop
their own from scratch, now they want to come onto the APRS network and
force people to make accomodation for them.
If they wanted to be part of APRS, they shouldn't have ignored the options
built into the protocol to accomodate them!
Steve K4HG
----------------------------------------------------------------------
Subject: RE: How about making OpenTrak part of APRS SPEC?
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Fri, 04 Jun 2004 14:37:55 -0400
X-Message-Number: 83
>>>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? I see all kinds of APRS activity, growth and new products. AND
the reason you see that GROWTH and new products is because people know that
the spec is SOUND and will not be obsoleted by each newbee programmer that
comes along... Thus, it is worth their time to build something to it...
>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.
Bob
----------------------------------------------------------------------
Subject: Re: Solar tetroon Sky Diamond - signal loss????
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Fri, 04 Jun 2004 14:45:43 -0400
X-Message-Number: 84
>>>"Scott Miller" <scott@opentrac.org> 6/4/04 1:21:45 PM >>>
>The question is, which packets were causing it?
>OpenTRAC packets use PID 0x77 and should be
>ignored by APRS devices.
Where do you get that idea. Eveyone with any experience with the plethora
of TNC's out there knows that is not true and we told you that. So your
continuing mantra that they "should" ignore the incompatible OPENTrack
packets is just a dream...
>And it's not just an OpenTRAC thing, it's an AX.25
>compatibility issue.
Yes, and we all know that and that is why we recommended that you not
introduce incompatible PID-isolated packets on the APRS network. Existing
TNC's (beyond our control) have problems with it...
>If you're not looking at the PID and accidentally QSY
>to a non-APRS packet channel, you're going to
>have problems.
Which is exactly why we suggested that you not do it on APRS!
Bob
----------------------------------------------------------------------
Subject: Re: Solar tetroon Sky Diamond 6 aloft right now!
From: Doug Bade <doug@clecom.com>
Date: Fri, 04 Jun 2004 14:50:09 -0400
X-Message-Number: 85
>As I said, the digipeaters worked fine. The problem is IGates with TNCs in
>converse mode without PID filtering set. It takes a single command to fix.
So if the I-gates filter out the packet, how is it going to get
into the APRS-IS stream???? Again, this seems to be anti-open track by
definition, and you are promoting this idea??? Unless you are only talking
about clients which is another matter......which makes far more sense from
your standpoint....
What it really looks like is you folks would just as soon the APRS network
operators allow the packets on the APRS-IS for your use, but just tell us
APRS users to block it and ignore it..so it doesn't trash the APRS users...
sounds kind of like hijacking to me...Provide transport at our expense.....
hmmmmm.
I do not know of any other users being intentionally permitted to use the
infra-structure who's data is effectively encrypted in a fashion we can not
see or use with existing HW and SW???? WE need to change to accommodate
you?????
Sounds like a one sided cooperation to me.....
Doug
KB8GVQ
----------------------------------------------------------------------
Subject: Re: OPENtrack incompatibilities
From: Doug Bade <doug@clecom.com>
Date: Fri, 04 Jun 2004 14:56:48 -0400
X-Message-Number: 86
At 02:16 PM 6/4/2004, Scott Miller wrote:
>I am NOT asking ANYONE to change ANY protocol! I have taken pains to follow
>the AX.25 specification, and to avoid conflicts with the APRS specification.
>I am, however, more than happy to help those with incorrectly configured
>systems rectify the problem. No one has come forward with a TNC yet that
>can't be properly configured.
>Scott
Sorry but UIDIGI is UI frames only... from the instructions... I quote....
"Repeats only AX.25 UI frames (APRS uses UI frames) "
so much for that theory......
Doug
KB8GVQ
----------------------------------------------------------------------
Subject: Re: OPENtrack incompatibilities
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Fri, 04 Jun 2004 14:56:08 -0400
X-Message-Number: 87
>>>"Scott Miller" <scott@opentrac.org> 6/4/04 1:47:52 PM >>>
>>Why does a balloon need centimeter accuracy, especially when
>>aGPS can hardly do 10 meters altitude accuracy? I still don't
>
>It doesn't. Why do it that way? Because 16 bits wasn't
>enough. 24 might be too much, but it's better to align the
>value on a byte boundary than to require more elaborate parsing.
Sounds like code just for the sake of code...
What is wrong with the bits that APRS alerady provides? In April, and in
response to the request for better accuracy, APRS introduced the !DAO!
construct that gives precision to one foot or so and REMAINS backwards
compatible with all existing systems, including even the Kenwoods!
>And someone might actually be able to make use of
>[OPENtrack] at some point. If Burt Rutan wants to connect
>a tracker to SpaceShipOne's inertial navigation system,
>we're set. =]
But then why incumber the other 20,000 of us for that virtually impossible
scenario?
>Especially when the APRS protocol allows for any kind of
>special format that anyone wants to introduce.
>I'll try to put together a presentation on what we're trying
>to accomplish and why it's not worth trying to shoehorn
>into the APRS protocol.
If it is not worth the two bytes to shoehorn it into the APRS extensible
protocol, then I suggest it is not worth shoehoring onto the National APRS
network and forcing everyone else to adapt...
Bob
----------------------------------------------------------------------
Subject: Re: OPENtrack incompatibilities
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Fri, 04 Jun 2004 15:28:00 -0400
X-Message-Number: 88
>>>"Scott Miller" <scott@opentrac.org> 6/4/04 2:16:26 PM >>>
>>OPENtrack is not APRS compatible and so it causes
>>unpredictible results exactly as we have said all along.
>
>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...
>You said yourself the spec requires APRS packets to
>be transmitted with PID 0xF0. If clients choose to receive
>non-APRS packets... then they should be prepared to
>handle those non-APRS packets gracefully.
Why should they be prepared to handle NON-APRS packets on the univerasal
APRS channel?
>Did you read my messages about this? OPENtrack
>CANNOT generate a valid APRS message. If your
>base91 processor just says 'x - 33' to get the encoded
>value of x, without first checking to see that x is a valid
>base91 character, you're asking for trouble.
No, its not the base-91 problem, its that your incompatible APRSformat byte
is flagging "the following X bytes to be base-91" when in fact they are
NOT,
>Minor to you, beause you are the one causing all the
>problems and insisting that everyone else must change
>to your new protocol.
>I am NOT asking ANYONE to change ANY protocol!
>I have taken pains to follow the AX.25 specification,
>and to avoid conflicts with the APRS specification.
Ah, but you have not taken the advice of those that have been down these
roads before and who keep telling you that just following the written spec
and ignoring common knowledge about the incompatibilities that exist in the
dozens of diffrente manufacturers TNC's will get you into trouble.
>I am, however, more than happy to help those with
>incorrectly configured systems rectify the problem.
Yes, make it compatible with APRS... or move it off of the national APRS
frequency,
Thank you very much.
Bob
----------------------------------------------------------------------
Subject: Re: OPENtrack incompatibilities
From: Doug Bade <doug@clecom.com>
Date: Fri, 04 Jun 2004 15:33:57 -0400
X-Message-Number: 89
In UIdigi, It looks like the settings to block non UI frames can be
disabled, but will basically stop all APRS related error checking... and
also I do not beleive this a very well documented and currently supported
mode, which is kind of contrary to UI digipeating anyhow....It will take
some time and effort in testing changes to see if it is possible..or even a
good idea for that matter... It may break something else.
In any case the default of all UI digi's is only UI frames... so that is
how the most likely all are configured as of today...
Just adding this information before someone else needs to...
Doug KB8GVQ
----------------------------------------------------------------------
Subject: Re: Solar tetroon Sky Diamond - signal loss????
From: "Jason Rausch" <ke4nyv@hamhud.net>
Date: Fri, 4 Jun 2004 14:34:12
X-Message-Number: 90
Scott said:
>Ijust glanced over the HH2 source code, version 2.7.001d, and it looks like
>it's not using KISS. Is this right? I could've sworn I heard that it
>worked ONLY with KISS TNCs.
Exact opposite. The orginal code only worked with a Kantronics KPC-3. I
wish it was KISS based because long ago I would have replaced my KPC-3 with
Hansen's TNC-X or somthing similar. Back when my KPC-3 was the ONLY TNC I
owned it was dedicating it to the HUD. Now that I have about 8 TNC's
laying around including a second KPC-3, its not as bad. But I still want
to see the day when I can replace it with a KISS modem and put it INSIDE
the case with the HH2 it'self.
One goal was achieved by Dale on the last revision, which was also a port
of the code from a PIC16F876 to a PIC18F252, was to make the code universal
with just about nay TNC-2 clone TNC. He currently is using a MFJ himself
for testing. I made a quick attempt to use one of my MFJ's but it failed.
I'm sure I had a parameter set wrong and a little more time would prove it
works.
My ultimate goal is to put the HH2, TNC and and one of my Motorola Oncores
all in one box. I'll have to keep the radio seperate since I'm dead set on
my Motorola VHF Maxtrac, we Moto techs are just like that :o)
>Seems odd to be developing new stuff for
>converse mode when we've had KISS for so many years, and now at least a few
>KISS-only TNCs.
Steve's explanation of that is, he had a KPC-3 at the time he started the
project and just decided to write the code to that, that simple.
Hope that clears some things up.
Jason KE4NYV
www.ke4nyv.com
RPC Electronics
www.ke4nyv.com/rpc
----------------------------------------------------------------------
Subject: Re: Solar tetroon Sky Diamond 6 aloft right now!
From: "Curt, WE7U" <archer@eskimo.com>
Date: Fri, 4 Jun 2004 12:38:48 -0700 (PDT)
X-Message-Number: 91
Current list for TNC PID filtering:
Kantronics: "PID OFF"
Paccomm: "PIDCHECK ??" or perhaps "MNOAX25 OFF" if it's very old
TAPR2: "MNOAX25 OFF"
AEA: "MPROTO OFF"
Kenwood: ??
Alinco: ??
Any PID checking on the Kenwoods or Alinco's?
Anyone with a Paccomm manual that can feed me a real description for the
PIDCHECK command that makes sense?
I'd like to get the Xastir converse-mode startup files set up properly for
all of these (and more if you have them).
They're not needed for KISS mode, AGWPE mode, or AX.25 kernel networking
mode. In those cases, Xastir will decode and show _both_ APRS and OpenTrac
stations on the map.
--
Curt, WE7U http://www.eskimo.com/~archer
"Lotto: A tax on people who are bad at math." -- unknown
"Windows: Microsoft's tax on computer illiterates." -- WE7U
"The world DOES revolve around me: I picked the coordinate system!"
----------------------------------------------------------------------
Subject: Re: TNC vs PID
From: "Scott Miller" <scott@opentrac.org>
Date: Fri, 4 Jun 2004 12:46:33 -0700
X-Message-Number: 92
>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.
Scott
N1VG
----------------------------------------------------------------------
Subject: Re: 30 Meter Policing needed.
From: "Scott Weis" <kb2ear@kb2ear.net>
Date: Fri, 4 Jun 2004 16:03:27 -0400
X-Message-Number: 93
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
----------------------------------------------------------------------
Subject: Re: OPENtrack incompatibilities
From: "Scott Miller" <scott@opentrac.org>
Date: Fri, 4 Jun 2004 13:03:05 -0700
X-Message-Number: 94
>But then why incumber the other 20,000 of us for that
>virtually impossible scenario?
Good protocol design doesn't encumber anyone. I've presented my reasons for
designing a new protocol. You don't have to agree or condone the project,
it doesn't matter to me in the least. Notice that I'm not saying APRS
should offer 24 bit resolution for altitude. You asked why it was done that
way, and I explained.
>If it is not worth the two bytes to shoehorn it into the APRS
>extensible protocol, then I suggest it is not worth shoehoring
>onto the National APRS network and forcing everyone else
>to adapt...
It's not all about the simple protocol vocabulary. As I've said repeatedly,
the protocol is intended to support features like store-and-forward
operation, backbone routing, digipeater-maintained objects, and so on.
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.
Scott
N1VG
----------------------------------------------------------------------
Subject: Re: OPENtrack incompatibilities
From: "Scott Miller" <scott@opentrac.org>
Date: Fri, 4 Jun 2004 13:17:59 -0700
X-Message-Number: 95
>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. What difference does it
make to anyone whether that packet is APRS or OpenTRAC? Other than the fact
that the OpenTRAC packet is only going to take 60% of the bandwidth, that
is. How is that not a legitimate use of the channel and network?
>Why should they be prepared to handle 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.
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? Even if you
only used it on SSB portions of the band?
>No, its not the base-91 problem, its that your incompatible
>APRSformat byte is flagging "the following X bytes to be
>base-91" when in fact they are NOT,
1. The packet was already explicitly flagged as non-APRS.
2. An APRS packet needs a lot more than a single matching byte to be
properly considered a valid packet.
>Ah, but you have not taken the advice of those that have
>been down these roads before and who keep telling you
>that just following the written spec and ignoring common
>knowledge about the incompatibilities that exist in the
>dozens of diffrente manufacturers TNC's will get you into
>trouble.
So tell me again why Mic-E was considered a good idea? Widespread TNC
incompatibilities didn't slow you down then.
Scott
N1VG
----------------------------------------------------------------------
Read previous mail | Read next mail
| |
