| |
ZL3AI > APRDIG 10.06.04 10:53l 743 Lines 29347 Bytes #999 (0) @ WW
BID : 3418-ZL3AI
Read: GUEST
Subj: TAPR Digest, Jun 04, 2/8
Path: DB0FHN<DB0FOR<DB0SIF<DB0EA<DB0RES<ON0AR<ZL2BAU<ZL2BAU<ZL3VML
Sent: 040610/0800Z @:ZL3VML.#80.NZL.OC #:25587 [Chch-NZ] FBB7.00i $:3418-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
Subject: Re: Solar tetroon Sky Diamond 6 aloft right now!
From: Curt Mills <archer@eskimo.com>
Date: Thu, 3 Jun 2004 22:53:54 -0700 (PDT)
X-Message-Number: 18
On Thu, 3 Jun 2004, Scott Miller wrote:
>I thought that was in there somewhere, but I couldn't find it. Does the PID
>setting apply only to converse, or to KISS as well? Not that there'd be any
>reason to turn it on in KISS mode...
>
>How about a roll call of the APRS client authors? Does anyone NOT check the
>PID as indicated in the APRS spec?
As far as the clients go, any that allow TNC's in Converse mode to be used
for APRS cannot check the PID on those TNC's. They can try to turn on the
PID filtering of course though.
Any that allow use of AX.25 kernel networking and/or KISS-mode TNC's can
certainly check PID, and should do so. Xastir does in those cases.
--
Curt, WE7U. archer at eskimo dot com
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: Curt Mills <archer@eskimo.com>
Date: Thu, 3 Jun 2004 22:51:54 -0700 (PDT)
X-Message-Number: 19
On Thu, 3 Jun 2004, Robert Bruninga wrote:
>Scott, why oh why as a late comer to APRS, do you seem
>bent on insisting that everyone else should
>change what they are doing to march to your tune?
I don't see that he's doing anything of the sort. He's following the
specs.
>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...
He is very definitely focusing on positive things that he can contribute...
That's why real progress is being made!
--
Curt, WE7U. archer at eskimo dot com
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: Dynamic unproto path for land use
From: Curt Mills <archer@eskimo.com>
Date: Thu, 3 Jun 2004 22:38:06 -0700 (PDT)
X-Message-Number: 20
On Thu, 3 Jun 2004, Scott Miller wrote:
>I thought about doing this. The main problem is that I'm running out of
>configuration space in the OpenTracker. Let's see... a single box would
>need six bytes of storage to define the corners to about 2.5 meters
>resolution. That wouldn't be too bad. Multiple boxes would be more
>trouble, especially dealing with dynamic storage requirements. It'd add to
>the code required, and I'd have to add more user interface stuff to handle
>data input for the configuration program. But it's doable.
Or just define a point and a distance. Less storage requirements.
--
Curt, WE7U. archer at eskimo dot com
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: Curt Mills <archer@eskimo.com>
Date: Thu, 3 Jun 2004 22:45:58 -0700 (PDT)
X-Message-Number: 21
On Thu, 3 Jun 2004, Robert Bruninga wrote:
>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. We took
>along time to build the network out of what is.
>
>There are hundreds of other frequencies in the VHF
>and UHF spectrum for experimenting with other
>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.
--
Curt, WE7U. archer at eskimo dot com
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: Enough griping, here's _a_ solution...
From: Wes Johnston <wes@johnston.net>
Date: Fri, 04 Jun 2004 07:14:01 -0400
X-Message-Number: 22
I like the little league analogy. Did you know there was a rule that allow
runners to bunt? No one used the rule until today, when everyone cried
foul when a runner bunted. Right there, on page 12 of the APRS WG
document.... "Protocol ID =97 This field is set to 0xf0 (no layer 3
protocol)." This says APRS packets will use F0 as a PID. Scott uses PID
77. It's a little obscure rule that was buried in the rule book that
hardly anyone read. But it is in there, and Scott read it.
It is important to note here that the digipeaters are not broken. No digi
owner needs to do anything. The clients need to figure out how to filter
based on PID or SUBNET. Since every version of APRS (except DOS) has a
method through one means or another to use kiss TNCs, this should not be a
big issue. I do understand the problems that findu faces though.... GIGO
(garbage in garbage out)... and findu will have to filter based on the
TOCALL of OPNTRK, and DOS APRS can filter that way too... Open trac can
use the subnet in tocall method because it does not need to specify an icon
in that field.
Perhaps that OPNTRK could be changed as Bob suggested to a valid APRS
subnet? Is that a workable solution?
Wes
----------------------------------------------------------------------
Subject: Re: Solar tetroon Sky Diamond - signal loss????
From: "Jason Rausch" <ke4nyv@hamhud.net>
Date: Fri, 4 Jun 2004 8:8:22
X-Message-Number: 23
Scott said:
>Locking up as in causing it to freeze, or just keeping it busy with
>excessive packets? If it's freezing because of parsing problems, I'll be
>happy to help debug.
Yes, its a pasring issue with a bad character in a packet that makes the
HH2 choke. It has been a problem for a long time. Dale thought he nipped
it in the butt on this last revision, but I guess it came back in another
form. I wish I was more profficient in C or I would take a whack at it
myself. Dale and Steve are really the C gurus in the group.
Scott, do you subscribe to the HH2 Yahoo group? Come over and lend your 2
cents, we always seem to give equal time to everyone's suggestions.
Jason KE4NYV
www.ke4nyv.com
RPC Electronics
www.ke4nyv.com/rpc
----------------------------------------------------------------------
Subject: 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 08:53:28 -0500
X-Message-Number: 24
>Of course, the benefit of WIDES from 10K+ altitudes, no matter how far
>fetched, are only of benefit right on the very edge of the range circle. 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. 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.
-----
gregg@cytetech.com (Cyte Technologies Inc)
----------------------------------------------------------------------
Subject: RE: How about making OpenTrak part of APRS SPEC?
From: "AE5PL Lists" <HamLists@ametx.com>
Date: Fri, 4 Jun 2004 09:13:24 -0500
X-Message-Number: 25
I meant for the following to be posted. Oops. Shouldn't reply to posts
before my first cup of coffee :-)
>-----Original Message-----
>From: Jeff King
>Posted At: Thursday, June 03, 2004 9:16 PM
>Subject: [aprssig] How about making OpenTrak part of APRS SPEC?
>
>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.
The "shortcomings" that you refer to are really just a different format
to send the information which is not compatible with the APRS packet
format.
>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.
This is not a matter of NIH, but a matter of trying to modify the spec
to incorporate a completely different protocol. Scott understands this
(hence the PID of 0x77 instead of 0xF0).
APRS-IS is called APRS-IS for a reason: it distributes APRS format
packets, not all packets. What we have seen with the balloon situation
is a two-fold problem: OpenTrak does not use APRS data types (and could
pass incompatible data) and many IGates do not differentiate PID's (I
would hope because those TNC's are not being run in KISS mode, not for
other reasons). The authors of APRS-IS servers were concerned that this
would happen and we now see that it has. From the reports, there are
some clients that are bothered by the non-APRS packets as well. Serious
consideration must be given to looking for a separate frequency for
OpenTrak-format packets. This all gets down to backwards-compatibility
which was so lambasted during previous threads. We can try to get
thousands of users to change equipment and or software OR we can find a
new home for OpenTrak-format packets. I think the latter is far more
doable.
>Without change and progress, APRS will eventually die.
Ah, the mantra of all on this SIG who don't get what they want. APRS is
not dying. The OpenTrak protocol does nothing to "save" APRS nor will
it cause APRS to die. I encourage the OpenTrak developers to continue
their trek, but let's quit trying to merge the OpenTrak protocol with
the APRS protocol, either in the specification or on the air. It is
counterproductive to both.
73,
Pete Loveall AE5PL
mailto:pete@ae5pl.net
----------------------------------------------------------------------
Subject: Re: Dynamic unproto path for land use
From: "Gregg G. Wonderly" <gregg@skymaster.cytetech.com>
Date: Fri, 04 Jun 2004 09:15:58 -0500
X-Message-Number: 26
>I that case, you might as well design the network to provide that sort of
>information. I think cellular networks do power management, though in a
>more refined manner.
Cellular networks handle calls from the strongest stations, and reduce their
output power to only serve the customers they are talking to. If you have a
T1 into a cell site, and your are the weakest of 24 active calls, and someone
closer requests service, you are going to get disconnected if your call can
not be handed off.
-----
gregg@cytetech.com (Cyte Technologies Inc)
----------------------------------------------------------------------
Subject: Re: Solar tetroon Sky Diamond 6 aloft right now!
From: "Gregg G. Wonderly" <gregg@skymaster.cytetech.com>
Date: Fri, 04 Jun 2004 09:30:54 -0500
X-Message-Number: 27
>>If anyone has a good technical contact at Kantronics,
>>let me know - I'd like to talk to them about getting this
>>bug fixed in future firmware revisions, if it hasn't been fixed
>already.
>
>And what good would that do for the 100,000 that are
>already out there?
Humm, use 100,000 existing TNCs to further enhance the abilities of packet
based telemetery systems, or ask the community to purchase another 100,000
TNCS, radios, antennas tower space, cans etc to support this effort on a new
frequency with a comparable infrastructure?
Seems to me that the right answer is to fix the cheapest to fix problem, and
that is the TNCs and the software...
-----
gregg@cytetech.com (Cyte Technologies Inc)
----------------------------------------------------------------------
Subject: Re: Solar tetroon Sky Diamond 6 aloft right now!
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Fri, 04 Jun 2004 10:42:12 -0400
X-Message-Number: 28
>>>Wes Johnston <wes@johnston.net> 6/3/04 8:30:29 PM >>>
>Just have it run path of WIDE WIDE when altitude is
><500' .... when >500' run no wides in path.
I still think the best recommendation is: RELAY,WIDE,WIDE while low to the
ground and WIDE while high.
There is a small penalty for running WIDE at altitude, but it has a payoff
in that many APRS packets systems are deaf. EIther poor antennas, long
coax runs, inside antennas, or basement installations. But the penalty is
minimal. There is no digi-to-digi exponential growth of copies, every digi
does it once, and no more, everyone gets a copy, etc.
Going direct is of course the minimal impact, but then some people wont see
it. And again, adding the single WIDE is of no consequence compared to the
exponential explosion of packets if MORE than one WIDE is used.
So I recommend RELAY,WIDE,WIDE while low.
WIDE while high.
de Wb4APR, Bob
----------------------------------------------------------------------
Subject: Re: Solar tetroon Sky Diamond 6 aloft right now!
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Fri, 04 Jun 2004 10:50:49 -0400
X-Message-Number: 29
>>>Jeff King <jeff@aerodata.net> 6/3/04 9:08:21 PM >>>
>which clearly defines the PID structures, of which APRS
>UI frames use 0xF0.
>
>Consequently, any of the other PID's, including undefined
>ones such as OpenTrak, shouldn't cause a problem,
>if the software is specification compliant.
I dont think you understand AX.25 packet as implemented in amateur radio
over the last 26 years. Your use of the term "shouldnt" is correct, but
the fact is, IT DOES. And it has NOTHING to do with APRS software or
firmware. It has to do with the apparently less than perfect AX.25
monitoring code built into the dozens and dozens of TNC's manufactured over
the years which is what HAMS want to use on APRS.
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,...
Bob
----------------------------------------------------------------------
Subject: Re: Solar tetroon Sky Diamond 6 aloft right now!
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Fri, 04 Jun 2004 10:58:08 -0400
X-Message-Number: 30
>>>Jeff King <jeff@aerodata.net> 6/3/04 10:06:30 PM >>>
>AX.25 wasn't created until ~1982..
>2004-1982 = 22 years, not 26. Packet (ascii) wasn't legal
>in the U.S. 26 years ago.
Sorry, ASCII was legalized I thought in 1978 when I had one of the first
ASCII-LEGAL BBS's on the air. You are right that it wasnt until 82 that
our local AMRAD group here in DC area developed AX.25.
I stand corrected.
Bob
----------------------------------------------------------------------
Subject: Re: Solar tetroon Sky Diamond 6 aloft right now!
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Fri, 04 Jun 2004 11:03:14 -0400
X-Message-Number: 31
>>>Jeff King <jeff@aerodata.net> 6/3/04 10:06:30 PM >>>
>But the whole point of PID's is to PREVENT
>unpredictable results. Your 180 degrees out of phase
>with reality here.
But it DOESNT as was just clearly demonstrated and has been KNOWN for the
last 22 years. SO no matter how much you claim from your mountain top that
it "shouldnt" it does. And no amount of hollering about how it "shouldnt"
is going to go out an cause all of the OUT-OF-BUSINESS TNC manufacturers to
come back to life and re-issue their TNC's.
>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.
Absolutely! It TRANSIMTS with a PID of F0, but NOWHERE does it claim that
it can be used on RECEIVE as a discriminant. Because we all KNEW and still
KNOW that there are tens of thousands of TNC's out there that dont
discirimate on PID.
>Or is the APRS specification/charter a work of fiction
>that can be disregarded anytime it seems prudent?
It has to be understood. Some people just cannot understand common sense
and the Amateur Radio environment where most hams just want to use the
equipment they have rather than having to have it obsoleted every time a
new hacker comes along...
Bob
----------------------------------------------------------------------
Subject: Re: Solar tetroon Sky Diamond 6 aloft right now!
From: "Gregg G. Wonderly" <gregg@skymaster.cytetech.com>
Date: Fri, 04 Jun 2004 10:04:48 -0500
X-Message-Number: 32
>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,...
Okay, so now that we have 2 different users of the collection of TNCs that
are called the APRS network today, but which can provide packet radio
digi-peating services for any traffic on 144.39, it would seem that we
should share the spectrum, as Part-97 demands we do. So, from this point
forward, how about if APRS only systems be turned off on even numbered
minutes (using GPS time reference), and opentrac systems will only transmit
on even numbered minutes.
It would be really easy to build a little PIC based switching device that
listened to the GPS data, and just opened the receive data line to the
computer, or from the radio so that the APRS system would be unaffected by
the opentrac packets :-)
We can make lots of arguments here, or we can step up to the challenge of
making things work, as HAMs have done for decades... Humm, looks like
there is a potential market for a <$100.00 TNC that just does digipeating
for UIFRAMEs, and uses KISS mode.
P.S. the even minute transmission and the PIC device was a joke, ignore it...
-----
gregg@cytetech.com (Cyte Technologies Inc)
----------------------------------------------------------------------
Subject: Re: Solar tetroon Sky Diamond 6 aloft right now!
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Fri, 04 Jun 2004 11:13:20 -0400
X-Message-Number: 33
>>>"James Jefferson" <jj@aprsworld.net> 6/3/04 11:41:12 PM >>>
>...preventing the OpenTrac packets from getting into the
>[APRSworld] data as Base-91 APRS packets.
>
>I am dropping anything that is to the OPNTRK destination
>address.
But expecting 20,000 APRS users to all have to add filters to protect
themselves from someone transmitting non APRS compliant packets on the APRS
frequency is ludicrous.
APRS has a mechanism for experimental packets. There are MANY authors who
have taken advantage of that and there are no problems. But why OPENTRACK
still wants to insist that it has the right to use non-compatible packets
on the APRS channel and not comply with APRS is beyond me. And then have
the audacity to claim that we all have to change all 20,000 users to
protect ourselves from them is also ludicrous.
Bob
----------------------------------------------------------------------
Subject: Re: Solar tetroon Sky Diamond 6 aloft right now!
From: "KC2MMi" <kc2mmi@verizon.net>
Date: Fri, 4 Jun 2004 11:16:52 -0400
X-Message-Number: 34
<The bottom line is this data is not APRS, and in my opinion
does not belong on the APRS frequency.>
Ah, Steve? What is this "APRS frequency" ? The Great White Father who sits
in Washington doesn't say there is any frequency assigned to the exclusive
use of APRS. APRS is supposed to be *sharing* a frequency for experimental
purposes.
It would be nice to get frequency assignments, but probably simpler to fix
the software problem and play nice alongside other traffic.<G>
----------------------------------------------------------------------
Subject: Re: Solar tetroon Sky Diamond 6 aloft right now!
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Fri, 04 Jun 2004 11:18:26 -0400
X-Message-Number: 35
>>>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...
Go to the APRS SPEC errata page and follow the links to EXPERIMENTAL
FORMATS and you will see an up-to-date list of all those experimental
formats that have been registered by other authors.
Bob
----------------------------------------------------------------------
Subject: Re: OPNTRK packets and exciting position reports from Findu RE: [apr
ssig] Re: Solar tetroon Sky Diamond 6 aloft right now!
From: "Scott Miller" <scott@opentrac.org>
Date: Fri, 4 Jun 2004 08:20:43 -0700
X-Message-Number: 36
>>I don't see how you're getting valid positions. Base91 starts at what, 33
>>decimal?
>
>Base91 posits always start with '/'. Of course that can come after
>a timestamp also.
No, I mean the range of valid characters starts at 33 decimal, or '!'.
Values less than that are obviously bad.
Scott
N1VG
----------------------------------------------------------------------
Subject: Re: Solar tetroon Sky Diamond 6 aloft right now!
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Fri, 04 Jun 2004 11:26:13 -0400
X-Message-Number: 37
>>>Curt Mills <archer@eskimo.com> 6/4/04 1:51:54 AM >>>
On Thu, 3 Jun 2004, Robert Bruninga wrote:
>>Scott, why oh why as a late comer to APRS, do you seem
>>bent on insisting that everyone else should
>>change what they are doing to march to your tune?
>
>I don't see that he's doing anything of the sort.
>He's following the specs.
But the APRS spec has NOTHING to do with how the hundreds of thousands of
AX.25 TNC's work. And we told him from the beginning that changing the PID
will NOT prevent him from causing problems. He is not following the APRS
spec in any way whatsoever with the OPENTRAK packets he is transmitting on
the national APRS channel.
Bob
----------------------------------------------------------------------
Subject: Re: Dynamic unproto path for land use
From: "Scott Miller" <scott@opentrac.org>
Date: Fri, 4 Jun 2004 08:22:32 -0700
X-Message-Number: 38
>Or just define a point and a distance. Less storage requirements.
And then it's got to perform a great circle distance calculation, which
isn't going to be fun when I've got a few hundred bytes of Flash left. With
the corner coordinates, it's just a few simple comparisons.
Scott
N1VG
----------------------------------------------------------------------
Subject: Re: Solar tetroon Sky Diamond 6 aloft right now!
From: James Jefferson <jj@aprsworld.net>
Date: Fri, 4 Jun 2004 10:28:46 -0500
X-Message-Number: 39
On Friday 04 June 2004 10:13 am, Bob B wrote:
>>>>"James Jefferson" <jj@aprsworld.net> 6/3/04 11:41:12 PM >>>
>>...preventing the OpenTrac packets from getting into the
>>[APRSworld] data as Base-91 APRS packets.
>>
>>I am dropping anything that is to the OPNTRK destination
>>address.
>
>But expecting 20,000 APRS users to all have to add filters to
>protect themselves from someone transmitting non APRS
>compliant packets on the APRS frequency is ludicrous.
Nowhere did I suggest that. I simply answered why aprsworld wasn't getting
bogus APRS packets.
-----
As far as I can tell there have been two problems that we observed:
1) findu got data that for one reason or another affected how KC8UCH-11 got
displayed. One station was affected and that was the sending station - and
this was with one application, findu.
2) Jason's HH2 crashed.
findu.com can figure out how to ignore the opentrac packets and/or make sure
that coordinates fall on earth and the change can be made and installed in a
matter of minutes. I know it can be because I did it yesterday when Robert
(KC8UCH) reported that aprsworld parsed one of his packets incorrectly. Even
if findu doesn't want to do anything, then the only station that is effected
is the station sending the data. We've shown that the aprs NETWORK can easily
handle foreign protocols without a problem.
The hamhud code can be updated and new firmware made available. The firmware
is downloaded over the serial port and the whole unit can be upgraded in less
than 30 minutes, including the time it takes to remove the unit from the
vehicle and re-install it. The HH group has a bunch of talented hackers that
should be able to fix or change their code fairly easily. If not I believe
Curt and Scott have both volunteered to help. I'll toss my hat in too.
So I fail to see where the big comotion of objections come from...
-Jim KB0THN
----------------------------------------------------------------------
Subject: Re: Solar tetroon Sky Diamond - signal loss????
From: "Scott Miller" <scott@opentrac.org>
Date: Fri, 4 Jun 2004 08:29:40 -0700
X-Message-Number: 40
>form. I wish I was more profficient in C or I would take a whack at it
>myself. Dale and Steve are really the C gurus in the group.
>
>Scott, do you subscribe to the HH2 Yahoo group? Come over and lend your 2
>cents, we always seem to give equal time to everyone's suggestions.
No, I'm not a member of the group yet. Haven't messed with it because it's
a PIC project, mostly, but if it's written in C I think I could tolerate it.
=] I'll join up and see what I can do.
Scott
N1VG
----------------------------------------------------------------------
Subject: Re: Solar tetroon Sky Diamond - signal loss????
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Fri, 04 Jun 2004 11:28:48 -0400
X-Message-Number: 41
>>>Curt Mills <archer@eskimo.com> 6/4/04 1:58:54 AM >>>
>> That Balloon has been locking up my HamHUD II
>>all day long, constantly! ...
>
>But isn't that code open-source, so it can be changed
>easily?
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?
Bob
----------------------------------------------------------------------
Subject: Re: Solar tetroon Sky Diamond 6 aloft right now!
From: "Curt, WE7U" <archer@eskimo.com>
Date: Fri, 4 Jun 2004 08:46:10 -0700 (PDT)
X-Message-Number: 42
On Thu, 3 Jun 2004, Neil Johnson wrote:
>What about all of us who have old KPC 3+ 's or run aprsd which pretty much
>precludes running a TNC in KISS mode.
Last I recall there are versions of aprsd that use AX.25 kernel networking,
so in that case you'd need to put the TNC in KISS mode to play. In fact, I
think the current SourceForge version of aprsd has it, but it might not be
in the docs.
Are old KPC-3+'s missing KISS mode? I thought darn near any TNC made in
the last 15 years had KISS mode. My very old PK-88's have KISS mode.
--
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: "Scott Miller" <scott@opentrac.org>
Date: Fri, 4 Jun 2004 08:48:40 -0700
X-Message-Number: 43
>But expecting 20,000 APRS users to all have to add filters to
>protect themselves from someone transmitting non APRS
>compliant packets on the APRS frequency is ludicrous.
First, as Wes pointed out it's exactly compliant with both the APRS spec and
the AX.25 spec. And as an added bonus, OPNTRK is an altnet that should be
filtered by many stations by default anyway.
Second, we've established two actual problems caused by yesterday's events -
both apparently caused by non-compliant parsers, and both should be easy to
fix. I'm going over the HH2 group right now to help out with their
debugging.
How about this for a proposed APRS spec change: Make OPNTRK NOT a valid
APRS altnet. No, it doesn't really change anything for anyone, but at least
then Steve can implement filtering without having to violate the spec. Even
that shouldn't really be necessary - as I've pointed out repeatedly,
OpenTRAC packets that get onto the APRS IS will not be valid APRS packets
and should be ignored by a spec-compliant parser anyway.
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.
Scott
N1VG
----------------------------------------------------------------------
Read previous mail | Read next mail
| |
