| |
ZL3AI > APRDIG 06.07.04 11:02l 427 Lines 15383 Bytes #999 (0) @ WW
BID : 3550-ZL3AI
Read: GUEST
Subj: TAPR Digest, Jul 01, 1/1
Path: DB0FHN<DB0RGB<DB0MRW<DB0WUE<DK0WUE<DB0RES<ON0AR<IK1ZNW<ZL2TZE<ZL3VML
Sent: 040706/0833Z @:ZL3VML.#80.NZL.OC #:27282 [Chch-NZ] FBB7.00i $:3550-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
TAPR APRS Special Interest Group Digest for Thursday, July 01, 2004.
1. Re: Campbell Scientific CR-10 WX station
2. Re: APRS Vicinity Tracking Nationwide!
3. Fixing the APRS network (elimiinate ID digis)
4. Great Plains Super Launch this Saturday
5. PK232 in KISS
6. Re: Maps on findu from aprsworld
7. RE: PK232 in KISS
8. RE: PK232 in KISS
9. Aging of object reports
10. Re: Aging of object reports
11. Mobile and HT digital comms Experiments via ECHO
12. weather radar map files and tie points
13. Re: weather radar map files and tie points
----------------------------------------------------------------------
Subject: Re: Campbell Scientific CR-10 WX station
From: "Scott Miller" <scott@3xf.com>
Date: Wed, 30 Jun 2004 20:57:36 -0700
X-Message-Number: 1
Get me some sample data and I'll see if it's something I can tackle in the
near term. Might also help to know if it'll work without true RS-232
levels - some of the stations have trouble with that.
I've been talking to Bob off-list about the possibility of building a Peet
Bros. translator to get rid of some of the raw weather traffic and convert
it to complete format w/ position. I've got a huge stockpile of one-time
programmable PICs on hand that'd be perfect for that sort of application.
Wish I'd thought of that before I'd placed my latest order with Mouser...
could've picked up a few windowed parts for debugging. Oh well, next week.
Dallas 1-wire support in the OpenTracker is ALMOST working. For some
reason, the DS2450 A/D chip that handles the wind direction readout
sometimes fails the Search_Rom function at some random place in its address
string. Been staring at the logic analyzer for some time trying to figure
it out. Think I'm going to fire up the 'scope and see if there are any
clues in the analog realm.
Scott
N1VG
-----Original Message-----
Hi Anthony!
I am looking into the details now and putting out feelers. I am hoping to
hear some ham in this sig...say.."Yeah, I've done that...here's how"! Curt
has offered to support them in Xastir and I am knocking on Scott Miller's
door too! Probably one of the best OpenWXTRAK Wx projects I can think of.
I think that we could take APRS Wx stations up a notch or two supporting
these sorts of units. Having an interface from the CSI dataloggers to APRS
format would benefit all concerned parties....without any doubt in my mind.
I know Weather Display supports at least one CSI (Campbell Scientific, Inc)
datalogger now....just not much info about it. I'll contact them too!
I have been given a complete working station without connectivity to the
world which was used for some government experiment that has been abandoned.
It looks to be in great shape and a very professional high $$$ installation.
And, it is in an area several government agencies see as an important area.
Now I am faced with finding a solution to interface the unit and I'd really
like that interface to be APRS. Obviously, I need all the help I can get
with this.
Jim Wooddell
FireNet Coordinator
WA6OFT
----------------------------------------------------------------------
Subject: Re: APRS Vicinity Tracking Nationwide!
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Thu, 01 Jul 2004 08:32:42 -0400
X-Message-Number: 2
>my car...shows 21 miles from my location...
>This is not the fault of the vicinity tracking method, but
>rather [the "ID/NOID"] problem with our WIDEn-n setup.
>...Problem is... each subsequent [ID] digipeater keeps
>putting it's callsign in.
Exactly, and that is why we have been saying for the last 6 years that
WIDEn-N digipeaters MUST BE SET TO NOID. If they are set with UIFLOOD,
WIDE,ID, then they obliterate all prior path information and are an
abomination to the network integrity...
>The solution it seems is to use the path of
>RELAY,WIDE,WIDE1-1 so that RELAY can be sub'ed
>by the FIRST digipeater to hear my packet, and
>subsequent [ID] digipeaters [will only obliterate the
>second WIDE and not the first one...
Thatnks, that is a good interim fix, but the real fix is for all of us to
get out there and get these wrongl configured "ID" digipeaters FIXED to
NOID... These digipeaters obliterate path information and should never
have been set up that way in the first place....
Thanks for your post and observation of this problem we have been harping
on for 6 years....
>So if you want vicinity tracking to work, you have to
>put TWO callsigns infront of your WIDEn-n path
>element - or not use WIDEn-n at all.
OR FIX THE DIGIS to work PROPERLY with UIFLOOD set to NOID.
Thanks
Bob
----------------------------------------------------------------------
Subject: Fixing the APRS network (elimiinate ID digis)
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Thu, 01 Jul 2004 09:08:36 -0400
X-Message-Number: 3
>>>"Robert Bruninga" <bruninga@usna.edu> 7/1/04 8:32:42 AM >>>
>>This is not the fault of the vicinity tracking method,
>>but rather [the "ID/NOID"] problem with our [local digis].
>>...Problem is... each subsequent [ID] digipeater keeps
>>putting it's callsign in.
Actually, this might be a good way to help erradicate these
miss-configured digis. If each user who shares this concern would simply
check his vicinity posit on FINDU and if some ID-Digi is obliterating his
path data, and usurping his SOURCE digi, then it should be obvious. Then
lets get that digi changed to NOID.
To check your vicinity plot enter your call instead of steve's in this
link:
http://www.findu.com/cgi-bin/find.cgi?call=K4HG-8&vicinity=yes
Look closely at the path that your packet took. See which digi (if any) is
wrongly obliterating your path data... If the digi identified is more than
ONE HOP from you, then that digi is probably an "ID" digi that is usupring
your path....
Lets get this national APRS network fixed finally...
de WB4APR, Bob
----------------------------------------------------------------------
Subject: Great Plains Super Launch this Saturday
From: "Mark Conner" <n9xtn@cox.net>
Date: Thu, 1 Jul 2004 10:11:37 -0500
X-Message-Number: 4
A reminder - several APRS-equipped balloons are scheduled to fly from the
Hutchinson KS area on Saturday, 3 July, at 8:45 am. More at
http://www.rckara.org/project_traveler/gpsl .
73 de Mark N9XTN
----------------------------------------------------------------------
Subject: PK232 in KISS
From: "Christensen, Eric" <CHRISTENSENE@MAIL.ECU.EDU>
Date: Thu, 1 Jul 2004 11:21:05 -0400
X-Message-Number: 5
Can a PK232 modem be used in KISS? A friend is trying to do so but can't
get it to work. I do not have such a modem to try, myself. Any help is
appreciated.
73s,
Eric KF4OTN
----------------------------------------------------------------------
Subject: Re: Maps on findu from aprsworld
From: "DG2JW" <dg2jw@privateasylum.com>
Date: Thu, 1 Jul 2004 18:27:17 +0300
X-Message-Number: 6
Thanks very much for your efforts Steve.
As you know good Scandinavian maps are hard to come by, now we can enjoy
the same functionality as the more populated places.
Is this a permenant fix or temporary?
Thanks again
julian
OH8GEJ
----------------------------------------------------------------------
Subject: RE: PK232 in KISS
From: "AE5PL Lists" <HamLists@ametx.com>
Date: Thu, 1 Jul 2004 10:32:30 -0500
X-Message-Number: 7
This is the sequence I have successfully used with AGWPE:
From a cold start (PK-232 looking for autobaud), connect to the PK-232
with a terminal program such as HyperTerminal. Have the terminal
program set for 9600,7,e,1. Press the * key and you should get the
welcome text.
Enter the following commands:
AWLEN 8
PARITY 0
CONMODE TRANS
TRACE OFF
HID OFF
BEACON EVERY 0
PACKET
RAWHDLC ON
HPOLL OFF
PPERSIST ON
KISS ON
RESTART
Exit your terminal program. Set your KISS application to 9600,8,n,1 and
to send HOST ON at startup.
The above is basically from the PK-232 Technical Reference Manual (not
normally shipped with the PK-232).
73,
Pete Loveall AE5PL
mailto:pete@ae5pl.net
----------------------------------------------------------------------
Subject: RE: PK232 in KISS
From: "Christensen, Eric" <CHRISTENSENE@MAIL.ECU.EDU>
Date: Thu, 1 Jul 2004 11:41:21 -0400
X-Message-Number: 8
Thanks Pete! I'll forward this along.
73s,
Eric KF4OTN
----------------------------------------------------------------------
Subject: Aging of object reports
From: Fritz Anderson <fritza@manoverboard.org>
Date: Thu, 1 Jul 2004 10:55:22 -0500
X-Message-Number: 9
My APRS plotter for Mac OS X continues to progress (some color coding
added, dead-reckoning lines...), and a usability issue has become
apparent. Here's an example:
Just now, in Arlington, Texas (I believe -- between and a hair south of
Dallas and Fort Worth) there is a group of objects being posted for a
4th-of-July parade. There's an aid station, reviewing stands, a rally
point, and a headquarters. Since the parade (I assume) hasn't happened
yet, and the objects are re-sent periodically, I take it these are
things that should be on the map, and stay there.
However: The time stamps on these objects are 11 to 150 hours old. My
application marks objects older than 80 minutes as stale (draws them
translucent), and periodically culls objects older than a user-defined
limit that is 120 minutes by default. So the parade-related objects
appear on the map as dimmed, and then disappear in a minute or so when
my housekeeping task fires.
This isn't what the poster of the objects intended, nor what the user
of my program would want.
1. Am I right that this is, strictly, not my problem, in that the
poster of an object should be responsible for attaching a time stamp
that reflects how current it is?
2. Am I also right in suspecting that "not my problem" is not a
satisfactory answer? Whoever posted these objects with old time stamps
may have done so out of experience that existing APRS software handles
such objects as he expects. My saying that the existing software is
wrong, or at least overly lenient, does not score points for me or my
software.
3. So what is the "right" way to cull obsolete objects? Should I age
from the time-last-heard instead of the time stamp in the packet?
A minor rant on the side: It's amazing how hard it seems to be to set a
clock, even with a GPS or an NTP connection delivering atomic UTC.
Packets from the future (1 hour being a favorite, as people seem to
have gone to DST by moving GMT up). Packets from a day, a month, a year
ago/from now. Gnargh. Oh, that reminds me of something else I'd like an
opinion on:
4. What should I do with position reports from the distant future
(which I'd define as 5 minutes or more)? (I already assume local-time
reports are nearest-current-hour.) Dead-reckoning a car going 50 kts
_toward_ its reported position from 50 nm away is embarrassing. Should
I not dead-reckon such objects, or should I substitute time-received
for time-stamped?
73 de WT9T
-- F
----------------------------------------------------------------------
Subject: Re: Aging of object reports
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Thu, 01 Jul 2004 14:22:43 -0400
X-Message-Number: 10
>>>Fritz Anderson <fritza@manoverboard.org> 7/1/04 11:55:22 AM >>>
>Dallas and Fort Worth) there is a group of objects being
>posted for a 4th-of-July parade. There's an aid station,
>etc...
>However: The time stamps on these objects are 11 to
>150 hours old. [though still being transmitted]
>My application marks objects older than 80 minutes as
>stale (draws them translucent),
My concept for APRS was that "stale" applies not to their time of
origination but time of last receipt.
Obviously the sender still thinks they are important and is still sending
them. His initial posting date is useful info to you to see how long he
has been doing this. So I woiuld change your determination of "stale" to be
based on time of receipt.
>3. So what is the "right" way to cull obsolete objects?
>Should I age from the time-last-heard instead of the
>time stamp in the packet?
Yes, that is how I would like to see it done...
>4. What should I do with position reports from the distant future ..
Nothing. Do not dead-reckon them until they are in past time. Its hard to
tell why someone would put a future time, but probably that would be a way
of indicating an intended future position. Thus, it should not be DR'ed.
That's what APRSdos does. Only DR's old posits. And I hope that your DR
display to the end user does include some kind of visual clue that the
position is dead reckoned and has some kind of connection back to the
actual last reported position...
Glad to see you applying DR. It is essential to displaying moving objects
on a very low duty cycle sampled system like APRS...
thanks
Bob
----------------------------------------------------------------------
Subject: Mobile and HT digital comms Experiments via ECHO
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Thu, 01 Jul 2004 15:52:40 -0400
X-Message-Number: 11
While we work on our stations in anticipation of ECHO comissioning, those
interested in mobile or handheld live digital communications may want to
read up on how we anticipate using the digipeat mode when it may be
enabled.
http://www.ew.usna.edu/~bruninga/echoaprs.html
AMSAT considers this mode experimental so it may be only turned on on
experimental days, but anyone with a 9600 baud TNC will be able to
participate. But the real thrill will be when using the stand-alone TH-D7
HT or TM-D700 mobile radios for front-panel-to-front-panel digital
communications.
Here are the capabilities of these radio front panels to display this
information on each station that successfuly transmits a single 0.5 second
data burst via the satellite:
Callsign, GridSquare
Position, Course and Speed (on mobile stations)
Antenna Height, Gain and Power (if fixed station)
ICON (1 of almost 200)
Distance and Bearing from own station
1 of 7 possible comments (Enroute, On duty, etc...)
Status Text (20 or up to 28 characters)
Type Station: (D7, D700, FIXED, MOBILE, WX, OBJECT, etc)
User Messages and Bulletins (45 to 64 bytes long)
Station location on a GPS map (if GPS is connected)
In addition, your station sends all of these data as well. Plus you may
format a message properly so it will be converted to a standard Email for
ultimate distribution. All from your HT with only an optional GPS
attached.
Looking forward to some fun!
And don't feel excluded if you dont have the D7 or D700. Just hook your
Pal-Pilot or other hand held or laptop device to any 9600 baud TNC and join
in...
de WB4APR, Bob
----------------------------------------------------------------------
Subject: weather radar map files and tie points
From: Wes Johnston <wes@johnston.net>
Date: Thu, 01 Jul 2004 22:12:41 -0400
X-Message-Number: 12
Does anyone know the tiepoints for the CAE NWS office's doppler radar image?
Wes
----------------------------------------------------------------------
Subject: Re: weather radar map files and tie points
From: Steve Dimse <k4hg@tapr.org>
Date: Thu, 1 Jul 2004 22:26:29 -0400
X-Message-Number: 13
On 7/1/04 at 10:12 PM Wes Johnston <wes@johnston.net> sent:
>Does anyone know the tiepoints for the CAE NWS office's doppler radar image?
http://www.findu.com/geo/rad_cae.geo
Steve K4HG
---
END OF DIGEST
Read previous mail | Read next mail
| |
