| |
ZL3AI > APRDIG 09.06.04 08:34l 729 Lines 29341 Bytes #999 (0) @ WW
BID : 3412-ZL3AI
Read: GUEST
Subj: TAPR Digest, Jun 03, 2/6
Path: DB0FHN<DB0THA<DB0ERF<DB0FBB<DB0GOS<DB0EEO<DB0RES<ON0AR<7M3TJZ<ZL2TZE<
ZL3VML
Sent: 040609/0503Z @:ZL3VML.#80.NZL.OC #:25536 [Chch-NZ] FBB7.00i $:3412-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
Subject: Re: Garbled status text Re: Solar tetroon Sky =?iso-8859-1?q?Diam ond
6 aloft right?= now!
From: James Jefferson <jj@aprsworld.net>
Date: Thu, 3 Jun 2004 13:54:10 -0500
X-Message-Number: 26
On Thursday 03 June 2004 01:32 pm, Jeff King wrote:
>On Thu, 3 Jun 2004 14:02:43 -0400, Rochte, Robert wrote:
>>>One good addition for opentrac would be the addition of dynamic
>>>digi paths that can be triggered via certain conditions.
>>
>>I have the Opentracker configured to use "RELAY,WIDE,WIDE" below 3k
>>meters and "WIDE,WIDE" above this altitude. Haven't checked yet to
>>see if that's what happened, but I assume so!
I agree with Jeff about the path. Perhaps have a single wide below 1000 meters
and then go to nothing above that.
In ground based applications the point of having multiple wides is usually to
get your signal to an I-Gate. In this near-space application the coverage
area includes dozens of digipeaters and igates so multiple hops aren't needed
because the packet is almost assuredly going to get to an i-gate.
Now I'm sure that I'll get some flames along the lines of "getting to an
i-gate isn't what amateur radio is about, it's about communicating with
people". The answer for that is that the tetroon's coverage area is so
massive that adding another 50 miles onto the coverage circle really does
nothing.
Anyway, it's really awesome to watch (I have the aprsworld track automatically
reloading in the browser). :-)
-Jim
----------------------------------------------------------------------
Subject: Re: Garbled status text Re: Solar tetroon Sky Diamond 6 aloft right
now!
From: Steve Dimse <k4hg@tapr.org>
Date: Thu, 3 Jun 2004 14:55:50 -0400
X-Message-Number: 27
On 6/3/04 at 11:23 AM Scott Miller <scott@opentrac.org> sent:
>KC8UCH-11>APOT01,RELAY,WIDE,WIDE,qAR,W8FSM-10:/031414z4225.18N/08258.58WO141
>/012/A=009705 08.2V 44C>RROCHTE@GPACADEMY.ORG
>KC8UCH-11>APOT01,WIDE,WIDE,qAS,NS8E:/031415z4225.00N/08258.36WO135/016/A=009
>938 08.1V 32C>RROCHTE@GPACADEMY.ORG
>
>I think a WIDE2-2 would be better than two WIDEs, but then I'm not sure how
>the network is set up in those parts.
At that altitude, even a single WIDE is close to overkill, most of the packets
in the raw list:
http://www.findu.com/cgi-bin/track.cgi?call=kc8uch-11°ree=2
are heard directly, some via one digi, and very required two.
Steve K4HG
----------------------------------------------------------------------
Subject: Re: Garbled status text Re: Solar tetroon Sky Diamond 6 aloft right
now!
From: Jeff King <jeff@aerodata.net>
Date: Thu, 3 Jun 2004 15:07:24 -0400
X-Message-Number: 28
OK, was thinking it would go to 100K. At 65,000 feet, your radio horizon is
only 339miles as opposed to 420 miles (100K). Tf
So assuming it keeps going east, you'll loose touch with Chicago and only
saturate the network (wides) from Grand Rapids MI to New York city at
altitude.
BTW, is the float a function of equilibrium or do you have a active system on
board?
--
Jeff King, jeff@aerodata.net on 06/03/2004
----------------------------------------------------------------------
Subject: Re: Solar tetroon Sky Diamond 6 aloft right now!
From: "Curt, WE7U" <archer@eskimo.com>
Date: Thu, 3 Jun 2004 12:33:02 -0700 (PDT)
X-Message-Number: 29
On Thu, 3 Jun 2004, Steve Dimse wrote:
>I'm not sure why you are blaming the IGate. By definition, the IGate is
supposed>to send everything it hears to the APRS IS. It is the clients that
choose
>whether or not to filter based on destination call.
>
>The packets causing the problem look like:
>
>KC8UCH-11>OPNTRK,NS8E*,WIDE,WIDE,qAS,808FCABF:>r:@*T449A>RROCHTE@GPACADEMY.ORG
>
>This is a completely valid APRS status packet. The only thing different from a
>completely normal APRS packet is that the destination is not one of the defined
>ones, which makes it something Bob calls an alternate net callsign.
Isn't the tracker sending out both APRS and OpenTrac packets? It's ok to
send out APRS packets with a different destination. It's in the spec.
If we're talking about an igate that is converting opentrac packets to APRS
packets and then injecting them into the 'net, that's a different story. A
few Xastir versions did this, but the latest versions do not. It's always
possible that someone hasn't upgraded recently and so is injecting the
converted OpenTrac packets.
>The is exactly the reason why I've argued that your protocol is incompatible
>with APRS, both on the air and in the APRS IS.
Again, are we talking the APRS packets out of his tracker, or the OpenTrac
packets/converted to APRS?
>This particular one does not
>appear to cause problems other than the garbage characters appearing in the
>status text, but unless you test every possible opentrack packet on every
client>(obviously impossible), you cannot be assured that some others will not
cause a
>buffer overrun or other serious problem.
>
>Yes, in a perfect world, nothing bad would happen from garbage input, but the
>world, and APRS specifically, are not perfect. We certainly have seen cases
>where bad packets cause client programs to crash.
I've seen a lot of them, and therefore patched the client to handle them.
In my view, such "killer" packets help to improve the system, not degrade
it.
--
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: OPNTRK packets and exciting position reports from Findu RE:
[apr ssig] Re: Solar tetroon Sky Diamond 6 aloft right now!
From: "Rochte, Robert" <rrochte@gpacademy.org>
Date: Thu, 3 Jun 2004 15:53:52 -0400
X-Message-Number: 30
>I've seen a lot of them, and therefore patched the client to handle
>them. In my view, such "killer" packets help to improve the system,
>not degrade it.
Personally, I find some of these position reports based on OPNTRK packets to
be quite exhilarating:
Position of KC8UCH-11
6094008.4 miles southwest of SCOTT STATION, ANTARCTICA
Course: 155.0 Speed: 437.3 MPH
If only.... =)
73,
Robert
KC8UCH
----------------------------------------------------------------------
Subject: Re: Solar tetroon Sky Diamond 6 aloft right now!
From: Steve Dimse <k4hg@tapr.org>
Date: Thu, 3 Jun 2004 15:59:51 -0400
X-Message-Number: 31
On 6/3/04 at 12:33 PM Curt, WE7U <archer@eskimo.com> sent:
>Isn't the tracker sending out both APRS and OpenTrac packets? It's
>ok to send out APRS packets with a different destination. It's in
>the spec.
That's correct.
>If we're talking about an igate that is converting opentrac packets
>to APRS packets and then injecting them into the 'net, that's a
>different story. A few Xastir versions did this, but the latest
>versions do not. It's always possible that someone hasn't upgraded
>recently and so is injecting the converted OpenTrac packets.
No, it is not doing that. It is sending the opentrack packets into the APRS
IS. This is what an IGate is supposed to do, however the problem is the
opentrack format packets can look like valid APRS packets, or take
unplanned routes through the parsing tree causing crashes.
>> The is exactly the reason why I've argued that your protocol is incompatible
>>with APRS, both on the air and in the APRS IS.
>
>Again, are we talking the APRS packets out of his tracker, or the
>OpenTrac packets/converted to APRS?
We are talking about opentrack packets, unconverted by anything.
I've now found the problem is worse than just the status message.
http://www.findu.com/cgi-bin/posit.cgi?call=kc8uch-11
You can see lots of bad positions there. The raw data causing this looks
like:
KC8UCH-11>OPNTRK,NS8E*,WIDE,qAS,NS8E:!?l@6|A41A>RROCHTE@GPACADEMY.ORG
In the APRS Spec, the packet format "!" is followed by a position report,
if the character after ! is a number, then it is the original format,
otherwise it is a base 91 compressed format position...in this format, any
character is acceptible, so there is nothing else to filter on...this is a
valid APRS position report!
>I've seen a lot of them, and therefore patched the client to handle
>them. In my view, such "killer" packets help to improve the system,
>not degrade it.
Fine as far as it goes...if a programmer wants to feed bizarre packets into
their client, looking for crashes and fixing them, that client will
undoubtable be better. If you can send every possible packet to every
client in every configuration, and be assured that any and all problems
found are fixed, then the entire system will be stronger. However, when you
send a small, random subset of these packets onto an otherwise functional
net, you risk crashing key assests at critical times. Imagine if these
packets end up crashing the only IGate near where this baloon comes down,
thereby losing the terminal position reports. Or worse, losing the EOC APRS
client during a tornado warning. It could happen, and unless you have
tested all clients against all legal opentrack packets, you cannot say it
will not happen!
A separate issue is that some of these are not incorrect packets, these are
LEGAL APRS format packets, they just mean something completely different
than when parsed using the APRS spec, contaminating the data.
Steve K4HG
----------------------------------------------------------------------
Subject: Re: Solar tetroon Sky Diamond 6 aloft right now!
From: "Scott Miller" <scott@opentrac.org>
Date: Thu, 3 Jun 2004 13:00:28 -0700
X-Message-Number: 32
>I'm not sure why you are blaming the IGate. By definition, the IGate is
supposed>to send everything it hears to the APRS IS. It is the clients that
choose
>whether or not to filter based on destination call.
The point is, it should NOT hear this. The only way this is going to happen
is if someone disregards the PID, or the TNC is broken and shows non-text
traffic in converse mode.
>This is a completely valid APRS status packet. The only thing different
from a
No, it's not even an UNPROTO packet.
>The is exactly the reason why I've argued that your protocol is incompatible
>with APRS, both on the air and in the APRS IS. This particular one does not
It is most definitely incompatible with the APRS IS. It's perfectly fine on
air with any device that follows the minimum standards of the AX.25 spec.
Scott
N1VG
----------------------------------------------------------------------
Subject: Re: Solar tetroon Sky Diamond 6 aloft right now!
From: "Scott Miller" <scott@opentrac.org>
Date: Thu, 3 Jun 2004 13:04:34 -0700
X-Message-Number: 33
It was apparently configured to use RELAY,WIDE,WIDE under 3000 meters. The
debate now is what path should be used at altitude. Direct should do it in
most cases, but I can see where a single WIDE might be needed to get to an
IGate.
Scott
N1VG
----- Original Message -----
From: "Christensen, Eric" <CHRISTENSENE@MAIL.ECU.EDU>
>Did someone really put up a balloon with RELAY,WIDE,WIDE as the path?!?
>That is scary.
----------------------------------------------------------------------
Subject: Re: Solar tetroon Sky Diamond 6 aloft right now!
From: "Scott Miller" <scott@opentrac.org>
Date: Thu, 3 Jun 2004 13:11:38 -0700
X-Message-Number: 34
>Isn't the tracker sending out both APRS and OpenTrac packets? It's
>ok to send out APRS packets with a different destination. It's in
>the spec.
APRS packets are sent with a TOCALL of APOT01, OpenTRAC packets are sent
with a tocall of OPNTRK. And I know you understand this Curt, but to
reiterate, that's NOT how they are distinguished.
The protocol identifier specifically identifies the packets as having a
defined higher level protocol, that they're NOT generic UNPROTO packets like
APRS uses. This is true for IP, Net/ROM, Appletalk, ARP, LQP, FlexNet, and
every other non-text protocol used on AX.25. It's how the AX.25 protocol
was designed.
The problem is people running converse mode on IGates using TNCs that don't
pay attention to the type of packets they're receiving. I've always felt
that converse mode is a bad idea for anything besides keyboard-to-keyboard
QSOs using a dumb terminal. The situation is equivalent to using TCPDUMP as
a network interface layer.
>I've seen a lot of them, and therefore patched the client to handle
>them. In my view, such "killer" packets help to improve the system,
>not degrade it.
Eventually, in a Nietzschean kind of way.
Scott
N1VG
----------------------------------------------------------------------
Subject: Re: Solar tetroon Sky Diamond 6 aloft right now!
From: Steve Dimse <k4hg@tapr.org>
Date: Thu, 3 Jun 2004 16:14:42 -0400
X-Message-Number: 35
On 6/3/04 at 1:00 PM Scott Miller <scott@opentrac.org> sent:
>>I'm not sure why you are blaming the IGate. By definition, the IGate is
>supposed
>>to send everything it hears to the APRS IS. It is the clients that choose
>>whether or not to filter based on destination call.
>
>The point is, it should NOT hear this. The only way this is going to happen
>is if someone disregards the PID, or the TNC is broken and shows non-text
>traffic in converse mode.
Well, there are multiple IGates sending the data to the APRS IS (a quick
glance at the packets shows at least VA3DVR, N2TBX-11, NS8E, KB2TXP,
808FCABF, W8MSU-10, and W8MSU-10) it is also being digipeated by multiple
digis, Clearly relying on the PID to keep the data from appearing on the
APRS IS is not working. What sort of testing did you do on this? I am not
surprised many TNCs would ignore the PID, this is uncharted territory...
>>This is a completely valid APRS status packet. The only thing different
>from a
>
>No, it's not even an UNPROTO packet.
If your point is that it is not AX-25 on the air, you may be right, but the
fact is it is getting into the APRS in large quantity from multiple IGates,
and once there IT IS A VALID APRS PACKET!
>>The is exactly the reason why I've argued that your protocol is
>incompatible
>>with APRS, both on the air and in the APRS IS. This particular one does not
>
>It is most definitely incompatible with the APRS IS. It's perfectly fine on
>air with any device that follows the minimum standards of the AX.25 spec.
Apparently large numbers do not, and we now have documentation of the
problem I hypothesized when I begged you to keep this off the APRS channel.
Are you going to blame all the TNC manufacturers and IGate operators and
continue to place the APRS network at risk, or are you going to take your
protocol off the APRS frequency?
Steve K4HG
----------------------------------------------------------------------
Subject: Re: Solar tetroon Sky Diamond 6 aloft right now!
From: "Curt, WE7U" <archer@eskimo.com>
Date: Thu, 3 Jun 2004 13:14:35 -0700 (PDT)
X-Message-Number: 36
On Thu, 3 Jun 2004, Steve Dimse wrote:
>No, it is not doing that. It is sending the opentrack packets into the APRS IS.
>This is what an IGate is supposed to do, however the problem is the opentrack
>format packets can look like valid APRS packets, or take unplanned routes
>through the parsing tree causing crashes.
Ok. Who's doing that? The OpenTrac binary packets are not supposed to be
sent through. OpenTrac packets converted to APRS packets aren't supposed
to be sent through either now, but might be still by some slightly older
Xastir clients.
The intent for the OpenTrac packets was to go through a separate internet
network. I believe that is still correct.
>when you send a small, random
>subset of these packets onto an otherwise functional net, you risk crashing key
>assests at critical times. Imagine if these packets end up crashing the only
>IGate near where this baloon comes down, thereby losing the terminal position
>reports. Or worse, losing the EOC APRS client during a tornado warning. It
could>happen, and unless you have tested all clients against all legal opentrack
>packets, you cannot say it will not happen!
It can happen with bugs in APRS clients, newly written APRS clients with
bugs, computers going awry, noise over overruns in the system (usually in
the TNC->Computer interface).
Personally I'd rather see a "killer" packet or two on a regular basis in
small quantities all along the timeline, than to get a bunch of them dumped
in when some critical event is happening. It makes the whole system more
robust in a hurry as people try to figure out why a few stations here and
there are crashing. Gives people a reason to fix things during
non-critical times.
By keeping everything possible off the system you don't know how
susceptible the system is to problem packets...
--
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: "J. Lance Cotton" <joe@lightningflash.net>
Date: Thu, 03 Jun 2004 15:19:42 -0500
X-Message-Number: 37
Scott Miller wrote:
>It is most definitely incompatible with the APRS IS. It's perfectly fine on
>air with any device that follows the minimum standards of the AX.25 spec.
But when a large number (most?) of the APRS base stations out there are just
TNCs dumping the raw packets to the serial port, how can they filter based
on the PID? It's not even indicated in the strings sent by a TNC!
--
J. Lance Cotton, KJ5O
http://map.findu.com/kj5o-14
joe@lightningflash.net
----------------------------------------------------------------------
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: Thu, 3 Jun 2004 13:21:57 -0700
X-Message-Number: 38
> 6094008.4 miles southwest of SCOTT STATION, ANTARCTICA
Looks like someone needs to add some sanity checking. It's awfully tough to
get SOUTH of Scott Station. =] And 6,000,000 miles puts it several times
the moon's distance from Earth...
I'm surprised it's getting parsed at all.
Scott
N1VG
----------------------------------------------------------------------
Subject: Paths again was Re: Garbled status text Re: Sola r tetroon Sky
Diamond 6 aloft right now!
From: "Rochte, Robert" <rrochte@gpacademy.org>
Date: Thu, 3 Jun 2004 16:18:56 -0400
X-Message-Number: 39
>So assuming it keeps going east, you'll loose touch with
>Chicago and only saturate the network (wides) from Grand
>Rapids MI to New York city at altitude.
Each time I have flown a long-distance solar Montgolfier, the issue of
"saturating the network" has come up. The last time it seemed as though
the argument centered around the use of RELAY in the path (yes, I did
that!) - so this time the RELAY has been removed above 3km.
Out of curiosity (and because I personally haven't a clue), I ask the same
question that I posed after my last flight:
Apart from sheer speculation and textbook-style calculations of the network
being inundated by packets from my evil balloon, is it possible to collect
empirical *data* about the damage, if any, that is being done (one would
have to imagine, right at this very moment!) to the network by my use of a
WIDE,WIDE path?
That is, I understand (I think) most of the arguments about why this is a
potential problem - but is the reality anywhere close to the prediction?
Backing up a bit from that question, is it even *possible* to analyze the
impact of my balloon's packets on the overall network (perhaps on a regional
basis) in real-time or otherwise?
If there is no quantitative way of doing this, then can it at least be
approached from a qualitative standpoint - is anyone seeing apparent
degradation of the APRS network as a result of these packets? Not just
"yes, a lot more packets are on the network" - but actual degradation of
service?
The last time I asked this question there were no replies - zip, zero, nada
(at least that made it into my mailbox). Having now gotten rid of the RELAY
problem (thanks Scott!), I didn't expect to ever pose the question again...
But now it seems that even a single WIDE is considered questionable.
Anyone, anyone?? =)
Robert
KC8UCH
----------------------------------------------------------------------
Subject: Re: Solar tetroon Sky Diamond 6 aloft right now!
From: Steve Dimse <k4hg@tapr.org>
Date: Thu, 3 Jun 2004 16:34:11 -0400
X-Message-Number: 40
On 6/3/04 at 1:14 PM Curt, WE7U <archer@eskimo.com> sent:
>On Thu, 3 Jun 2004, Steve Dimse wrote:
>
>>No, it is not doing that. It is sending the opentrack packets into the APRS
>IS.
>>This is what an IGate is supposed to do, however the problem is the opentrack
>>format packets can look like valid APRS packets, or take unplanned routes
>>through the parsing tree causing crashes.
>
>Ok. Who's doing that?
By now you have the partial list of "offenders" I sent in a previous message.
>The OpenTrac binary packets are not supposed
>to be sent through. OpenTrac packets converted to APRS packets
>aren't supposed to be sent through either now, but might be still by
>some slightly older Xastir clients.
Who says TNC's are supposed to filter on PID? Certainly the AX-25 spec says
what PID an AX-25 packet should have when it is transmitted, but does it
say that a TNC must not pass any other PID packets out the serial port? I
don't have my copy of the AX-25 spec handy, but I'd be surprised if it said
that...correct me if I'm wrong.
It is true that the PID on the packet is different from AX-25, but as we
clearly see here, many TNCs are sending them through the serial port
anyway. The thing is, who says a TNC should ignore PIDs other than AX-25?
The idealists might say it is obvious, but obviously not, as many TNCs are
indeed passing them, it wasn't obvious to the TNC code programmers. The
text format that the TNC's communicate to the software does not have a PID
field, so there is no way for the client program to apply filtering, even
if one wanted to. The textual representation of some of these packets has
the appearance of valid APRS format packets, and therefore they cannot be
filtered or ignored at the IGate, hub, or client.
>The intent for the OpenTrac packets was to go through a separate
>internet network. I believe that is still correct.
Yet here there are, in large numbers, placing garbage in the data for the
balloon. This was exactly the result I predicted when I said that an
incompatible protocol belonged not only on a separate internet network, but
a separate rf network as well.
>By keeping everything possible off the system you don't know how
>susceptible the system is to problem packets...
But you also run the risk of crashing key assets at critical times. If you
did this deliberately at times wwhen you knew no one in the APRS world was
facing critical situations, then I'd say OK, but to do it randomly and hope
the crash will not occur at a critical time and place sounds a bit like
Russian Roulette (allbeit with a lot more than 5 empty chambers).
Steve K4HG
----------------------------------------------------------------------
Subject: Re: Solar tetroon Sky Diamond 6 aloft right now!
From: "Scott Miller" <scott@opentrac.org>
Date: Thu, 3 Jun 2004 13:35:56 -0700
X-Message-Number: 41
>But when a large number (most?) of the APRS base stations out there are just
>TNCs dumping the raw packets to the serial port, how can they filter based
>on the PID? It's not even indicated in the strings sent by a TNC!
They're not dumping raw packets. Converse mode is SUPPOSED to give you a
mechanism to send and receive TEXT packets, i.e. those with AX.25 PID 0xF0.
I'm not sure if it's specific firmware versions or some configuration
option, but at least some Kantronics TNCs seem to print ALL packets out as
text.
Remember, a raw packet doesn't start with "KC8UCH-11>APOT01" in ASCII. It
starts with an encoded TOCALL, FROMCALL, digi list, control byte, and PID,
followed by the payload and frame check sequence.
Scott
N1VG
----------------------------------------------------------------------
Subject: Re: Solar tetroon Sky Diamond 6 aloft right now!
From: "Curt, WE7U" <archer@eskimo.com>
Date: Thu, 3 Jun 2004 13:38:27 -0700 (PDT)
X-Message-Number: 42
On Thu, 3 Jun 2004, Steve Dimse wrote:
>Apparently large numbers do not, and we now have documentation of the problem I
>hypothesized when I begged you to keep this off the APRS channel. Are you going
>to blame all the TNC manufacturers and IGate operators and continue to place
the>APRS network at risk, or are you going to take your protocol off the APRS
>frequency?
Ban the packets instead of trying to fix the problem? How about a little
ham cooperation, experimentation, and problem-solving here instead?
--
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: Thu, 3 Jun 2004 16:40:17 -0400
X-Message-Number: 43
On Thu, 3 Jun 2004 15:59:51 -0400, Steve Dimse wrote:
>On 6/3/04 at 12:33 PM Curt, WE7U <archer@eskimo.com> sent:
>>Again, are we talking the APRS packets out of his tracker, or the
>>OpenTrac packets/converted to APRS?
>>
>We are talking about opentrack packets, unconverted by anything.
>
>I've now found the problem is worse than just the status message.
>
>http://www.findu.com/cgi-bin/posit.cgi?call=kc8uch-11
I'm seeing the errors you speak of above in FINDU. Yet in APRSWORLD:
http://maps.aprsworld.net/datamart/track.phtml?call=KC8UCH-11&hours=72
I'm seeing what looks like solid data. Why do you think that is?
----------------------------------------------------------------------
Subject: Re: Solar tetroon Sky Diamond 6 aloft right now!
From: "Curt, WE7U" <archer@eskimo.com>
Date: Thu, 3 Jun 2004 13:42:22 -0700 (PDT)
X-Message-Number: 44
On Thu, 3 Jun 2004, J. Lance Cotton wrote:
>Scott Miller wrote:
>>It is most definitely incompatible with the APRS IS. It's perfectly fine on
>>air with any device that follows the minimum standards of the AX.25 spec.
>
>But when a large number (most?) of the APRS base stations out there are just
>TNCs dumping the raw packets to the serial port, how can they filter based
>on the PID? It's not even indicated in the strings sent by a TNC!
Because the protocol identifier byte is supposed to allow multiple
protocols (AX.25 and others) to co-exist on the same channel.
They're supposed to ignore packets that have the wrong PID. As I
understand it, most TNC's work that way. Let's find out which ones
don't and get the manufacturer to issue a firmware upgrade so that
they operate properly on the network.
--
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: "Christensen, Eric" <CHRISTENSENE@MAIL.ECU.EDU>
Date: Thu, 3 Jun 2004 16:44:11 -0400
X-Message-Number: 45
Well, I think it is really neat to see that the technology exists to change
the unproto path... If we can get all the data from this flight and graph
the number of hops it had to take to get into an I-Gate v. the altitude,
then we might have some very useful data to work with to answer this
question.
Got another idea... It will follow in another email.
73s,
Eric KF4OTN
kf4otn@amsat.org
----------------------------------------------------------------------
Subject: Re: Distributing the NMEA string from a gps
From: WB4GQK@aol.com
Date: Thu, 3 Jun 2004 16:45:10 EDT
X-Message-Number: 46
After reading William's request I performed a small experiment which I just
completed a few minutes ago. My boat is docked 40 feet behind my house. I
have used a 100 ft CAT 5 cable to connect between the PC on the boat which
is a Mini ITX with only a CD/DVD reader. The operating system is WinMe. I
set this system up over a year ago just so I could download programs and
updates from the Inet here in the house and install them directly into the
ITX.
I turned the ITX and Garmin on about an hour ago and then connected to this
machine in the house. This PC is running Win2000. I requested to connect to
the virtual port on the ITX and lo and behold the Garmin NMEA sentence
showed up. There is no application on my wife's machine that can display a
position but the data is available. The CAT 5 cable will not quite reach
the PC in the ham shack but I'm sure if it did it would display on WinAPRS.
The conclusion simply is that Lantronix Redirector does share the GPS data
over a simple network. What a neat little experiment specially when it
works!
Jim
----------------------------------------------------------------------
Read previous mail | Read next mail
| |
