| |
ZL3AI > APRDIG 11.01.04 12:21l 237 Lines 8498 Bytes #999 (0) @ WW
BID : 2623-ZL3AI
Read: GUEST
Subj: TAPR Digest, Jan 07, 3/3
Path: DB0FHN<DB0FOR<DB0MRW<OK0PPL<DB0RES<ON0AR<IK1ZNW<ZL2TZE<VK3TE<ZL2BAU<
ZL2BAU<ZL3VML
Sent: 040111/1005Z @:ZL3VML.#80.NZL.OC #:16651 [Chch-NZ] FBB7.00i $:2623-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
Subject: Re: INTERLNK-INTERSVR
From: "Mike Yetsko" <myetsko@insydesw.com>
Date: Wed, 7 Jan 2004 20:17:21 -0500
X-Message-Number: 17
>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
I may be wrong, but...
I thought the Interlnk and intersvr stuff was still there, but you just
have to activate it from the DOS boot prior to windows loading.
Mike
----------------------------------------------------------------------
Subject: Re: INTERLNK-INTERSVR
From: Dale Blanchard <wa7ixk@arrl.net>
Date: Wed, 07 Jan 2004 17:45:21 -0800
X-Message-Number: 18
I used it once, it was tricky for a non dos person. dont remember what I
did.
Mike Yetsko wrote:
>>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
>
>I may be wrong, but...
>
>I thought the Interlnk and intersvr stuff was still there, but you just
>have to activate it from the DOS boot prior to windows loading.
>
>Mike
----------------------------------------------------------------------
Subject: 571Mph wind?
From: "Jacob Tennant" <k8jwt@adelphia.net>
Date: Wed, 7 Jan 2004 21:38:34 -0500
X-Message-Number: 19
Sure would hate to live near W2WSF's weather station.
Jacob Tennant-K8JWT (FM09ap)
Ham Radio Page: http://users.adelphia.net/~k8jwt/index.html
----------------------------------------------------------------------
Subject: Re: 571Mph wind?
From: Steve Dimse <k4hg@tapr.org>
Date: Wed, 7 Jan 2004 21:48:47 -0500
X-Message-Number: 20
On 1/7/04 at 9:38 PM Jacob Tennant <k8jwt@adelphia.net> sent:
>Sure would hate to live near W2WSF's weather station.
>Jacob Tennant-K8JWT (FM09ap)
Undoubtably comes from improper parsing of this sort of packet:
Raw packet:
W2WSF>APU25H,qAS,N2NJH:@080228z4251.86N/07847.42W_225/5g11t16r0p0b10229h38W=
.
Seneca WX {UIV32N}
This is very much in violation of the APRS spec, the fields of a weather
packet are of fixed length with leading zeros. findU does not parse these
bad packets, which is why anyone that went scrambling for the weather page
for this call was disappointed! These packets do appear on the findU error
page though:
http://www.findu.com/cgi-bin/errors.cgi
Note that whatever client program parsed a high wind speed out of this is
equally in error!
Steve K4HG
----------------------------------------------------------------------
Subject: Re: APRS+SA v2.22 Posted
From: "Tim Cunningham" <tim_cunningham@mindspring.com>
Date: Wed, 7 Jan 2004 21:44:42 -0600
X-Message-Number: 21
>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 $15.00. APRS+SA only works with Street Atlas versions 4 through 9.
....and we just completed 226 days, 15 hours, and some odd minutes of
continuous uptime with version 2.21 running on an IBM P166 with 96MB RAM
under Windows 95B before we had to recycle the machine due to the IP lease
expiring last week... If we had thought ahead and renewed the IP lease on
the computer, it would probably have continued without recycling the
machine and renewing the lease. It is always something silly after so many
days of continuous operation.
Tim - N8DEU
Huntsville, AL
----------------------------------------------------------------------
Subject: Re: 571Mph wind?
From: Bob Bruninga <bruninga@usna.edu>
Date: Wed, 7 Jan 2004 23:08:42 -0500 (EST)
X-Message-Number: 22
On Wed, 7 Jan 2004, Jacob Tennant wrote:
>Sure would hate to live near XXXXX's weather station. [570 MPH wind]
There were so many WX errors on the air that I finally changed the default
WIND ALARM in APRSdos from 99 MPH to 999 MPH so that I didnt get woken up
in the middle of the night by someone's new WX code...
de WB4APR, Bob
----------------------------------------------------------------------
Subject: Re: Deadreckoning
From: Bob Bruninga <bruninga@usna.edu>
Date: Wed, 7 Jan 2004 23:50:47 -0500 (EST)
X-Message-Number: 23
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
---
END OF DIGEST
Read previous mail | Read next mail
| |
