| |
ZL3AI > APRDIG 02.04.03 10:42l 244 Lines 9572 Bytes #999 (0) @ WW
BID : 1091-ZL3AI
Read: GUEST
Subj: TAPR Digest, Mar 27, 5/6
Path: DB0FHN<DB0RGB<OK0PPL<RZ6HXA<SP7MGD<IK6PYS<VK7AX<ZL2BAU<ZL3VML
Sent: 030401/0907Z @:ZL3VML.#80.NZL.OC #:63029 [Chch-NZ] FBB7.00i $:1091-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
Subject: Re: [ Alex ] Re: Digipeating and fun with PIDs
From: Henk de Groot <henk.de.groot@hetnet.nl>
Date: Thu, 27 Mar 2003 23:18:25 +0100
X-Message-Number: 25
At 11:53 27-3-03 -0500, Jeff King wrote:
>Not withstanding, what is being discussed is the ratified APRS spec and the
>inability of some organizations to conform to it (for whatever reason) which
>potentially can cause problems.
In the case of using a different PID I wonder if we are chaseing
nonexistant ghosts. I'm pritty sure nearly all (if nor all) APRS clients
handle the PID correctly. Those using the TNC in terminal mode will never
see the packets with a different PID (so its handled even if the author
doesn't realise it) and those that use KISS *know* that the PID exists and
check on it to avoid problems with NetROM and TCP/IP datagram packets.
Realy, we can continue this discussion but I have yet to see one existing
real-life APRS application that indeed has a PID problem. Up to now its has
been FUD and not a real problem.
Kind regards,
Henk.
----------------------------------------------------------------------
Subject: Re: APRS development?
From: "Peter \"Dakota\" Summerhawk" <wymarine@toughguy.net>
Date: Thu, 27 Mar 2003 15:44:34 -0700
X-Message-Number: 26
Heck any computer system can be made to crash, even my 3.11 system can be
made to crash if the right programs are run. Talking from a system admin
standpoint here.
Peter
----------------------------------------------------------------------
Subject: Re: [ Alex ] Re: Digipeating and fun with PIDs
From: "Curt Mills, WE7U" <hacker@tc.fluke.com>
Date: Thu, 27 Mar 2003 15:15:13 -0800 (PST)
X-Message-Number: 27
On Thu, 27 Mar 2003, Henk de Groot wrote:
>Realy, we can continue this discussion but I have yet to see one existing
>real-life APRS application that indeed has a PID problem. Up to now its has
>been FUD and not a real problem.
Here's a real-life example of the right way to do it within Xastir's
interface.c:process_ax25_packet() function:
if(*bp != (unsigned char)0xF0)
return(NULL); /* check the the PID */
We drop packets at that point that don't have a 0xf0 PID, early in
the packet decoding process. I believe the network and AX.25 kernel
networking interfaces use this function. I'll have to check whether
the Serial KISS interfaces use it.
--
Curt Mills, WE7U hacker_NO_SPAM_@tc.fluke.com
Senior Methods Engineer/SysAdmin
"Lotto: A tax on people who are bad at math!"
"Windows: Microsoft's tax on computer illiterates!" -- WE7U
"The world DOES revolve around me: I picked the coordinate system!"
----------------------------------------------------------------------
Subject: Re: [ Alex ] Re: Digipeating and fun with PIDs
From: Curt Mills <hacker@tc.fluke.com>
Date: Thu, 27 Mar 2003 15:37:04 -0800 (PST)
X-Message-Number: 28
On Thu, 27 Mar 2003, Curt Mills, WE7U wrote:
>We drop packets at that point that don't have a 0xf0 PID, early in
>the packet decoding process. I believe the network and AX.25 kernel
>networking interfaces use this function. I'll have to check whether
>the Serial KISS interfaces use it.
A good thing to check. Serial KISS interface packets take a different path
through our code, which has now been tweaked to only allow packets that
meet the Control=0x03, PID=0x0f restrictions. Thanks for making me take
another look at it!
--
Curt Mills, WE7U hacker_NO_SPAM_@tc.fluke.com
Senior Methods Engineer/SysAdmin
"Lotto: A tax on people who are bad at math!"
"Windows: Microsoft's tax on computer illiterates!" -- WE7U
"The world DOES revolve around me: I picked the coordinate system!"
----------------------------------------------------------------------
Subject: my packets on findu.com
From: Matthew Werner <mwerner@duluth.com>
Date: Thu, 27 Mar 2003 20:42:23 -0600
X-Message-Number: 29
I've noticed that my packets that are on Findu.com are being incorrectly
decoded. My home station (KB0KQA) is showing up as Course: 48.0 Speed: 12.7.
The packet is compressed (I'm running X-Astir). This is the packet:
Raw packet: KB0KQA>APX114,K0NDX-10*,WIDE3-3,qAR,W0TVD-10:=/6d9@70,8x{-
Cmwerner@duluth.com
My mobile shows the same type of thing. The truck is not moving, and hasn't
moved since about 1200 CT, yet shows Course: 198.0 Speed: 41.0. The packet is
compressed (using a TinyTrak3). This is the packet:
Raw packet: KB0KQA-4>TV5Y6V,RELAY*,WIDE2-1,qAR,W0TVD-10:`x-xp+~k/"8S}
Why do the packets show up incorrectly in findu? Is this a problem with the
equipment on my end, or on the findu end? I notice on aprsworld.net that the
home station has ??? in the speed and course field, while the mobile station
says it is moving 198 degrees at a speed of 46 (different speed than findu).
What's right and where's the problem?
Thanks and 73 - Matt
----------------------------------------------------------------------
Subject: RE: my packets on findu.com
From: "AE5PL Lists" <HamLists@ametx.com>
Date: Thu, 27 Mar 2003 21:29:05 -0600
X-Message-Number: 30
javAPRS translates as:
Position:
=
KB0KQA>APX114,K0NDX-10*,WIDE3-2,qAR,W0TVD-10:=/6d9@70,8x{-Cmwerner@dulu=
th.com
KB0KQA 46 59.64'N 92 17.94'W Range=5mi mwerner@duluth.com
And
Position:
KB0KQA-4>TV5Y6V,RELAY*,WIDE2-1,qAR,W0TVD-10:`x-xl!Nk/"8o}
KB0KQA-4 46 59.66'N 92 17.91'W course 150=B0 speed 0 MPH alt 1483' =
"8o}
The first is compressed format, the second is Mic-E.
For the Mic-E decoding, make sure that both are reporting in the same
units (Mic-E is in knots but most convert to MPH). Also, there can be
different rounding errors.
As for compressed format, if no adjustment is made for the { in the c
position (see spec), it could be interpreted as a course/speed.
Hope this helps.
73,
Pete Loveall AE5PL
pete@ae5pl.net
----------------------------------------------------------------------
Subject: Re: my packets on findu.com
From: Steve Dimse <k4hg@tapr.org>
Date: Thu, 27 Mar 2003 22:46:04 -0500
X-Message-Number: 31
On 3/27/03 at 8:42 PM mwerner@duluth.com (Matthew Werner) sent:
>I've noticed that my packets that are on Findu.com are being incorrectly
>decoded. My home station (KB0KQA) is showing up as Course: 48.0 Speed: 12.7.
>The packet is compressed (I'm running X-Astir). This is the packet:
>
>Raw packet:
KB0KQA>APX114,K0NDX-10*,WIDE3-3,qAR,W0TVD-10:=/6d9@70,8x{-Cmwerner@duluth.com
This one was a bug in findU, the { indicates the course/speed value is a radio
range, my software was not picking op this special case, should be fixed now,
looking for some data to check it now. This form seems to be quite rare, none
heard in the last 15 minutes. findU was handling the much more common forms of
base 91, (a space where the { is above for no course/speed or range, and a
course/speed), correctly.
>My mobile shows the same type of thing. The truck is not moving, and hasn't
>moved since about 1200 CT, yet shows Course: 198.0 Speed: 41.0. The packet is
>compressed (using a TinyTrak3). This is the packet:
>
>Raw packet: KB0KQA-4>TV5Y6V,RELAY*,WIDE2-1,qAR,W0TVD-10:`x-xp+~k/"8S}
>
>Why do the packets show up incorrectly in findu? Is this a problem with the
>equipment on my end, or on the findu end? I notice on aprsworld.net that the
>home station has ??? in the speed and course field, while the mobile station
>says it is moving 198 degrees at a speed of 46 (different speed than findu).
I'd have to calculate this out to be certain (and after a 12 hour shift at
work my head hurts too much to do it), but I bet it is right (the Mic-E
format is very common, and I'd expect errors like this would have been
picked up by now), probably the last report for the mobile that got through
was while you were still moving. The difference between findU and aprsworld
is probably due to findU displaying knots and aprsworld displaying MPH...
Steve K4HG
----------------------------------------------------------------------
Subject: Re: my packets on findu.com
From: James Jefferson <jjeffers@aprsworld.net>
Date: Thu, 27 Mar 2003 21:54:16 -0600
X-Message-Number: 32
On Thursday 27 March 2003 09:46 pm, Steve Dimse wrote:
>>Why do the packets show up incorrectly in findu? Is this a problem with
>>the equipment on my end, or on the findu end? I notice on aprsworld.net
>>that the home station has ??? in the speed and course field, while the
>>mobile station says it is moving 198 degrees at a speed of 46 (different
>>speed than findu).
>
>I'd have to calculate this out to be certain (and after a 12 hour shift at
>work my head hurts too much to do it), but I bet it is right (the Mic-E
>format is very common, and I'd expect errors like this would have been
>picked up by now), probably the last report for the mobile that got through
>was while you were still moving. The difference between findU and aprsworld
>is probably due to findU displaying knots and aprsworld displaying MPH...
Another possible reason that aprsworld could be different from findu is that I
convert all units to metric before putting it in the database. The result is
that the metric display usually is right, but the english display looses some
precision. It has bugged me the most of the weather display page where the
temperature is off by a degree.
I haven't been following the thread, so if there are any more issues regarding
aprsworld (incorrect / incomplete parsing?) please let me know and I'll get
them fixed.
-Jim KB0THN
----------------------------------------------------------------------
Read previous mail | Read next mail
| |
