| |
ZL3AI > APRDIG 11.01.04 12:07l 241 Lines 9376 Bytes #999 (0) @ WW
BID : 2622-ZL3AI
Read: GUEST
Subj: TAPR Digest, Jan 07, 2/3
Path: DB0FHN<DB0FOR<DB0MRW<OK0PKL<OK0PPL<DB0RES<ON0AR<IK1ZNW<IK6PYS<ZL2TZE<
ZL3VML
Sent: 040111/0953Z @:ZL3VML.#80.NZL.OC #:16649 [Chch-NZ] FBB7.00i $:2622-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
Subject: Re: Access restriction to software
From: Richard Garcia <k4gps@bellsouth.net>
Date: 07 Jan 2004 17:20:47 -0500
X-Message-Number: 10
But I also understood that the Gulf Waters were 3 seperate regions while
the license only provides for one, I think this was the major issue. The
Gulf waters are exactly that Gulf waters but Garmin considers it 3
different places meaning you would need to purchase 3 licenses to have
that one region.
I can also see this problem with others. I don't remember how the
regions are split but if the SE and NE are split at the State of VA what
happens to the people who live on the border of SC and VA. Again, I am
not sure of the split location this is an example. If someone lives on
or near the border I am sure day to day life takes them across the
region boundries several times every day. That really would stink!
needing to purchase 2 just because of where you live.
And yes I do remember the license stating that you could upload two
units but only of the same region.
Rich
----------------------------------------------------------------------
Subject: INTERLNK-INTERSVR
From: Bob Bruninga <bruninga@usna.edu>
Date: Wed, 7 Jan 2004 17:41:02 -0500 (EST)
X-Message-Number: 11
Is there anything built into Windows95 or 98 that is backwards compatible
with INTERLNK and INTERSVR? Old Win3.1 laptop A: died and I want to
transfer stuff to newer laptop (lazily)...
BOb
----------------------------------------------------------------------
Subject: Re: INTERLNK-INTERSVR
From: "Laurie - g6isy" <g6isy@dsl.pipex.com>
Date: Wed, 7 Jan 2004 23:07:24 -0000
X-Message-Number: 12
Bob Bruninga wrote:
>Is there anything built into Windows95 or 98 that is backwards
>compatible with INTERLNK and INTERSVR? Old Win3.1 laptop A: died and
>Iwant to transfer stuff to newer laptop (lazily)...
"Direct Cable connection" is the 95/98 built in equivalent but it is not
compatible with INTERLNK.
INTERLNK will run under win95/98 ok though.
Thread here may be useful (esp resp 12)
http://www.computing.net/windows31/wwwboard/forum/10781.html
--
73 Laurie - G6ISY
----------------------------------------------------------------------
Subject: Re: Deadreckoning
From: Bob Bruninga <bruninga@usna.edu>
Date: Wed, 7 Jan 2004 18:10:13 -0500 (EST)
X-Message-Number: 13
Revisiting Dead Reckoning:
Are we now at a state where all APRS client software properly deadreckons
moving objects (that contain a course and speed), especially WX objects?
I hope so...
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)...
>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.
>Items can't be dead reckoned because there is no timestamp. We don't
>dead reckon timestamped posits. I would suggest it would be better to
>remain consistent in our handling of position reports, regardless of
>type.
Wrong on both counts. But completely correct that both should be treated
equally. Objects contain time stamps and should always be treated
IDENTICALLY to STATIONS. There is no difference. The only difference
between an "object" and a "station" in APRS is whether the name of the
"object" is the same as the CALLSIGN of the TNC that sent it. If so, then
it is not an object but a "station"..
>The tropical storm objects have course/speed but also show where they
>are expected 12, 24, etc. hours in the future. Dead reckoning would not
>be beneficial in this case, either.
If the sender wants them to stay put on a map, then they should not have
CSE/SPD fields. OR, if the sender wants to include future CSE/SPD data,
then he needs to include the FUTURE time stamp. Receiving software cannot
DR on a future posit until it becomes "past"... Again, exactly what the
sender intended...
Bob
----------------------------------------------------------------------
Subject: Re: APRS and Skywarn
From: Dave VanHorn <dvanhorn@cedar.net>
Date: Wed, 07 Jan 2004 18:18:04 -0500
X-Message-Number: 14
At 04:08 PM 1/7/2004 -0600, Joel Black wrote:
>Would like to hear from those of you out there that are using APRS with
>their Skywarn StormSpotters. Specifically, I'd like to know:
>
> 1. Are you using dedicated trackers or through your voice repeaters?
Dedicated tracker.
> 2. If you're using dedicated trackers, what have you found that works
>consistently? What have you found that causes problems?
Don't use it on the same radio you use for voice, like the "data" side of a
tm-v7a.
Watch for desense.
Stub filters will help.
----------------------------------------------------------------------
Subject: Re: Deadreckoning
From: dale huguley <kg5qd@wxsvr.net>
Date: Thu, 08 Jan 2004 00:07:47 +0000
X-Message-Number: 15
Bob Bruninga wrote:
>Revisiting Dead Reckoning:
>
>Are we now at a state where all APRS client software properly deadreckons
>moving objects (that contain a course and speed), especially WX objects?
>I hope so...
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,
and plotting where dead-reckoning places it. In the latter case, you
are putting the software authors in the forecasting business. I
see liability problems with this. Dead reckoning also requires the
client computer to have accurate time in its operating system. Most NWS
objects have a "area of Maximum Concern" polygon that describes the area
that has a higher probability of being affected by the object during the
life of the warning - much better than dead reckoning an object that has
a mind of its own.
>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 ;-) )
73 de kg5qd Dale
----------------------------------------------------------------------
Subject: APRS+SA v2.22 Posted
From: "B. Hildebrand" <bhildebrand@earthlink.net>
Date: Wed, 7 Jan 2004 17:24:31 -0800
X-Message-Number: 16
APRS+SA v2.22 has been posted to TAPR. Several bugs have been fixed and a
few new Settings keys added. Hopefully no bugs added! Of note, the new
setup file is AprsPlusSetup222.exe and now conforms to a more standard
windows setup with keys added to the Control Panel Add/Remove programs, and
options to create Quick Launch and/or Desktop Icons. Registration fee is
now $xx.xx. APRS+SA only works with Street Atlas versions 4 through 9.
Change Log:
Current version is 2.22 in AprsPlusSetup222.exe
2004.01.04 v2.22
Installation now is standard setup process
Fixed - rare Index Error problem on several data tabs
Fixed - NWS compressed reports were not decoded if they were to simple.
Fixed - qAR not added to AEA packets. qAR was added incorrectly when using
AEA TNC.
Fixed - Entering a message sometimes created a packet without a line number
when exceeding message length limit.
APRS+SA eXtenstions are now included in basic setup, Name and callsign
lookup with Internet Connection.
New - Settings, [Config]BulletinFromCallsigns. Limit bulletins based on
callsigns, supports wildcards, i.e., A* N* K* W*
New - Settings, [Config]TelemetryFromCallsigns. As above for Bulletins.
New - Settings, [Config]WeatherFromCallsigns. As above for Bulletins.
Brent Hildebrand, KH2Z
http://www.tapr.org/~kh2z/aprsplus
ftp://ftp.tapr.org/aprssig/winstuff/aprsplus
----------------------------------------------------------------------
Read previous mail | Read next mail
| |
