| |
ZL3AI > APRDIG 07.12.03 12:00l 244 Lines 9402 Bytes #999 (0) @ WW
BID : 2433-ZL3AI
Read: GUEST
Subj: TAPR Digest, Dec 02, 3/5
Path: DB0FHN<DB0FOR<DB0SIF<DB0FHK<DB0FBB<DB0GOS<ON0AR<ON0AR<VK3TE<VK4TRS<
ZL2BAU<ZL2BAU<ZL3VML
Sent: 031207/0906Z @:ZL3VML.#80.NZL.OC #:14126 [Chch-NZ] FBB7.00i $:2433-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
Subject: Re: WX Station decode...
From: James Jefferson <jj@aprsworld.net>
Date: Tue, 2 Dec 2003 13:04:33 -0600
X-Message-Number: 13
Hi Bob - I don't know why the attacks are necessary. All I can do is prove
my points in a clear and consistant manner and go on.
>>I can probably explain this weather station. It's mine....
>>The packet meets APRS spec.... None of the Kenwoods will decode it
>>however... I didn't want to send many extra bytes of data just so the
>>broken Kenwoods would display it correctly... aprsworld.net, findu,
>>xastir, and possibly other APRS clients parse the packets correctly.
In support of my packet meeting APRS spec. Here is the output from aprsdec,
an aprs packet checker written by Ian Wade, editor of the APRS spec:
Record #1
KB0THN-2>APRS,N0BZZ-10,KC0FTN-10,K0NDX-10,TRACE3*,qAo,W0TVD-10:!
4647.04N/09042.41W_.../002g005t024#000000PIC
APRS Data Type= Posit w/o time. No APRS
Lat= 46 deg 47.04 min N Long= 90 deg 42.41 min W
Icon= WX station Overlay= (none)
Wind Direction= (Indeterminate) deg Speed= 002 knots (2.3 mph 3.7 kph 1.0
m/s)
Gust Speed= 5 mph (8.0 kph 2.2 m/s 4.3 knots)
Temp= 24 degF (-4.4 degC) Windchill= 24.1 degF (-4.4 degC)
Rain: Last hour= (Indeterminate) Last 24 hrs= (Indeterminate)
Since midnight= (Indeterminate)
>Wow, interesting comments:
>1) The kenwoods do properly decode a valid WX packet
It's a valid packet. See above. The Kenwoods don't properly decode it. See
previous post.
So your point is valid, but it is not relevant to the discussion. Your
statement holds if the Kenwoods decode a single WX packet. IE they could
decode a single Ultimeter 2k packet and nothing else. That does no good. They
need to be able to decode all all valid weather packets.
>2) The example packet is *not* in conformance with the spec in that
> it has a wind SPEED but has no direction
See above.
>3) The fact that some other clients plot an indeterminate, non-compliant
> wind vector is not necessarily a valid measure of "validity"
Valid point.
>4) Damning the vast majority of MOBILE APRS users to no weather data
> becasuse you personally dont use a mobile kenwood is not good for the
> general APRS objectives and community..
On the Kenwood D700 and D7A(G) the body of the packet will show up in the
status text. On the D700 that is the full length and is easy to parse by
hand.
If the Kenwoods accepted valid APRS weather packets it would display. This
is a problem with the Kenwoods, not with my weather station. So the Kenwood
users have the weather data and your point is invalid.
Assuming that I don't use Kenwood mobile radios is also invalid. I use my
TM-D700 continuously whenever I am in my vehicle. I have my TH-D7A(G)
sitting my desk next me. I've had both of these radios since shortly after
they came out. Only recently did I purchase my first new non-Kenwood radio.
In Winona, Minnesota I am a large advocate of the D700 and D7 and can count
almost a dozen hams that have them based on my recommendations.
BUT THAT DOESN'T MEAN THAT THE KENWOODS ARE PERFECT!
>You are sending a packet that contains a wind speed without a wind
>direction. That is inconsistent.
Perhaps that is inconsistent.
There is not provision for a wind direction sensor. How can I send an APRS
weather packet that takes that into account and is consistent?
>>The "..." indicates that no data is present. I think this is right. Bob
>>B.?
>
>Nope, not in the complete format...
Okay, how do I do it right?
>>Sometime I hope to document the weather stations better. There are
>>actually a handful of them on APRS. KB0VYO-12, KB0THN-2, K0NY-2 and a
>>few temporary test stations. KB0VYO-12 and KB0THN-2 are entirely
>>stand-alone solar powered weather stations.
>
>Wow, what great assets, why do you not intend to support mobile users of
>WX data?
I do support them. Why doesn't everybody else's APRS software follow the spec
and decode a proper packet?
One of the rules in computer science, which I am a student of, is that you
write your parsers to be forgiving and your encoders to follow the spec
exactly. This follows the spec exactly. An APRS parser that follows the
spec exactly will decode it, and a forgiving APRS parser will also decode
it.
73's,
-Jim KB0THN
----------------------------------------------------------------------
Subject: Re: aprssig ID vs NOID
From: "Cap Pennell" <cap@cruzio.com>
Date: Tue, 2 Dec 2003 11:47:16 -0800
X-Message-Number: 14
Bob WB4APR wrote:
>>SOMECALL>APTW01,DIGI1*,WIDE3-3:_11272313c060s000g000t...
>>SOMECALL>APTW01,DIGI1*,WIDE3-2:_11272313c060s000g000t...
>>SOMECALL>APTW01,DIGI1*,WIDE3-1:_11272313c060s000g000t...
>>
>>I agree that the ID function is wiping out any previous path info.
>>However I'm not sure I agree it is USEFUL path info if it doesn't tell
>>me who the other stations are. At least this way I know who I'm hearing
>>when I'm sitting between 2 or 3 WIDEs.
>
>Then I think you may not be understanding what these would look like if
>the "DIGI1" was not improperly set to ID. If it was properly set to NOID
>and the packet was initiated with the standard recommended initial hop of
>WIDE,... then you would see:
>
>SOMECALL>APTW01,DIGIA*,WIDE3-3:_11272313c060s000g000t...
>SOMECALL>APTW01,DIGIB*,WIDE3-2:_11272313c060s000g000t...
>SOMECALL>APTW01,DIGIC*,WIDE3-1:_11272313c060s000g000t...
>
>and it would be clear that the SENDER is hitting all three digis DIGIA,
>DIGIB and DIGIC direct and that this is the reason for the multiple
>packets.
<snip>
Bob, I think you must have meant:
SOMECALL>APTW01,DIGIA*,WIDE3-3:_11272313c060s000g000t...
SOMECALL>APTW01,DIGIB*,WIDE3-3:_11272313c060s000g000t...
SOMECALL>APTW01,DIGIC*,WIDE3-3:_11272313c060s000g000t...
Three digis heard DIRECT and none of the WIDE3-3 is used yet (and probably
most of it's not routinely needed).
>>When I read the TNC command docs, I saw no indication that the TNC ever
put
>>its own call sign on a digi packet unless it was a TRACE command or the
>>UIFLOOD ID parameter was enabled. The way I read the docs and what I saw
>>when watching packets seemed to confirm that if the packet came in
>>addressed to WIDE or WIDEn-n, it was repeated with an address of WIDE.
<snip>
No. UIFlood controls the WIDEn-N behavior, UIDigi controls the "callsign
substitution". As long as WIDE (and RELAY and TRACE) is set in UIDigi,
callsign substitution will occur in it's place. UITrace controls the
TRACEn-N behavior.
So, for a true WIDEn-N (worthy of the "N" overlay on the digi star) you're
looking at something like:
MYAlias NONE
Unproto APN383
UIdigi ON RELAY,WIDE,TRACE,CA (CA is for CAlifornia, YMMV)
UIDWait OFF
UIFlood WIDE,36,NOID
UITrace TRACE,36
73, Cap KE6AFE
----------------------------------------------------------------------
Subject: Re: WX Station decode...
From: Bob Bruninga <bruninga@usna.edu>
Date: Tue, 2 Dec 2003 16:43:40 -0500 (EST)
X-Message-Number: 15
On Tue, 2 Dec 2003, James Jefferson wrote:
>In support of my packet meeting APRS spec. Here is the output from
>aprsdec, an aprs packet checker written by Ian Wade, editor of the APRS
>spec:
>
>Record #1
>KB0THN-2>APRS,N0BZZ-10,KC0FTN-10,K0NDX-10,TRACE3*,qAo,W0TVD-10:!
>4647.04N/09042.41W_.../002g005t024#000000PIC
> Wind Direction= (Indeterminate) deg...
Yes, so his program is showing you where the problem is. Your wind
direction is "indeterminant".
>It's a valid packet. See above. The Kenwoods don't properly decode it. See
>previous post.
Its an indeterminant packet. The Kenwoods only decode valid packets.
See above..
>If the Kenwoods accepted valid APRS weather packets it would display.
>This is a problem with the Kenwoods, not with my weather station....
No, I say again, your packet is indeterminant. And you can not then
justifiably extrapolate that to your words of condemning the Kenwoods of
being in error.
>BUT THAT DOESN'T MEAN THAT THE KENWOODS ARE PERFECT!
Never said they were. But their inabilty to decode your indeterminant
packet is not something that should be counted against them.
>There is not provision for a wind direction sensor. How can I send an APRS
>weather packet that takes that into account and is consistent?
Well, APRS did allow for that because APRS defines 000 as indeterminant
and 360 as NORTH. THus, the correct way to send indeterminant wind
direction is with 000. At least that is the way I designed "APRS" back in
1994 time frame and it should have gotten into the spec that way.
>I do support them[kenwoods]. Why doesn't everybody else's APRS software
>follow the spec and decode a proper packet?
It does. Your packet is not "proper"...
>One of the rules in computer science, which I am a student of, is that you
>write your parsers to be forgiving and your encoders to follow the spec
>exactly. This follows the spec exactly. An APRS parser that follows the spec
>exactly will decode it, and a forgiving APRS parser will also decode it.
Nope, sorry, there should be no mention in the spec that says you can
substitute "..." for the Wind Direction field in the complete weather
format. If you want to insert an indeterminant value for wind direction,
then 000 should work. Again, I have no clue how many client programs
properly implemented it this way....
Good luck..
Bob
----------------------------------------------------------------------
Read previous mail | Read next mail
| |
