| |
ZL3AI > APRDIG 14.02.04 13:12l 98 Lines 3586 Bytes #999 (0) @ WW
BID : 2844-ZL3AI
Read: GUEST
Subj: TAPR Digest, Feb 12, 5/5
Path: DB0FHN<DB0RGB<DB0MRW<OK0PPL<DB0RES<ON0AR<7M3TJZ<JE7YGF<LU6DTS<ZL2TZE<
ZL3VML
Sent: 040214/1054Z @:ZL3VML.#80.NZL.OC #:19090 [Chch-NZ] FBB7.00i $:2844-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
Subject: Re: question about 'timestamping' with IGATEd traffic to APRS-IS
From: Steve Dimse <k4hg@tapr.org>
Date: Thu, 12 Feb 2004 18:13:31 -0500
X-Message-Number: 32
On 2/12/04 at 12:31 PM Robert Bruninga <bruninga@usna.edu> sent:
>Some early APRS clones simply save packets in their raw form. This is
>very dangerous
>unless there is a system that also permanently saves a time stamp with
>them....
No Bob, it is only dangerous if you keep the raw packets AND use their
timestamps. If W9XYZ knows his timestamp is good, and wants to grab data
off findU or another APRS allication and use the timestamp with his own
application, he can do that. Otherwise, a client that ignores timestamps
and uses time received, as most clients do, is not more dangerous than
yours that converts it with a local timestamp.
Steve K4HG
----------------------------------------------------------------------
Subject: Re: question about 'timestamping' with IGATEd trafficto APRS-IS
From: "Bill Diaz" <william.diaz@comcast.net>
Date: Thu, 12 Feb 2004 17:27:56 -0600
X-Message-Number: 33
Bob,
We still see legacy applications converting Mic-E packets and inserting
timestamps. Some are flat wrong. These converted packets are all too
common on the IS.
Another problem is the use of local time in some objects. Impossible to
determine the timezone / actual time in some cases. I would like to see
local time stamps eliminated. If UTC was universally used, the client
applications could make any necessary conversions to local time.
Bill KC9XG
----------------------------------------------------------------------
Subject: Re: question about 'timestamping' with IGATEd traffic to APRS-IS
From: "Scott Miller" <scott@opentrac.org>
Date: Thu, 12 Feb 2004 15:38:52 -0800
X-Message-Number: 34
>This way, with a single user-def format you could implement all the APRS
>protocol, it would be relatively simple for clients to include in their
>programs, and would not cause any difficulty with all the other formats. It
also
>provides an unambiguous timestamp, unlike present APRS timestamps (of course
>there would be a Y2.1K problem, but do we really need to worry?...If so, add
>another 2 bytes and put it off to the year 10,000 AD!)
I think at this point the discussion probably belongs on the opentrac-spec
list. At least there we've still got a chance of doing something useful
with it. The spec already has an unambiguous timestamp element - it's six
bytes including the header and gives time to the second out to the year
2106. Like any other element, it can be added to any message... no need to
deal with non-standard user-defined formats that don't mean anything to
anyone else.
After seeing what's happened to timestamps in APRS, I think the spec will
have to be very specific about when the use of a timestamp is appropriate.
Scott
N1VG
----------------------------------------------------------------------
Subject: Re: TRACE in the FLOOD parameter???
From: Earl Needham <needhame1@yucca.net>
Date: Thu, 12 Feb 2004 17:39:38 -0700
X-Message-Number: 35
At 07:16 AM 2/9/2004, Robert Bruninga wrote:
>Sounds like your local digi has set UIFLOOD to TRACE instead
>of UITRACE to TRACE... Bob
Yeah, I thought so, too, but didn't know who to mention it to. This was in
the Dallas, Texas area, near the intersection of I-45 and I-30.
7 3
Earl
Earl Needham, KD5XB, Clovis, New Mexico DM84jk
KD5XB-2>APW251,PCSAT-1%:=3425.83N/10313.55W-PHG7150/WinAPRS 2.5.1
-EARL_CLOVIS -251-<630>
SETI@Home: 11364WU/7.37yrs
---
END OF DIGEST
Read previous mail | Read next mail
| |
