| |
ZL3AI > APRDIG 12.01.04 13:53l 248 Lines 9659 Bytes #999 (0) @ WW
BID : 2624-ZL3AI
Read: GUEST
Subj: TAPR Digest, Jan 08, 1/2
Path: DB0FHN<DB0RGB<OK0PPL<DB0RES<ON0AR<ZL2BAU<ZL2BAU<ZL3VML
Sent: 040112/1115Z @:ZL3VML.#80.NZL.OC #:16725 [Chch-NZ] FBB7.00i $:2624-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
TAPR APRS Special Interest Group Digest for Thursday, January 08, 2004.
1. Re: Deadreckoning
2. APRS and ISS SatGates
3. Re: 571Mph wind?
4. Re: 571Mph wind?
5. Re: Topo Map Opinions Needed
6. Re: APRS and Skywarn
7. PayPal to AMSAT for APRS
8. Re: 571Mph wind?
9. Unable to locate station, any help?
10. APRS Sketch of Global Connectivity
11. Re: APRS and ISS SatGates
12. Feb Circuit Cellar
13. RE: Any way to limit range of rcvd stations using internet
14. Vicinity tracking without GPS
15. Epoxy for coating circuit cards
16. Re: Vicinity tracking without GPS
----------------------------------------------------------------------
Subject: Re: Deadreckoning
From: Bob Bruninga <bruninga@usna.edu>
Date: Wed, 7 Jan 2004 23:50:47 -0500 (EST)
X-Message-Number: 1
On Thu, 8 Jan 2004, dale huguley wrote:
>I am opposed to dead reckoning objects derived from NWS bulletins.
>There is a fundamental difference between plotting an object as
>accurately as possible with a course and speed where the NWS says it is,
>not where dead-reckoning places it.
Wow, many comments race to mind:
1) I think this missunderstands the concept and PROPER display of a
dead-reckoned position in APRS. The exact reported position always
remains on the map at exactly that point. It NEVER moves and is always
retained at its LAST REPORTED position.
DeadReckoning is only a local display function that indicates the AGE of
that plot by drawing some kind of probability indication of the probable
movement of the object based on its known course and speed at that time
with VISUAL reference to the ACTUAL EXACT reported position.. There is no
way the display should be interpreted as an estimated repositioning of the
object. If it does, then the client program has not properly displayed
DeadReckoning.
>[with DRing], you are putting the software authors in the
>forecasting business. I see liability problems with this.
Only if they implement it incorrectly so that it is missleading. Which
was the purpose of my post, to see if client programs are doing it right
now or not.
2) Whether or not an object is dead reckoned is up to the SENDER. If he
wants it deadreckoned, then he includes a CSE/SPD field. If not, he
doesnt. If he still wants to include the info but not have it dead
reckoned, then he should put the speed and direction elsewhere in the
comment field.
But conversly, we cannot have ambiguity in how RECEIVING APRS clients
display the data. We must have consistency in the rpesentation of objects
and stations at the end user, or we dont have a system that has any value
or meaning or consistency or reliablilty at conveying intended information
from the sender to ALL receivers.
So it is your choice as the sender of the data as to wheter it moves or
not by whether you include the CSE/SPD fields or not. If they are there,
then in APRS, it SHOULD show a dead-reckoned indication on receiving
stations after passage of time without having received any updates.
>>Here is some Old stuff I'm trying to clear out of the "issues" folder:
>>------------------------------------------------------------------------
>>Someone said:
>>
>>
>>>Personally, I think this is a bad idea. For instance, a thunderstorm
>>>object generated by Dale's wx server could end up over 500 miles away
>>>24 hours later.
>>>
>>>
>>
>>Which is where it should be if it continued to move at 20 MPH in the
>>given direction (which most do) (though they dont last 24 Hours and
>>should have been killed by then if they dont)...
>>
>>
>Objects generated by wxsvr are killed at the expiration time- no
>guarantee the kill would be received.
>
>>>If the software author wants an object created by their software to
>>>dead reckon, they should put that option in their software. I don't
>>>think it should be the receiver's responsibility to try to determine
>>>what the object's creator's intent was.
>>>
>>>
>>
>>They DO so indicate by including a CSE and SPEED and time stamp in the
>>OBJECT. There is no ambiguity here at all.
>>
>>
>I abandoned the normal timestamps 2 years ago- wxsvr objects had 3
>timestamps in a single packet. The time in the "normal" position is the
>expiration time. Dead reckoning on that will give you an erroneous
>position. (Golly- that works to my advantage doesn't it ;-) )
ah, but it violates the APRS spec! Wow, I had no idea you were doing that
(though I see how it is a loophole). But if I view that packet in
accordance with the APRS SPEC, I can only interpret that object as a
FUTURE ESTIMATED position at that FUTURE time.
This is a problem...
The solution is not to munge up APRS as you appear to be doing, but to fix
the errant clients that do not display it properly...
Keep up the good work, though, I konw you are only trying to help the WX
users...
de WB4APR, Bob
----------------------------------------------------------------------
Subject: APRS and ISS SatGates
From: Bob Bruninga <bruninga@usna.edu>
Date: Wed, 7 Jan 2004 23:55:36 -0500 (EST)
X-Message-Number: 2
Downlink SatGates feeding SATELLITE packet
downlinks live into the global APRS system:
I checked pcsat.aprs.org and www.ariss.org and see the following active
IGATES for the last several hours:
on 145.825 (PCsat): EA8CAC,ON7EQ-12,DF5FF-10
on 145.800 (ISS ): KE0VN-3,KB2M-5,KB9ZWL-3,N0AN,N1BHX,WA6LIE-3,
ON7EQ-12,PD0SBH-5,PE5YES,PP5UF-1,G4DPZ,VE6CNO,
ZL1AMW-14,ZL2UCX,ZL2UMF-9
on 437.1 (Sapphire): none seen today.
On the PCsat page you will see a large number of additional SATGATES, but
this is missleading, because it includes packets from PCSAT-11. These
PCSAT-11 packets are only 1 telemetry packet a minute that is transmitted
down over the USA on the normal terrestrail APRS frequency. Anyone in the
country has the probability of hearing that packet between local QRM and
so this list can contain ANY IGATE that was operating APRS at the time
while logged onto the internet. Here is a list for what it is worth of
the three western passes over the USA:
On 144.39 (PCsat over USA): These IGates are only incidental (see above)
N. USA/CANADA: AH6GR,KD7BCS,KC7DBA,KK6RW,WB8SKP,VE6BCA,W0BIS-1,KD7BCS
NW USA/CANADA: WC9AAG,WB8SKP,N9QIP,VE3XZT,AC7TK,KE0VN,KK6RW
W7NTF,N1VG,KD7BCS,K6TPK-7,WH6SJ,AH6GR
W. USA/CANADA: AA5ED-10,K0STL,KE2LJ-8,N0ESC-1,N0RGA-15,N0QBH-4,N1VG,
N6TBQ-3,N9QIP,NS8E,WC9AAG,w9da,VE7PTW
----------------------------------------------------------------------
Subject: Re: 571Mph wind?
From: "Neil Lauritsen" <neil-w4nhl@verizon.net>
Date: Thu, 8 Jan 2004 00:10:58 -0500
X-Message-Number: 3
These unusual high wind speeds are usually seen because RF gets into the WX
station hardware. It is not a software problem.
Neil, W4NHL
----------------------------------------------------------------------
Subject: Re: 571Mph wind?
From: Steve Dimse <k4hg@tapr.org>
Date: Thu, 8 Jan 2004 00:30:30 -0500
X-Message-Number: 4
On 1/8/04 at 12:10 AM Neil Lauritsen <neil-w4nhl@verizon.net> sent:
>These unusual high wind speeds are usually seen because RF gets into the WX
>station hardware. It is not a software problem.
Not in this case. As I posted, the weather data from this station is
improperly formatted, having dropped the leading zeros that are required by
the APRS spec. The fact that all the packets from this station contain this
error indicates it is a programming error, not an rf problem:
http://www.findu.com/cgi-bin/errorlist.cgi?call=W2WSF&last=999
findU, for example, uses a strict parser, and if a weather packet does not
lead off with the required 3 digit wind speed and direction separated by a
slash, then it throws the packet out as an error.
Other software may not be so strict, and may try to parse out data from an
incorrectly formatted packet. What happens depends on how the parser is
written, and what the error in the packet. In this case with just the
missing leading zeros, it would be possible to guess what the programmer
meant if your method for parsing out the value was to look for two values,
consisting of one or more digits, separated by a slash. However, another
method for parsing the data is to take characters 1-3 and 5-7 and convert
by bytes to a number, then this will fail.
Garbage in, garbage out!
Steve K4HG
----------------------------------------------------------------------
Subject: Re: Topo Map Opinions Needed
From: Curt Mills <archer@eskimo.com>
Date: Wed, 7 Jan 2004 21:29:05 -0800 (PST)
X-Message-Number: 5
On Tue, 6 Jan 2004, Vince wrote:
>Three questions - does the mouse pointer show lat/lon, are roads shown
>on the maps, and how small can I resolve terrain height (e.g. can I see
>the height of my street)? One or more of these questions may seem dumb,
>but I'm still learning here :)
>
>If you know of a free, on-line source of topo maps that would be helpful
>too.
Xastir has had access to free online topo maps for several years
now. Xastir runs on several operating systems.
http://www.xastir.org
Click ont the "Features" link to see what the current list of map
types is, and what operating systems we run on.
Xastir is free under the GPL license, including source code. It can
show dd.dddd, dd mm.mm, dd mm ss, UTM, UTM w/special zones, and MGRS
coordinates for the mouse pointer.
--
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!"
----------------------------------------------------------------------
Read previous mail | Read next mail
| |
