| |
ZL3AI > APRDIG 14.02.04 13:10l 227 Lines 9285 Bytes #999 (0) @ WW
BID : 2842-ZL3AI
Read: GUEST
Subj: TAPR Digest, Feb 12, 3/5
Path: DB0FHN<DB0RGB<DB0MRW<OK0PPL<DB0RES<ON0AR<7M3TJZ<JE7YGF<LU6DTS<ZL2TZE<
ZL3VML
Sent: 040214/1035Z @:ZL3VML.#80.NZL.OC #:19087 [Chch-NZ] FBB7.00i $:2842-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
Subject: Re: question about 'timestamping' with IGATEd trafficto APRS-IS
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Thu, 12 Feb 2004 11:55:25 -0500
X-Message-Number: 18
Bob :
>Back in 1995, we changed APRS to remove PC time stamps from all packets
>unless explicitly required. All data is to be time-stmped on receipt.
Curt asked:
>>... Are these assumptions in the spec? I don't recall seeing
>>them there, but I haven't delved deeply into it lately either.
No and again that is one of the problems. APRSdos always saved LOG files
with the RECEIVED time stamp. I never guessed that other authors would do
differently...
Unfortunately, some authors simply save all packets raw in their LOG files
just like they come off the air. This leads to total confusion, since
there is no TIME information. And on REPLAY or review or (heaven forbid)
RETRANSMISSION, it undermines the integrity of APRS by being incomplete and
ambiguous data.
I consider it fundamental that all LOG files have to save the
time-of-receipt and that these files then cannot be retransmnitted in their
as-saved format.
de WB4APR
----------------------------------------------------------------------
Subject: APRS Time stamps
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Thu, 12 Feb 2004 12:20:47 -0500
X-Message-Number: 19
I just added this document to my APRS errata page. It clarifies the basis
of time stamps, but it does not offer any answers as to how to make them
work in the APRS-IS. But it does correct some missconcceptions.
Bob
APRS TIME STAMPS 12 Feb 2004
----------------------------------------------------------------------
WB4APR
APRS originally had time stamps in many formats, but the total lack of
consistency in PC clocks made on-air interpretation of received data
ambiguous and full of errors. To solve this, in 1995, we changed all
default position reports to NOT have time-stamps on transmission but for
all software to add time stamps on receipt.
RECEIVED TIME STAMPS: By assigning time stamps on receipt, then all
packets heard are then self-consistent to the recepients system and do give
a live presentation of the data.
ASSUMPTIONS: APRS is a real-time tactical communications system. Data
moves at nearly the speed of light and so all data seen on RF MUST be
assumed to be LIVE, or the best available data at that instant. As soon
as the packet leaves the RF environment, a TIME STAMP must then and forever
more be associated with that packet.
LOG FILES: Thus all LOG files of ANY APRS packets must contain a RECEIVED
time stamp so that this association with TIME is not lost on receipt. Note,
some software saves RAW packets and no time stamps. This is NOT GOOD. Not
only is the temporal nature of the entire log lost, but the file can then
be reloaded or exchanged and the recepient has no clue of the difference
between LIVE or OLD data. The only time an APRS packet can exist without a
time stamp is when it is LIVE and on RF.
TX TIME-STAMPS: Conversly, if anyone does use an APRS format that does
include a time stamp, then that time stamp must be honored as the time that
that data was valid, regardles of time of receipt.
APRS INTERNET SYSTEM: Now the APRS INTERNET system has a problem. It also
assumed that all packets are LIVE and so all IGates simply forwarded on
LIVE packets and the time of receipt was the time of arrival at the other
end of the APRS-IS. This then introduces many seconds or even ten's of
seconds of delays. This cannot be solved by time-stamping on receipt by
every IGate, becasue we have learned that we cannot trust individual PC
times.
APRS-IS TIME: I have no answer to this APRS-IS problem. GOod luck. But I
think it must all boil back to basics, and that is that at the instant that
a packet leaves RF, that is when the time must be stamped for that
particuolar copy of that particular packet, and that association must
remain for all uses of that packet data...
----------------------------------------------------------------------
Subject: Re: question about 'timestamping' with IGATEd traffic to APRS-IS
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Thu, 12 Feb 2004 12:31:10 -0500
X-Message-Number: 20
>>>"Curt, WE7U" <archer@eskimo.com> 2/12/04 12:04:17 PM >>>
One of the things that Scott has mentioned before has my interest: The
capability of portable stations to store up a bunch of positions, then
blast them all at once to the incident command post when an RF path is
found between them.
REPLY: This is an Excellent application, but it MUST THEN REFORMAT those
packets into one of the TIME STAMPED formats. This is fundamental to APRS,
that any data the instant it leaves RF must be permanently assigned a time
stamp.
If a time stamp is not IMMEDIATELY applied, then that data must be
discarded as useless and dangerous to the integrity of APRS. APRSdos has
always simply converted all position packets no matter what, to the "@"
time-stamped format on receipt, so that all further processing always has a
consistent time stamp, and can be parsed the same way.
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....
de WB4APR
----------------------------------------------------------------------
Subject: Re: question about 'timestamping' with IGATEd traffic to APRS-IS
From: "Curt, WE7U" <archer@eskimo.com>
Date: Thu, 12 Feb 2004 09:42:39 -0800 (PST)
X-Message-Number: 21
On Thu, 12 Feb 2004, Robert Bruninga wrote:
>>>>"Curt, WE7U" <archer@eskimo.com> 2/12/04 12:04:17 PM >>>
>
>One of the things that Scott has mentioned before has my interest: The
>capability
>of portable stations to store up a bunch of positions, then blast them
>all at once to the incident command post when an RF path is found
>between them.
>
>REPLY: This is an Excellent application, but it MUST THEN REFORMAT
>those packets into one of the TIME STAMPED formats. This is fundamental
>to APRS, that any data the instant it leaves RF must be permanently
>assigned a time stamp.
Ah, but OpenTrack ain't APRS! He'd probably have to add timestamps, or one
timestamp for the initial packet and then the delay to the next and
succeeding packets (whatever is most efficient). That's up to Scott.
--
Curt, WE7U archer at eskimo dot com
Arlington, WA, USA 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!"
----------------------------------------------------------------------
Subject: IC3SAT R.F. XMIT hang up problem
From: "ROBERT M KING" <krm6@msn.com>
Date: Thu, 12 Feb 2004 09:55:03 -0800
X-Message-Number: 22
I am using an old IC3SAT handi for a tracker on 223.480 here in the Seattle
area.
The old handi is a good rig . But early serial numbers had a xmit hang-up
problem. If you keyed it it would stay transmitting and not go back to
receive. ICOM had a fix for the problem and would do the fix if you
returned it to them.
Does anybody remember the problem and know what the fix was?
Thanks
Bob King
K7OFT
krm6@msn.com
----------------------------------------------------------------------
Subject: Re: question about 'timestamping' with IGATEd trafficto APRS-IS
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Thu, 12 Feb 2004 13:04:51 -0500
X-Message-Number: 23
>>>>"Curt, WE7U" <archer@eskimo.com> 2/12/04 12:04:17 PM >>>
>
>One of the things that Scott has mentioned before has my interest: The
>capability of portable stations to store up a bunch of positions, then
>blast them all at once to the incident command post... [later]...
Ah, but OpenTrack ain't APRS! He'd probably have to add timestamps,
REPLY: Ah, I missinterpreted. I thought you were implying that
it had your interest and so you were adding it to Xastir... Thus my
response of caution... to be sure to include timestamps. Bob
----------------------------------------------------------------------
Subject: Re: question about 'timestamping' with IGATEd trafficto APRS-IS
From: "Curt, WE7U" <archer@eskimo.com>
Date: Thu, 12 Feb 2004 10:14:10 -0800 (PST)
X-Message-Number: 24
On Thu, 12 Feb 2004, Robert Bruninga wrote:
>>>>>"Curt, WE7U" <archer@eskimo.com> 2/12/04 12:04:17 PM >>>
>>
>Ah, but OpenTrack ain't APRS! He'd probably have to add timestamps,
>
>REPLY: Ah, I missinterpreted. I thought you were implying that
>it had your interest and so you were adding it to Xastir... Thus my
>response of caution... to be sure to include timestamps. Bob
Not yet, but some of the other timestamp subjects brought up today
may require minor changes to Xastir long-term.
--
Curt, WE7U archer at eskimo dot com
Arlington, WA, USA 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
| |
