| |
ZL3AI > APRDIG 09.06.04 08:21l 754 Lines 29231 Bytes #999 (0) @ WW
BID : 3415-ZL3AI
Read: GUEST
Subj: TAPR Digest, Jun 03, 5/6
Path: DB0FHN<DB0FOR<DB0MRW<DB0WUE<DK0WUE<HA3PG<ZL2TZE<ZL3VML
Sent: 040609/0503Z @:ZL3VML.#80.NZL.OC #:25539 [Chch-NZ] FBB7.00i $:3415-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
Subject: Re: OPNTRK packets and exciting position reports from Findu RE: [apr
ssig] Re: Solar tetroon Sky Diamond 6 aloft right now!
From: Steve Dimse <k4hg@tapr.org>
Date: Thu, 3 Jun 2004 19:09:31 -0400
X-Message-Number: 89
On 6/3/04 at 3:34 PM Scott Miller <scott@opentrac.org> sent:
>I don't see how you're getting valid positions. Base91 starts at what, 33
>decimal? OpenTRAC elements are going to start with a length, which will be
>less than 33 for most element types (including position), and all of the
>basic position/altitude/course/speed elements have IDs of less than 33 that
>are going to be invalid as well.
I see plenty that are longer than 33 characters. Does your length include
the beacon text? Even if not, you'd have to assure that your part of the
packet never reaches 32. If the length does include the beacon text, then
you have more of a problem, the most common opentrack packet I see is 31
bytes long, with just a modest beacon (an email address).
Steve K4HG
----------------------------------------------------------------------
Subject: Paths again was Re: Garbled status text Re: Sola r tetroon Sky
Diamond 6 aloft right n
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Thu, 03 Jun 2004 19:18:26 -0400
X-Message-Number: 90
>>>"Rochte, Robert" <rrochte@gpacademy.org> 6/3/04 4:18:56 PM >>>
>Each time I have flown a long-distance solar Montgolfier,
>the issue of "saturating the network" has come up.
>The last time I asked this question there were no replies
Sorry Robert, this is simply not true.
As the inventor of APRS, I sent an email telling you the same thing we tell
everyone else at altitude.
1) Never use RELAY
2) only use 1 wide.
This is so throoughly documented in APRS over the last 12 years and I
distictly remember sending you an Email to that regard, that I was
surprised that this new balloon took no advantage of this advice.
It is great about your balloons. They are very welcome on APRS, but please
think of the network and the fact that the settings in such a balloon have
drastic consequences over thousands of square miles and thousands of
users...
Good luck. Keep em comming... But consider what is best for the network.
Thanks
de WB4APR, Bob
----------------------------------------------------------------------
Subject: Re: Solar tetroon Sky Diamond 6 aloft right now!
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Thu, 03 Jun 2004 19:23:48 -0400
X-Message-Number: 91
>>>"Curt, WE7U" <archer@eskimo.com> 6/3/04 4:42:22 PM >>>
>Because the protocol identifier byte is supposed to
>allow multiple protocols (AX.25 and others) to co-exist
>on the same channel.
>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.
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 a long 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...
Bob
----------------------------------------------------------------------
Subject: Re: Solar tetroon Sky Diamond 6 aloft right now!
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Thu, 03 Jun 2004 20:10:03 -0400
X-Message-Number: 92
>>>"Scott Miller" <scott@opentrac.org> 6/3/04 4:00:28 PM >>>
>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.
Sorry Scott that you have to re-learn what people who have been in packet
for the last 26 years have always known about TNC's and AX.25.
You cannot use PID's as discriminants on an AX.25 network with
come-as-you-are TNC's without all kinds of unpredictible results. This is
common knowledge.
It is also why 12 years ago when we invented APRS that we could not use
PID's then, nor plan on expecting everyone on the planet to upgrade their
TNC's so that we could use it at any conceivible time in the future.
Yes, KNOWING this, we did declare that APRS would use the F0 PID on
TRANSMIT, but that in no way implies that it can be used as a filter on
receive by every TNC on the air. We receommended that you not attempt this
on the APRS network.
Believe me, in the past 26 years of AX.25 there is an awful lot of common
knowledge out there that it is painful to have to see these things
"re-discovered" over and over and against all advice to the contrary.
The APRS infrastructure was build by thousands of volunteers in response to
their enjoyment of the APRS protocol. I think many of them welcome new
things but they dont like to see their hard work and existing system
threatened by incompatible procotols.
It was hard building the APRS network of thousands of digis, but that is
what we had to do when we started APRS, becasue at the time APRS WAS NOT
WELCOME ON ANY EXISTING AX.25 NET.
So we went off and built our own. Many might think similarly that
introducing new incompatible protocols on a dedicated network
infrastructure at the expense of existing operations might also be not
welcome.
Great balloon! Keep em coming. But please do not ignore the sound advice
about how to operate at altitude on APRS for the sake of the network and
others...
de WB4APR, Bob
----------------------------------------------------------------------
Subject: Re: Solar tetroon Sky Diamond 6 aloft right now!
From: kb2scs@optonline.net
Date: Thu, 03 Jun 2004 20:04:48 -0400
X-Message-Number: 93
Hi All
I do not know about converse mode but in KISS mode all TNC's outputs the
ctrl character and the PID character out its serial port to the connected
PC. That is why when I programmed PMmap it only accepts packets that have a
PID of ASCII 240. Which is the PID for UI packets.
In other words OPENTRACK,NOS,ROSE and Flexnet to name a few will not crash
PMmap.
PMmap will send any packet that does not contain a PID of ASCII 240 to its
bit bucket.
Let us hope we never witness the "Silence Of The Hams"
73 DE John KB2SCS
E-Mail: kb2scs@arrl.net
----------------------------------------------------------------------
Subject: RE: APRS SSID's defaults
From: "Christensen, Eric" <CHRISTENSENE@MAIL.ECU.EDU>
Date: Thu, 3 Jun 2004 20:18:48 -0400
X-Message-Number: 94
They are different in the spec...
73s,
Eric KF4OTN
kf4otn@amsat.org
-----Original Message-----
From: Robert Bruninga [mailto:bruninga@usna.edu]
The defaults for APRS SSID's have been updated on:
http://www.ew.usna.edu/~bruninga/aprs/SSIDs.txt
The OZ discussion about being able to quickly recognize HOW stations are
getting into APRS is something that is easily shown by SSID. So I have
added HF, APRStouch-tone and the Internet as shown below:
-6 is for Operations via Satellite
-7 is for TH-D7 HT's (legacy)
-8 is for maritime applications, boats, sailboats and ships
-9 is for Mobiles (legacy)
-10 is for stations operating on the internet only
-11 is for APRStouch-tone users (and the occasional Balloons)
-14 is for Truckers (legacy)
-15 is for HF
All others are for digis, and of course this list is only a recommendation
for a default in the absence of any other overriding situations. Notice I
am trying NOT to assign any SSID's to things that can easily be shown by
ICON.
I want to use SSID's to be a default means of showing the type of network
used to get into APRS... If 802.11 APRS networks actually start being used,
we may consider reserving -8 for that....
de WB4APR, Bob
----------------------------------------------------------------------
Subject: Re: Solar tetroon Sky Diamond 6 aloft right now!
From: Wes Johnston <wes@johnston.net>
Date: Thu, 03 Jun 2004 20:21:51 -0400
X-Message-Number: 95
I agree with Curt.... frames w/o F0 PID should be ignored by text mode
TNCs. Sure would be a shame to have a net/rom node crash aprs... or a file
transfer... or some TCP/IP activity.
kpc3plus manual says:
PID {ON | OFF}
default OFF
When OFF, only those packets with a protocol ID of $F0 (pure AX.25) are
displayed. When ON, all packets are displayed. Some of the information in
non-AX.25 packets (for example: TCP/IP, NET/ROM or TheNet) can cause some
computers to lock up. Net/Rom, TheNet and G8BPQ nodes have a PID of $CF,
TCP/IP uses $CC and $CD, and standard AX.25 is $F0.
MONITOR {ON | OFF}
default ON
When ON, unconnected packets will be monitored unless prohibited by SUPLIST,
BUDLIST, CONLIST, or LLIST. This will also allow monitoring of other packets if
permitted by the other monitor commands. The MONITOR command acts as a
master switch for the MALL, MCOM, MCON, MRESP, and MRPT commands. The
addresses in the packet are displayed along with the data portion of the
packet.
Callsigns (to and from fields) are separated by a ">"; and the Secondary
Station
Identifier (SSID) is displayed if it is other than 0. If any data is
contained in the
monitored packet which does not follow the AX.25 protocol, it is displayed in
curly braces on the header line. All monitor functions are disabled in the
Transparent Mode.
I think the curley braces are the problem... looks like all kpc3 tnc owners
need to audit their PID commands. I'm not sure about the others.... Since
AGWPE ends up using KISS mode, it will be up to the client software to
filter on PID.
Wes
----------------------------------------------------------------------
Subject: Balloon and Aircraft Paths
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Thu, 03 Jun 2004 20:31:44 -0400
X-Message-Number: 96
>>>"Rochte, Robert" <rrochte@gpacademy.org> 6/3/04 4:18:56 PM >>>
>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...
>balloon, is it possible to collect empirical *data* about the
>damage, if any, that is being done to the network by my
>use of a WIDE,WIDE path?
Well, it is common sense. At altitude, there are probably 2 thousand users
and probably 100 digipeaters that can hear it direct. And every one of
your packets is being duplicated 100 times on the first hop, and if each
DIGI hears 4 others, then as many as 400 times on the second WIDE. Thus,
lets say 500 copies of EACH of your packets.
Lets say you do this once a minute. Now normally, you would be taking up
1/60th of the channel like any other 1 minute APRS mobile and welcome just
about everywhere.
But the load because of your altitude and choice of WIDE,WIDE is taking up
that much channel capacity on EVERY LOCAL net over 160 thousand square
miles.
AND you are causing everyone of those users to contend with not just ONE
packet per minute, but as many as 5 per minute. It has been proven that
the effective throughput of an APRS network is at about 20% or so. and your
5 packets per minute are consuming almost 10% of the entire network's
capacity, or HALF of what is available to eveyrone else.
Yes, the network will survive, but you have reduced the tracking efficiency
of those other 2000 users by a good factor of 2 to only 50% of what they
would have had if you had just used only WIDE or not hops at all at
altitude.
>Apart from sheer speculation ... of the network being
>inundated by packets from my... balloon, is it possible
>to collect empirical *data* about the damage, if any...?
Well, I think that is kind of like parking your car in the middle of the
road duing rush hour and then challenging others to tell you how the 10
mile long backups you are causing actually have any impact on others...
But again, we are not saying that you broke anything. So keep up the good
work with the balloons, but just use common sense and work with us to use
the appropriate paths.
In fact, it is good to see this discussion as a reminder to any new balloon
or airplane adventurers to use the right paths. Its just too bad that we
have to learn this over and over with every new balloon that gets launched.
hi hi...
The RULE IS: At altitude where more than a few digis can hear you at the
same time:
* Use a path of only one WIDE
* And remember that you have to think about DCD and its impact on your
ability to ever transmit.
de WB4APR, Bob
----------------------------------------------------------------------
Subject: Re: Solar tetroon Sky Diamond 6 aloft right now!
From: Wes Johnston <wes@johnston.net>
Date: Thu, 03 Jun 2004 20:30:29 -0400
X-Message-Number: 97
I thought the opentracker could change modes based on altitude, temp,
voltage..... Just have it run path of WIDE WIDE when altitude is <500' ....
when >500' run no wides in path.
Wes
At 05:19 PM 6/3/2004, you wrote:
>For our mobile with its antenna 65,000 feet above the ground, we get a RLOS
>of 361 miles. The typical home station, with a antenna at 35 feet, can hear
>that mobile from a distance of 369 miles. So a home WIDE buys you 9 more
>miles.
>
>But lets look at a wide that is at 75 feet AGL. That will take you from 361
>miles range, to 373 miles. Got ya 12 there.
----------------------------------------------------------------------
Subject: Re: Solar tetroon Sky Diamond 6 aloft right now!
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Thu, 03 Jun 2004 20:41:58 -0400
X-Message-Number: 98
>>>"Scott Miller" <scott@opentrac.org> 6/3/04 6:50:51 PM >>>
>I still stand by my assertion that properly implemented
>TNCs won't have a problem...
But with dozens and dozens of TNC manufacturers over the last 26 years, IT
IS COMMON KNOWLEDGE that there is no such thing as a "properly implemented"
TNC.
Your arguments at using incompatible protocols on the APRS network and
then complaining about the damage you cause to others is their fault is
like insisting that you can run 4 way stop signs any time you want because
eveyrone else is also "supposed to" stop and so there shouldnt be any
problem...
>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?
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?
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... Three is just so much that needs to be
done...
de WB4APR, Bob
----------------------------------------------------------------------
Subject: the group...
From: "Rochte, Robert" <rrochte@gpacademy.org>
Date: Thu, 3 Jun 2004 20:35:40 -0400
X-Message-Number: 99
There's one thing I know for certain - 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
(The balloon is on its way down...)
--
Robert Rochte
Director of Technology
The Grosse Pointe Academy
171 Lake Shore Road
Grosse Pointe Farms, MI 48236
Tel. +1 313-886-1221 x155
FAX +1 313-886-1418
www.gpacademy.org
----------------------------------------------------------------------
Subject: RE: APRS SSID's defaults
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Thu, 03 Jun 2004 20:53:00 -0400
X-Message-Number: 100
>>>"Christensen, Eric" <CHRISTENSENE@MAIL.ECU.EDU> 6/3/04 8:18:48 PM
>>>
>They are different in the spec...
Yes and the SSID's in the SPEC are obsolete. That is why I updated the
errata page to keep it current with today's APRS needs. de WB4APR, Bob
----------------------------------------------------------------------
Subject: Re: Solar tetroon Sky Diamond 6 aloft right now!
From: Wes Johnston <wes@johnston.net>
Date: Thu, 03 Jun 2004 20:58:11 -0400
X-Message-Number: 101
Steve, does this mean that you invented a system and now no one else can
play unless they follow your rules? The problem as I see it is that the
existing APRS system is cobbled together with contextual clues and so it's
difficult as hell to sort out the good from the wacky packets (or even
other protocols). I understand that once a packet is in textual form, the
PID byte has been lost forever, and there is no way to filter based on that
lost information. But still, the APRS parser should realize that a given
packet does not fit the 100's of context clues and reject it.
APRS should operate like a Part 15 device... accept any interference and
keep on trucking. Where does one draw the line? What would the response
be if I suggested that we use a 'new' compressed position report and
someone said that it was not a valid APRS data type and should be on
another frequency? Of course we adopted MIC-e packets despite their issues
and they are now a part of APRS. What about specifying icons with
SSIDs? We now routinely do it with the TOCALL in ax.25... all of these
improvements were new at one time and are now commonplace in aprs.... I
think the solution is to fix the holes in the system so that bad data gets
filtered and allow new data types to not crash anything... they can either
be parsed or simply ignored. As a potential user of OT packets, I
certainly don't want to have to build a whole 'nother network... I feel
that we have a very robust (in most areas) digipeater network, and that
network needs to be available for use... Scott nailed it (I think it was
scott)... when he said that without experimentation, ham radio would be a
very very boring place. Our local ham club is dieing a slow death b/c they
have alienated all the experimenter types by thinking of the local repeater
as a "service" instead of as a "testbed". Anyone who wanted to do
something new was greeted with "We can't do _that_, it might make the
repeater unsuitable for the travellers up and down I-95!" That philosophy
has succeeded in running the club out of members. I'd hate to see that
happen to APRS.
Although this OT test probably should not have covered as much area as it
did, hey, it did accomplish something. We learned a weakness in the APRS
system and can fix it now that we are aware of it.
FWIW, all the convoluted cobbled together APRS methods are one of the
reasons Open Trac was created... a uniform data structure on the air which
will allow packets and elements of packets to be handled or skipped if the
client doesn't know how to handle them.
Hoping I don't step on any toes while trying to make my point.
Wes
----------------------------------------------------------------------
Subject: Re: Solar tetroon Sky Diamond 6 aloft right now!
From: "Scott Miller" <scott@3xf.com>
Date: Thu, 3 Jun 2004 17:59:08 -0700
X-Message-Number: 102
>I really do not see why this is such an issue. Opentrack is not APRS, it is
>clearly incompatible with APRS. It is great if some people want to create
>something new, but can't they do that without interfering with a
successful,
It is NOT incompatible with APRS. It's just not compatible with converse
mode on some TNCs.
We've got a great UI digi network in place across this country and many
others. The digis work exactly like the AX.25 spec says they should, and
they can be used for digipeating any type of UI packet. Using OpenTRAC
packets on this network causes no interference with regular APRS use, and
reduces channel load when used alone. Even when it IS encountered by
non-compliant equipment, all evidence so far indicates that it causes no
collateral damage. It's impossible to generate a valid OpenTRAC position
packet that can be properly parsed as a valid APRS packet, which means
there's no reason inadvertently gated traffic should make it past a properly
written parser. Certainly, experimentation with a new mode should take into
account good amateur operating practices, and I think we're operating well
within that mandate.
I think today's balloon adventure demonstrates this pretty clearly. We've
had hundreds of OpenTRAC packets heard by many, many stations across a wide
area, and no reports of mass client failures. In fact, I'm not aware of any
corrupted positions received anywhere but FindU. And had this not been a
publicized event, I doubt the corruption would have attracted any notice at
all.
Scott
N1VG
----------------------------------------------------------------------
Subject: Re: Modes and Frequencies
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Thu, 03 Jun 2004 21:00:18 -0400
X-Message-Number: 103
>>>"Bill Vodall" <wa7nwp@jnos.org> 6/3/04 7:04:04 PM >>>
>144.39 is not exclusively APRS any more then the
>other frequencies are exclusively non-APRS.
Really? Do the people that built the network realize that? Are such uses
welcome?
>There are times when it's reasonable to use the other
>modes on 144.39 just as there are even more uses
>for APRS on the other frequencies.
The difference in those halves of that sentence are about 100 to one. It
is ludicrous for you to make such a claim.
>Our systems have to be tolerant of all alien packets.
Yes, BUT IT IS COMMON KNOWLEDGE FOR THE LAST 26 YEARS THAT TNC's dont all
consistently implement the AX.25 protocol!
Sending packets against all recommendations to the contrary and then
telling all those that you impact that it is their problem is not being a
gentlemen in using other peoples channel...
Come on. Be a gentlemen. Dont trash everyone else and say it shouldnt
happen... WHEN EVERYONE TELLS YOU IT WONT WORK.
Please do not plan on using non APRS protocols on the national APRS
channel. It just causes problems and I dont have time to try to fix
eveyrone that comes along...
de WB4APR, Bob
----------------------------------------------------------------------
Subject: Re: Garbled status text Re: Solar tetroon Sky Diam ond 6 aloft right
now!
From: "Scott Miller" <scott@3xf.com>
Date: Thu, 3 Jun 2004 18:12:34 -0700
X-Message-Number: 104
>You are using the UNPROTO string TO OPNTRK
>Which will be ignored by all users that dont turn off
>their ALT-NET filters and of course, none of the
>Kenwoods will see them either. This will make
>finding this thing difficult...
That's a good thing. If Kenwoods are indeed broken when it comes to PIDs,
it means they won't decode OpenTRAC packets anyway.
The OpenTracker sends APRS packets with the TOCALL of APOT01. Only PID 0x77
packets go to OPNTRK.
Scott
N1VG
----------------------------------------------------------------------
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@3xf.com>
Date: Thu, 3 Jun 2004 18:10:33 -0700
X-Message-Number: 105
>I see plenty that are longer than 33 characters. Does your length include the
>beacon text? Even if not, you'd have to assure that your part of the packet
>never reaches 32. If the length does include the beacon text, then you have
more
>of a problem, the most common opentrack packet I see is 31 bytes long, with
just
>a modest beacon (an email address).
Lengths are per-element, not per-packet. A position element is either 9 or
12 bytes long, and its element ID is 16 (decimal). That means every
position, as currently defined, will start with either chr(9) chr(16) or
chr(12) chr(16). Comments have an element ID of 18. So no packets with
positions or comments can be valid APRS packets. Even if you strip all
non-printable characters - which also breaks Mic-E, remember? - the most
common element, position with no altitude, comes through as a tab character
which isn't valid in APRS.
Scott
N1VG
----------------------------------------------------------------------
Subject: Re: Solar tetroon Sky Diamond 6 aloft right now!
From: Jeff King <jeff@aerodata.net>
Date: Thu, 3 Jun 2004 21:08:21 -0400
X-Message-Number: 106
On Thu, 3 Jun 2004 15:50:51 -0700, Scott Miller wrote:
>I still stand by my assertion that properly
>implemented TNCs won't have a problem, and
Page 12 of the APRS spec it states:
from (ftp://ftp.tapr.org/aprssig/aprsspec/spec/aprs101/APRS101.pdf )
"At the link level, APRS uses the AX.25 protocol, as defined in Amateur
Packet-Radio Link-Layer Protocol (see Appendix 6 for details), utilizing
Unnumbered Information (UI) frames exclusively."
Which then references the AX.25 spec:
http://www.tapr.org/tapr/html/ax25.html
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.
My $12 TNC (a soundcard) using AGWPE behaved just fine decoding both 0xF0
PIDS as well as 0x77 PIDS.
>even those that do shouldn't cause any disruption to others.
What can go wrong, will go wrong, that is a tenant of any software developer.
It is just good engineering practice.
Scott, I don't think you owe anyone an apology for following specifications!
In APRS we have a very bad habit of excusing poor and shoddy engineering, in
the "interest of progress" or keeping certain manufacturers happy. I say just
say NO and demand excellence and that means not apologizing for others
slipshod engineering or unwillingness to follow published specifications.
Not that I have an opinion....... ;-)
----------------------------------------------------------------------
Subject: Re: Solar tetroon Sky Diamond 6 aloft right now!
From: "Scott Miller" <scott@3xf.com>
Date: Thu, 3 Jun 2004 18:30:26 -0700
X-Message-Number: 107
Which is exactly as it should be. Nice to see that someone reads (and
follows!) the specs when writing these things.
Scott
-----Original Message-----
Hi All
I do not know about converse mode but in KISS mode all TNC's
outputs the ctrl character and the PID character out its serial port
to the connected PC.
That is why when I programmed PMmap it only accepts packets that have
a PID of ASCII 240. Which is the PID for UI packets.
In other words OPENTRACK,NOS,ROSE and Flexnet to name a few will not
crash PMmap.
PMmap will send any packet that does not contain a PID of ASCII 240
to its bit bucket.
Let us hope we never witness the "Silence Of The Hams"
73 DE John KB2SCS
E-Mail: kb2scs@arrl.net
----------------------------------------------------------------------
Subject: Re: Solar tetroon Sky Diamond 6 aloft right now!
From: "Scott Miller" <scott@3xf.com>
Date: Thu, 3 Jun 2004 18:36:33 -0700
X-Message-Number: 108
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?
Scott
N1VG
-----Original Message-----
I agree with Curt.... frames w/o F0 PID should be ignored by text mode
TNCs. Sure would be a shame to have a net/rom node crash aprs... or a file
transfer... or some TCP/IP activity.
kpc3plus manual says:
PID {ON | OFF}
default OFF
When OFF, only those packets with a protocol ID of $F0 (pure AX.25) are
displayed. When ON, all packets are displayed. Some of the information in
non-AX.25 packets (for example: TCP/IP, NET/ROM or TheNet) can cause some
computers to lock up. Net/Rom, TheNet and G8BPQ nodes have a PID of $CF,
TCP/IP uses $CC and $CD, and standard AX.25 is $F0.
MONITOR {ON | OFF}
default ON
When ON, unconnected packets will be monitored unless prohibited by SUPLIST,
BUDLIST, CONLIST, or LLIST. This will also allow monitoring of other packets
if
permitted by the other monitor commands. The MONITOR command acts as a
master switch for the MALL, MCOM, MCON, MRESP, and MRPT commands. The
addresses in the packet are displayed along with the data portion of the
packet.
Callsigns (to and from fields) are separated by a ">"; and the Secondary
Station
Identifier (SSID) is displayed if it is other than 0. If any data is
contained in the
monitored packet which does not follow the AX.25 protocol, it is displayed
in
curly braces on the header line. All monitor functions are disabled in the
Transparent Mode.
I think the curley braces are the problem... looks like all kpc3 tnc owners
need to audit their PID commands. I'm not sure about the others.... Since
AGWPE ends up using KISS mode, it will be up to the client software to
filter on PID.
Wes
----------------------------------------------------------------------
Subject: Solar tetroon Sky Diamond - signal loss????
From: "Brian Riley (maillist)" <n1bq_list@wulfden.org>
Date: Thu, 03 Jun 2004 21:44:36 -0400
X-Message-Number: 109
Its 0143z and KC8UCH-11 has had no posit for over 14 minutes. The last posit
posted is a dupe of one ten minutes earlier than that. The last good posit
was
KC8UCH-11>APOT01,WIDE,WIDE,qAr,N3BSQ-1:/040129z4006.22N/07952.68WO080/070/A
=041225 06.5V-21C>RROCHTE@GPACADEMY.ORG
cheers, 73 de n1bq
----------------------------------------------------------------------
Read previous mail | Read next mail
| |
