| |
ZL3AI > APRDIG 10.06.04 10:47l 830 Lines 29270 Bytes #999 (0) @ WW
BID : 3421-ZL3AI
Read: GUEST
Subj: TAPR Digest, Jun 04, 5/8
Path: DB0FHN<DB0FOR<DB0SIF<DB0EA<DB0ACC<DB0GOS<ON0AR<ON0AR<ZL2TZE<ZL3VML
Sent: 040610/0801Z @:ZL3VML.#80.NZL.OC #:25590 [Chch-NZ] FBB7.00i $:3421-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
Subject: RE: the group...
From: "Julian White" <dg2jw@privateasylum.com>
Date: Fri, 4 Jun 2004 22:18:05 +0200
X-Message-Number: 96
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: Re: [ Jeff King ] Re: Solar tetroon Sky Diamond 6 aloft right now!
From: Jeff King <jeff@aerodata.net>
Date: Fri, 04 Jun 2004 15:19:45 -0500 (CDT)
X-Message-Number: 97
Quoting "Gregg G. Wonderly" <gregg@skymaster.cytetech.com>:
To
>>the 300,000 other square miles, they activate each and every single wide, for
>>no benefit at all. 200,000+ additional transmissions cluttering the channel
>>for the duration of the mission. (~400 wides in coverage area, *60 times a
>>hour, * 10 hours. Remember, no dupes at all on the first reception, that
>>doesn't even include the second hop.
>The only think that I would add is that the air mobile is not using CSMA
>to control its transmission.
Exactly, that is why one of the tenents of Air Mobile should be to use the
minimum power required. At 250 miles away, I was getting perfect copy on the
500mw signal of the Solar tetroon.
>So, the use of a single 'Wide' will help to make
>sure that after the packet enters a CSMA network, that it is heard by
>all such participating stations who may have been transmitting or receiving a
>stronger transmission during the air mobiles original transmission.
As soon as the packet was sent, it "entered" the CSMA network. So whoever
heard it, already heard it. But your missing the most important point. That
is, you have to define the mission, and then define the minimum impact to
achive that mission. Clearly, having 400 digipeaters send out a duplicate
packet is not low impact! Hence, if your mission is simply to enter the
APRS-IS, this is a huge waste of resources.
----------------------------------------------------------------------
Subject: Re: OPENtrack incompatibilities
From: "Scott Miller" <scott@opentrac.org>
Date: Fri, 4 Jun 2004 13:20:14 -0700
X-Message-Number: 98
>Sorry but UIDIGI is UI frames only... from the instructions... Iquote....
>"Repeats only AX.25 UI frames (APRS uses UI frames) "
>
>so much for that theory......
I don't think I see the problem. OpenTRAC uses UI frames as well. Have you
read the AX.25 spec?
Scott
N1VG
----------------------------------------------------------------------
Subject: Re: [ Robert Bruninga ] RE: How about making OpenTrak part of APRS
SPEC?From: "Gregg G. Wonderly" <gregg@skymaster.cytetech.com>
Date: Fri, 04 Jun 2004 15:26:23 -0500
X-Message-Number: 99
>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...
Or the existing equipment and software doesn't fill their needs, as Scott has
found and designed a new protocol for his needs. True, he could the user
defined packet extensions. But, I am convinced that as soon as he was
transmitting with PID=0xf0 and sending a user defined packet that we'd have
systems crashing, thrashing and locking up because that is also largely
unchartered waters.
-----
gregg@cytetech.com (Cyte Technologies Inc)
----------------------------------------------------------------------
Subject: Re: Solar tetroon Sky Diamond 6 aloft right now!
From: "Curt, WE7U" <archer@eskimo.com>
Date: Fri, 4 Jun 2004 13:27:26 -0700 (PDT)
X-Message-Number: 100
On Fri, 4 Jun 2004, Curt, WE7U wrote:
>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: ??
There's been some discussion about the MNOAX25 command. It appear to me
from reading the description that it filters based on PID's, but it doesn't
specifically say that. They say that if ON, you'll see NET/ROM and TCP/IP
traffic. If off, you won't. That would tend to make me thing it's
filtering on PID.
Anyone know anything more about that one?
--
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: Jeff King <jeff@aerodata.net>
Date: Fri, 04 Jun 2004 15:23:05 -0500 (CDT)
X-Message-Number: 101
Quoting Robert Bruninga <bruninga@usna.edu>:
>>>>Jeff King <jeff@aerodata.net> 6/3/04 11:56:56 PM >>>
>>>Instead, the creators of opentrack chose a mechanism that is
>>>incompatible with APRS...
>>
>>And why do you think this is? I think it is because
>>the APRS-WG charter is not being followed, which
>>DOES allow extensions to APRS, yet it is not happening.
>
>Untruths, and hogwash...
http://www.tapr.org/tapr/html/Faprswg.html
Then ask TAPR then to remove these from their site, as everything I say is
backed up in both the charter and the spec.
----------------------------------------------------------------------
Subject: Re: Solar tetroon Sky Diamond 6 aloft right now!
From: Dale Blanchard <wa7ixk@arrl.net>
Date: Fri, 04 Jun 2004 14:25:23 -0700
X-Message-Number: 102
Curt, WE7U wrote:
>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?
>
>In my Pico manual PIDCHECK ON|OFF or Yes|No Default :OFF
> ON -All frames with a PID other thsn $F0 are ignored.
>
OFF -All frames are accepted
equally.
Dale
WA7ixk
----------------------------------------------------------------------
Subject: Re: Solar tetroon Sky Diamond 6 aloft right now!
From: Jeff King <jeff@aerodata.net>
Date: Fri, 04 Jun 2004 15:42:43 -0500 (CDT)
X-Message-Number: 103
Quoting Robert Bruninga <bruninga@usna.edu>:
>>>>Jeff King <jeff@aerodata.net> 6/4/04 12:41:40 PM >>>
>>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.
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?
>>Silly me
>
>Yep, Sometimes common sense is more important.
As well as the ability to have a selective memory.
----------------------------------------------------------------------
Subject: Re: Solar tetroon Sky Diamond - signal loss????
From: Jeff King <jeff@aerodata.net>
Date: Fri, 04 Jun 2004 15:31:04 -0500 (CDT)
X-Message-Number: 104
He is on a roll again I see....
Quoting Robert Bruninga <bruninga@usna.edu>:
>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? Can you clearly and succiently
describe the damage that was done?
Yeap, I thought so.....
----------------------------------------------------------------------
Subject: Re: Solar tetroon Sky Diamond 6 aloft right now!
From: "Scott Miller" <scott@opentrac.org>
Date: Fri, 4 Jun 2004 13:28:57 -0700
X-Message-Number: 105
> 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
It should NEVER be on the APRS-IS stream. It's not compatible, never will
be. No one's proposing that.
>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.
Not at all. The digipeater network is the only resource being used.
>infra-structure who's data is effectively encrypted in a fashion we can not
Encrypted? What, like TCP/IP? Being in a binary format doesn't make it
encrypted. It's not even obfuscated. The spec is freely available, example
code is out there, I've written a Windows decoder library, and unlike APRS,
OpenTRAC has always been an open project, unencumbered by claims to
intellectual property or demands for licensing. In case anyone's forgotten:
Bob Bruninga, 1998:
"APRS is a registered trademark of APRS Software and Bob Bruninga. Other
software engineers desiring to include APRS protocols in their software for
sale within or outside of the amateur community will require a license from
the author. Licensing is not intended to be restrictive, but to provide a
means for the maintaining a consistent on-air protocol and for the owner of
APRS to share in any proceeds made from APRS applications. "
>see or use with existing HW and SW???? WE need to change to accommodate
>you?????
Nope. Just follow good engineering and amateur operating practices.
Scott
N1VG
----------------------------------------------------------------------
Subject: Re: TNC vs PID
From: Steve Dimse <k4hg@tapr.org>
Date: Fri, 4 Jun 2004 16:46:37 -0400
X-Message-Number: 106
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!
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.
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, blaming them for not using
the right mode in the right TNC with the right software, and not caring
about any interference you might cause.
Pretty selfish attitude, if you ask me!
Steve K4HG
----------------------------------------------------------------------
Subject: RE: How about making OpenTrak part of APRS SPEC?
From: "Scott Miller" <scott@opentrac.org>
Date: Fri, 4 Jun 2004 13:47:41 -0700
X-Message-Number: 107
>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...
Please, provide me with an example of an APRS packet that includes:
- Timestamp
- Position
- Course and speed
- Altitude
- Comment
- Display name (in Kanji)
- Battery voltage
- Temperature
- GPS DOP and # of sats
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
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, you'd
still be able to extend your packets without fear of breaking anything. In
APRS, you have the option of using a user-defined format that they won't
parse at all, or cramming more data into the comment field of one of the
formats they do support.
And for the record, this newbie programmer is well into his second decade of
'real' programming - not counting several years of playing with assembly
language and basic before that.
Scott
N1VG
----------------------------------------------------------------------
Subject: Re: OPENtrack incompatibilities
From: "Andrew Rich" <vk4tec@hotmail.com>
Date: Sat, 5 Jun 2004 06:57:26 +1000
X-Message-Number: 108
I see some heated debates happeing.
It is good to discuss and sometimes you have to agree to disagree.
I think it is a good thing to try new things.
Don't get too hung up and emotional over the situation.
Concentrate you energy toward experimenting.
Cheers
----------------------------------------------------------------------
Subject: Re: OPENtrack incompatibilities
From: Doug Bade <doug@clecom.com>
Date: Fri, 04 Jun 2004 17:00:44 -0400
X-Message-Number: 109
At 04:20 PM 6/4/2004, Scott Miller wrote:
>> Sorry but UIDIGI is UI frames only... from the instructions...
>>I quote....
>>"Repeats only AX.25 UI frames (APRS uses UI frames) "
>I don't think I see the problem. OpenTRAC uses UI frames as well. Have you
>read the AX.25 spec?
I could care less about your determination of what the AX.25 spec
says vs what your predecessors have read it to say....The facts are as they
are... UIDigi will have a problem with it..
UIDigi is UI and PID specific. The only way I can see, as it is
written, for the PID of OpenTrac to be repeated by a UIDigi digi would be
to allow ALL PID's which is a hardware change for most UIDigi
operators...as long as OpenTrac uses an alternate PID...
Many if not most installations of UIDigi are hard coded Eprom boot's...
power on defaults to rom data with no battery backup for memory.. which is
the suggested implementation of the user group. Less corruption due to
battery failure over time.
Doug
KB8GVQ
----------------------------------------------------------------------
Subject: PID filtering commands for TNC's
From: "Curt, WE7U" <archer@eskimo.com>
Date: Fri, 4 Jun 2004 14:00:20 -0700 (PDT)
X-Message-Number: 110
Combining two earlier messages and adding latest data:
On Fri, 4 Jun 2004, Curt, WE7U wrote:
>Current list for TNC PID filtering:
>
> Kantronics: "PID OFF"
> Paccomm: "PIDCHECK ON" 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?
>There's been some discussion about the MNOAX25 command. It appear
>to me from reading the description that it filters based on PID's,
>but it doesn't specifically say that. They say that if ON, you'll
>see NET/ROM and TCP/IP traffic. If off, you won't. That would tend
>to make me thing it's filtering on PID.
>
>Anyone know anything more about that one? Can anyone test it?
I've already set up the Xastir tnc-startup files with this new data.
Regular Xastir users can snag that data starting later today, when
the file sync between the two CVS servers hits.
If I find out that Kenwood and/or Alinco have PID filtering
commands, I'll add those as well. Anyone?
--
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: Fw: RE: How about making OpenTrak part of APRS SPEC?
From: "Andrew Rich" <vk4tec@hotmail.com>
Date: Sat, 5 Jun 2004 07:03:30 +1000
X-Message-Number: 111
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 ?
----------------------------------------------------------------------
Subject: RE: How about making OpenTrak part of APRS SPEC?
From: "Scott Miller" <scott@opentrac.org>
Date: Fri, 4 Jun 2004 14:07:18 -0700
X-Message-Number: 112
>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.
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.
Take the issue of static objects - mostly houses - everywhere. APRS gospel
says that they should transmit with a decaying rate algorithm, doing their
best to avoid collisions. 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. As
long as the digi is responsible for it, you've already eliminated half the
channel time needed to maintain it - no need for the station to resend to
have it digipeated. Plus, the digi is far less susceptible to hidden
transmitter collisions, and can aggregate multiple static objects and
transmit them in a single periodic burst that saves even more channel time.
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. That's why OpenTRAC is designed the way
it is. 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 transmit the object as usual, and guess
what? If the receiving stations don't understand or can't support that
request, it's ignored. It doesn't clutter up someone's message window, and
it doesn't break anyone's parser. The rest of the content is parsed and
displayed as usual. If, on the other hand, a digi does pick it up, it can
repeat it and say 'I will announce this object for the next 10 hours at 10
minute intervals.' Again, the confirmation doesn't break anything.
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.
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.
Scott
N1VG
----------------------------------------------------------------------
Subject: AX.25 / UI digi
From: Mark Earle <wa2mct@mearle.com>
Date: Fri, 04 Jun 2004 16:30:05 -0500
X-Message-Number: 113
People have been amazed that I can test a UI digi with a terminal program.
Of course a digi will repeat any UI (unconnected) packet.
My quick-test set up is a Zeos Palm PC (dos), VX-1 HT, and a baycom modem
on the serial port. Or, a Tiny-2 TNC, or, a Pico Packet.
No need to wait for a posit or whatever.
Typical tnc-2 speak:
cmd:
un test v digi1 (use the callsign)
cmd:
k
dfdfdf
Should see dfdfdf returned after being digipeated, if
mon on
mall on
Of course one can do
un test vi digi1,digi2,digi1 etc to test further than the digi in the
cabinet you're leaning on.
The point is, UI code in a TNC-2 clone does not discriminate a particualar
to call, etc. If it is an unconnected packet, it gets digi'd.
) ) de WA2MCT Mark
( (
) ) You will be assimilated... oooh, coffee!!
_|****| http://www.findu.com/cgi-bin/find.cgi?wa2mct-8 Home
( | | http://www.findu.com/cgi-bin/find.cgi?wa2mct-9 Mobile
`|____| wa2mct@mearle.com wa2mct@juno.com www.mearle.com/mark
----------------------------------------------------------------------
Subject: Re: TNC vs PID
From: "Scott Miller" <scott@opentrac.org>
Date: Fri, 4 Jun 2004 14:43:10 -0700
X-Message-Number: 114
>It is just as incompatible with RF APRS clients, unless they implement the
>changes you mandate!
So far I've seen no reports of client problems caused by the widespread
OpenTRAC traffic yesterday, with the exception of one HH2.
PID filtering should be enabled on any TNC used in converse mode for APRS.
It's not critical, but it's a good idea.
Scott
N1VG
----------------------------------------------------------------------
Subject: Re: [ Jeff King ] Re: [ Jeff King ] Re: Solar tetroon Sky Diamond 6
aloft right now!
From: "Gregg G. Wonderly" <gregg@skymaster.cytetech.com>
Date: Fri, 04 Jun 2004 16:44:38 -0500
X-Message-Number: 115
>As soon as the packet was sent, it "entered" the CSMA network. So whoever
heard
>it, already heard it. But your missing the most important point. That is, you
>have to define the mission, and then define the minimum impact to achive that
>mission. Clearly, having 400 digipeaters send out a duplicate packet is not
low
>impact! Hence, if your mission is simply to enter the APRS-IS, this is a huge
>waste of resources.
Since opentrac is not intended to traverse the APRS-IS, there might be
different requirements for proper propagation to all interested stations.
But, yes I do understand that getting to the APRS-IS at that altitude with
APRS packets would not strictly require any PATH.
-----
gregg@cytetech.com (Cyte Technologies Inc)
----------------------------------------------------------------------
Subject: Re: OPENtrack incompatibilities
From: "Scott Miller" <scott@opentrac.org>
Date: Fri, 4 Jun 2004 15:01:11 -0700
X-Message-Number: 116
> UIDigi is UI and PID specific. The only way I can see, as it is
>written, for the PID of OpenTrac to be repeated by a UIDigi digi would be
>to allow ALL PID's which is a hardware change for most UIDigi
>operators...as long as OpenTrac uses an alternate PID...
That's fine with me. No one's expecting universal coverage, and we're not
expecting anyone to go out of their way to make things work for an
experimental project.
I'm sure if someone's doing regional experimentation and they've only got a
UIDigi locally, they can work things out with the sysop.
Scott
N1VG
----------------------------------------------------------------------
Subject: RE: How about making OpenTrak part of APRS SPEC?
From: Jeff King <jeff@aerodata.net>
Date: Fri, 04 Jun 2004 17:08:13 -0500 (CDT)
X-Message-Number: 117
Quoting AE5PL Lists <HamLists@ametx.com>:
>>>This is not a matter of NIH, but a matter of trying to modify the spec
>>>to incorporate a completely different protocol.
>>
>>Iunderstand that. But how does one do this? That is what the
>>"NIH" was about.
>
>I am saying we don't.
Which is your right. And it is your opinion as well that OpenTrak is completely
different, but is is any more different then MIC-E? Or Base-91 math?
My point, was their has to be a fair mechnism in place to arbitrate changes and
additions to the spec.
----------------------------------------------------------------------
Subject: Re: Sky Diamond 6 landing site prediction
From: Jeff King <jeff@aerodata.net>
Date: Fri, 04 Jun 2004 17:11:05 -0500 (CDT)
X-Message-Number: 118
Quoting Scott Miller <scott@opentrac.org>:
>>Since the GPS likely powered off during descent, the tracker will not be
>>transmitting at all. The radio and Opentracker are likely powered up right
>>now but sitting idle.
>
>Time to start writing a fallback CWID mode, I guess. I think it's
>already on my to-do list.
Well, no, even with a digipeat you can localize the area. CWID you'd have to be
close enough to hear it....
Also, any way you can store the last valid fix? Last I saw it, it was falling
south of Pittsburg.
----------------------------------------------------------------------
Subject: Re: Fw: RE: How about making OpenTrak part of APRS SPEC?
From: "Scott Miller" <scott@opentrac.org>
Date: Fri, 4 Jun 2004 15:12:24 -0700
X-Message-Number: 119
>Why is the SPEC property of BOB ?
>
>Iknow 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 ?
In theory, anyway, that's supposed to be how it works now. The reality
seems to be another matter. I'm on the APRS SPEC mailing list, and I see
about one email every three months.
As far as I know, Bob dropped his licensing requirements long ago. I was
pointing that out for historical context. It's easy to get very posessive
of something you've put a lot of work into. It was a hard decision for me
to release the OpenTracker source code under the BSD license, but I think
it's the best decision, at least for the community as a whole. The OpenTRAC
protocol on the other hand has always been an open project, there for the
benefit of the community. Yeah, the work we put into it might get put into
commercial use, with none of the profit going back to those who did the
work. But standards aren't source code - wide, unencumbered adoption is a
good thing.
If it meant having radios on the market that'd do everything I envision, I
wouldn't mind at all if Kenwood or Icom was making a ton of money off it.
Scott
N1VG
----------------------------------------------------------------------
Subject: Re: TNC vs PID
From: "Curt, WE7U" <archer@eskimo.com>
Date: Fri, 4 Jun 2004 15:13:51 -0700 (PDT)
X-Message-Number: 120
On Fri, 4 Jun 2004, Scott Miller wrote:
>PID filtering should be enabled on any TNC used in converse mode for APRS.
>It's not critical, but it's a good idea.
Agreed, and why I'm adding it to the Xastir TNC startup files.
Another highly important thing to put in there: Remove the ASCII filtering
that a lot of TNC's have by default. That filtering can remove the
non-printable characters that Mic-E protocol users, thereby causing
corruption of the payload.
Here's what I have for those:
tnc-startup.aea:MFILTER 0
tnc-startup.kam:FILT OFF
tnc-startup.kpc3:FILT off
tnc-startup.paccomm:MFILT $00
tnc-startup.pico:MFILTER 0
tnc-startup.sys:Filt off
tnc-startup.sys:MFILT off
--
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: OPENtrack incompatibilities
From: Jeff King <jeff@aerodata.net>
Date: Fri, 04 Jun 2004 17:13:43 -0500 (CDT)
X-Message-Number: 121
Quoting Robert Bruninga <bruninga@usna.edu>:
>>>>"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.
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 0xF0, where as
OpenTrak uses 0x77.
>totally bogus propoganda.
Your such a wonderful person to work with Bob.
----------------------------------------------------------------------
Subject: Re: OPENtrack incompatibilities
From: Jeff King <jeff@aerodata.net>
Date: Fri, 04 Jun 2004 17:17:04 -0500 (CDT)
X-Message-Number: 122
Quoting Scott Miller <scott@opentrac.org>:
>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.
Well, that was the problem Scott. You didn't apply enough smoke, mirrors and
duct tape.
----------------------------------------------------------------------
Subject: Re: Solar tetroon Sky Diamond 6 aloft right now!
From: Jeff King <jeff@aerodata.net>
Date: Fri, 04 Jun 2004 17:21:53 -0500 (CDT)
X-Message-Number: 123
Quoting Doug Bade <doug@clecom.com>:
>What it really looks like is you folks
"You folks"? Hmmmm.....
Doug, what are the exact problems you encountered? What damage or mis-display
did you encounter?
----------------------------------------------------------------------
Subject: Re: Solar tetroon Sky Diamond 6 aloft right now!
From: Jeff King <jeff@aerodata.net>
Date: Fri, 04 Jun 2004 17:20:11 -0500 (CDT)
X-Message-Number: 124
Quoting Robert Bruninga <bruninga@usna.edu>:
>>>>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.
Again, show us your data. The more your weave and jive, the more shallow this
whole exercise becomes.
>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.
The only thing I "want" is for you to show us the data. Your in the Washington
DC area, you heard the balloon well, exactly what problems did you encounter?
----------------------------------------------------------------------
Read previous mail | Read next mail
| |
