| |
ZL3AI > APRDIG 14.02.04 13:10l 210 Lines 7587 Bytes #999 (0) @ WW
BID : 2843-ZL3AI
Read: GUEST
Subj: TAPR Digest, Feb 12, 4/5
Path: DB0FHN<DB0RGB<DB0MRW<OK0PPL<DB0RES<ON0AR<7M3TJZ<JE7YGF<LU6DTS<ZL2TZE<
ZL3VML
Sent: 040214/1048Z @:ZL3VML.#80.NZL.OC #:19089 [Chch-NZ] FBB7.00i $:2843-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
Subject: Re: question about 'timestamping' with IGATEd traffic to APRS-IS
From: Jeff King <jeff@aerodata.net>
Date: Thu, 12 Feb 2004 13:23:53 -0500
X-Message-Number: 25
On Thu, 12 Feb 2004 12:31:10 -0500, 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.
I've seen two APRS-IS applications step forward and say they strip time
stamps across the board, or did I mis-read them?
If I didn't, how do you get them to comply with the spec? I think TimeStamps,
in-particular for the above application, are very handy. Taking it a step
further, I heard there was someone working on a 802.11b APRS application
where they do exactly as Curt describes, when the unit comes within range of
a open AP.
Accurate time-stamps in this non-realtime application would be critical,
since what you are looking TX audio to ground. I'd try 1K or
2.2k?
Bob
----------------------------------------------------------------------
Subject: Re: Alinco DJ-S11, Tx Audio, PTT...
From: Bob <n4bk@hiwaay.net>
Date: Thu, 12 Feb 2004 13:37:47 -0600
X-Message-Number: 28
Robert Bruninga wrote:
>You must run OPEN squelch. and force the squelch open.
>Otherwise the radio goes into power-saver mode and is
>useless for packet..
>
>>>>"Rick Bolen (HM)" <rickbol@hotmail.com> 2/12/04 9:03:34 AM >>>
>
> I've tried connecting the tnc's TxAud\PTT in both orientations on the
>Tip
>and Ring of the mic jack (Sleeve is ground). One orientation allows PTT
> to
>trigger, but no audio passes thru (except for a low frequency "thump"
>at the
>conclusion of Tx).
>
>Your PTT circuit is shorting it to ground. You have to
>use a resistor to so that the PTT doesnt
>bypass all the TX audio to ground. I'd try 1K or 2.2k?
>
>Bob
Try like with a IC-2AT hook one end of a .1 uf and a 2.2K resistor
together feed the mic audio to the end of the .1 and the tx to the 2.2K.
Bob N4BK
----------------------------------------------------------------------
Subject: findU status
From: Steve Dimse <k4hg@tapr.org>
Date: Thu, 12 Feb 2004 14:39:21 -0500
X-Message-Number: 29
Been a busy afternoon, but I think most things are working on the new server.
For some reason the new dos map cgi isn't working, so the EU and world maps
on PCSat and ariss pages are not work.
I forgot to make sure that the direct entry position, namely WinLink and
email/web were up do date on the backup, and to copy them over to the new
server. Any posits from that route in the last three weeks will be lost, at
least until I get the old server back from NJ.
APRS data for the 24 hours the server was down during its trip are in the
process of being updated from the backup server, should be complete
sometime tonight, filling in the gaps in the weather charts.
Steve K4HG
----------------------------------------------------------------------
Subject: Re: APRS donations to ECHO
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Thu, 12 Feb 2004 17:45:35 -0500
X-Message-Number: 30
Three people on the APRS list contributed almost $400 for the launch of
ECHO, (our next potential APRS satellite) and one other joined AMSAT. Wow,
good work!
The word is that the Russian launch has been delayed until June, So there
is still time to contribute and show how much APRS supports the concept of
Digipeaters in space.
[commercial content deleted]
Bob, WB4APR
----------------------------------------------------------------------
Subject: Re: question about 'timestamping' with IGATEd traffic to APRS-IS
From: Steve Dimse <k4hg@tapr.org>
Date: Thu, 12 Feb 2004 18:09:19 -0500
X-Message-Number: 31
On 2/12/04 at 1:23 PM Jeff King <jeff@aerodata.net> sent:
>On Thu, 12 Feb 2004 12:31:10 -0500, 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 REFOother 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
| |
