| |
ZL3AI > APRDIG 02.03.03 10:02l 217 Lines 9072 Bytes #999 (0) @ WW
BID : 966-ZL3AI
Read: GUEST
Subj: TAPR Digest, Feb 27, 4/8
Path: DB0FHN<DB0RGB<DB0FSG<DB0GAP<DB0KFB<DB0CZ<DB0GE<LX0PAC<DB0NDK<DB0ACH<
DB0ACC<DB0GOS<ON0AR<ON0AR<WB0TAX<N1UAN<ZL2BAU<ZL3VML
Sent: 030301/0847Z @:ZL3VML.#80.NZL.OC #:60712 [Chch-NZ] FBB7.00i $:966-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
Subject: RE: TXD (Final answer?)
From: radio_q@juno.com
Date: Thu, 27 Feb 2003 07:40:03 -0700
X-Message-Number: 25
On Thu, 27 Feb 2003 09:31:48 -0500 (EST) Bob Bruninga <bruninga@usna.edu>
writes:
>Yep, i Guess Im thinking of a D7 transmitting, so the only unknown is
>the lockup time of the KPC-3 type open squelch TNC, since the
>digipeater receiver is already on freq and squelch is open...
>
>Bob
There is one other unknown and that is the response time of the AGC
to settle down and not distort the leading edge.
In your application, that is position dependent as the signal strength to
the receiver depends on your D7 location.
C U
Jim K5QQ
----------------------------------------------------------------------
Subject: Re: Item-by-Item-RX N.F. [was: Holy Grail of APRS Network Performance
From: "Tim Cunningham" <tim_cunningham@mindspring.com>
Date: Thu, 27 Feb 2003 08:46:00 -0600
X-Message-Number: 26
APRS+SA has a PHG scaling factor that allows the user adjust the range
from the PHG into a percentage of the actual size. Thus, you can tailor
the PHG information to a more realistic circle based on how the actual
packet data performs within reason. This does not account for those who
pre-adjust their PHG information to make the circles look more accurate.
Those circles will be scaled down along with the others. So why play with
the PHG numbers on the transmitting end to make it look correct. Enter
the values correctly for consistency and let the end user software scale it
to their liking, accepting that the circles are always bigger than the actual
performance of a 1200 baud packet using FM.
We all know that 1200 baud FM packet takes a lot more ERP than the
PHG circles suggest for the packet to be decoded. Accept it for its reality.
My point is that some of the software authors have made provisions for the
users to scale the PHG circle to a more realistic view. It does nothing to
solve for the flat earth problem and that can only be done with software
that takes into account the surrounding terrain. The transmitting station
cannot solve that issue since it cannot account for every listener. Thus,
the intelligence is required on the receiving end. The scaling factor seems
to be a simple start to bring the PHG information into perspective.
There are numerous directions to take on the issue, but one must
understand the original purpose of the system they are using. Of course
it could be better, but does it need to be better and for what purpose?
Does that purpose fit into the mission of APRS as we know it?
Tim - N8DEU
Huntsville, Alabama
----------------------------------------------------------------------
Subject: Re: Handling 100 3-min trackers
From: Robert Kirk <isobar@cablespeed.com>
Date: Thu, 27 Feb 2003 11:32:52 -0500
X-Message-Number: 27
At 09:54 PM 2/26/03 -0500, Bob Bruninga wrote:
>I was asked how I would handle 100 3-min trackers in a 3 digi event:
[...]
Sounds like an interesting application, Bob. assuming it's not just
theoretical, who's got these 100 trackers to use in an event?
Bob Kirk
N3OZB
----------------------------------------------------------------------
Subject: RE: TXD (Final answer?)
From: <BobDonnell@arkalmus.com>
Date: Thu, 27 Feb 2003 10:01:46 -0800
X-Message-Number: 28
Hi Bob,
If you're really looking for a high performance situation, the D7 isn't
the way to go, in any event. A MIC-E or TinyTrak connected to
(probably) a crystal-controlled, or dual-PLL data radio would be less
expensive on a per-unit basis. And with any PLL radio where the radio
has to re-lock between RX and TX, the timing is going to be variable,
due to alignment of the radio, component tolerances, possible power
supply considerations, and the random phase of the signals arriving at
the phase detector at the time the command to transmit occurs. You've
probably heard of the transmitter signature analysis tools - they end up
measuring the results of some of the above variables. Another effect
that we discovered in about 1987 is that the lockup time of the PLL can
be significantly affected by the presence of modulation audio during the
time that the PLL is trying to achieve lock. It's the primary reason
that AEA added a command called AUDELAY to those TNCs that were capable
of controlling when TX audio was generated, vs. when the PTT circuit was
activated. All because the IC-2AT's PLL lockup was sloppy in the
presence of modulation. So unless there's a way to assure consistency,
a lot of radios will have to by analyzed before you can determine a
TXDELAY that'll work for 99+% of any particular model of radio, every
time they key up.
----------------------------------------------------------------------
Subject: RE: TXD (Final answer?)
From: <BobDonnell@arkalmus.com>
Date: Thu, 27 Feb 2003 10:17:31 -0800
X-Message-Number: 29
Hi Jim, and all,
On a properly designed FM rig, there should be insignificant delay due
to AGC characteristics, since FM receivers usually employ hard limiting
and saturated amplifiers to achieve a constant RF level at the
discriminator. This wouldn't be true of many HF packet designs, where
SSB receivers are normally employed, and the FM characteristics are only
experienced by the demodulator. There are surely other level-sensitive
areas in an FM packet system design, including any AGC action that the
modem's demodulator might employ to compensate for variable audio levels
from the discriminator or audio output from the receiver, as well as
variations in the capabilities of different demodulator chips and
implementations used by the various manufacturers. The audio
characteristics of the receiver (de-emphasis and level) will also have a
very measurable effect.
And some TNCs have different DCD detection speeds, i.e. how fast the
data clock regeneration loop synchronizes on the edges from the flags at
the beginning of the packet, and once done, how quickly that detection
is reported to the HDLC decoding hardware or software. If I recall
correctly, the late Kantronics TNC's even provide the ability to tune
those parameters as part of their command suite.
73, Bob, KD7NM
----------------------------------------------------------------------
Subject: Re: More APRS weather
From: Miller Scott Contr 30SCS/FTI <Scott.Miller@vandenberg.af.mil>
Date: Thu, 27 Feb 2003 18:46:35 -0000
X-Message-Number: 30
Flexibility is my primary goal. In the base specification, I'm attempting
to provide a vocabulary for everything that APRS, BEACONet, and Firenet
currently do, plus a fair amount of new stuff.
Extensibility is built into the protocol, with thousands of message elements
reserved for future expansion or experimental use. The way it's structured,
you could add exotic stuff like spectral wave density to a new element, and
existing clients would still be able to decode the elements they know about.
Perhaps we can have some sort of central repository of Java classes to
handle new elements, operating as plug-ins to the client software.
Scott / N1VG
----------------------------------------------------------------------
Subject: Re: Item by Item-Frequency of Operation: Holy Grail of APRS Network
Performance
From: Bob Bruninga <bruninga@usna.edu>
Date: Thu, 27 Feb 2003 14:10:21 -0500 (EST)
X-Message-Number: 31
On Thu, 27 Feb 2003, Ev Tupis (W2EV) wrote:
>Bob Bruninga wrote:
>>>RF Frequency of Operation
>>Not needed on APRS on 144.39
>
>So you are making the decision that the APRS folks on 30-meters have no need to
>reach "the Holy Grail", then. It sounds like an "obsoleting" philosophy. Is
>that your intent with the APRS service?
Good point. But again, I am looking to a 1 byte addition to the PHG that
every fixed station uses on 144.39. And I do not want to encumber the
simplicity and backwards compatibilty of PHG on 144.39 with every possible
need for DX and HF work which is a separate issue..
I am open to a separate discussion of a suitable similar construct for DX
on HF, but because it is not immediately an issue, and such a small
subset, it unfortunately is not something I have time to address right
now. But I am open to your proposals if you want to develop such a
string... that will work in APRS...
Thanks.
GOod point
Bob
----------------------------------------------------------------------
Subject: Re: Item by Item-Modulation Scheme [was: Holy Grail of APRS Network
Performance
From: Bob Bruninga <bruninga@usna.edu>
Date: Thu, 27 Feb 2003 14:16:25 -0500 (EST)
X-Message-Number: 32
Again, I am not trying to solve all possible and future propogation issues
of APRS by adding this one byte to the existing PHG... I agree, there are
lots of bytes of data we can add to every packet to convey such info,
but it is not needed 99.999% of the time on 144.39 which is my current
issue.
On Thu, 27 Feb 2003, Ev Tupis (W2EV) wrote:
>>>Modulation Scheme (AX.25, PSK31, etc.) and bandwidth
Bob wrote: Not needed on APRS on 144.39
----------------------------------------------------------------------
Read previous mail | Read next mail
| |
