| |
ZL3AI > APRDIG 02.03.03 09:57l 261 Lines 9503 Bytes #999 (0) @ WW
BID : 964-ZL3AI
Read: GUEST
Subj: TAPR Digest, Feb 27, 2/8
Path: DB0FHN<DB0RGB<DB0FSG<DB0GAP<DB0KFB<DB0CZ<DB0GE<DB0ZDF<DB0AIS<DB0NDK<
DB0ACH<DB0IUZ<DB0GOS<ON0AR<ON0AR<WB0TAX<N1UAN<ZL2BAU<ZL3VML
Sent: 030301/0805Z @:ZL3VML.#80.NZL.OC #:60710 [Chch-NZ] FBB7.00i $:964-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
Subject: Item by Item-Modulation Scheme [was: Holy Grail of APRS Network
Performance
From: "Ev Tupis (W2EV)" <w2ev@arrl.net>
Date: Thu, 27 Feb 2003 07:07:00 -0500
X-Message-Number: 7
Bob Bruninga wrote:
>>Modulation Scheme (AX.25, PSK31, etc.) and bandwidth
>Not needed on APRS on 144.39
>>Modulation Scheme (AX.25, PSK31, etc.) and bandwidth
>Not needed on APRS on 144.39
You are also making the decision that APRS will always be delivered using
modulation scheme that will be known to the analyzing person. This, of
course, is fine if the data is being taken from the on-air channel, and
that channel has to GATEWAY's to other services that do use different
modulation schemes and bandwidths. Unfortunately, 30m includes APRS
traffic that doesn't. This protocol ignores them again...suggesting that
you don't mind obsoleting 30m APRS operation. I'm not certain that this is
your intent, is it?
Ev, W2EV
----------------------------------------------------------------------
Subject: Item by Item-Power Output at Antenna: Holy Grail of APRS Network
Performance
From: "Ev Tupis (W2EV)" <w2ev@arrl.net>
Date: Thu, 27 Feb 2003 07:09:19 -0500
X-Message-Number: 8
Bob Bruninga wrote:
>>Power Output at the antenna
>Included in PHG
>
>> - RF output minus feeder loss
>Included in PHG
No, not that I could find, anyway. According to Page 28, "The 7-byte
PGHphgd Data Extension specifies the transmitter power, ..." This is quite
different than outlined above.
Ev, W2EV
----------------------------------------------------------------------
Subject: Item-by-Item-Antenna Stuff [was: Holy Grail of APRS Network Performance
From: "Ev Tupis (W2EV)" <w2ev@arrl.net>
Date: Thu, 27 Feb 2003 07:12:11 -0500
X-Message-Number: 9
Bob Bruninga wrote:
>>Antenna Gain (including negative)
>Included in PHG (down to 0 dB)
This is limiting to a meaningful "Holy Grail" analysis.
>>Antenna Center - Above Average Terrain
>Included in PHG
This is broken. There are stations at negative HAAT that cannot use this
scale.
>>Antenna Center - Above Sea Level
>Included in PHG
According to the APRSpec, Page 28 "The height code represents the effective
height of the antenna (italics on) above average local terrain (italics off),
not above ground or sea level..."
Ev, W2EV
----------------------------------------------------------------------
Subject: Item-by-Item-RX N.F. [was: Holy Grail of APRS Network Performance
From: "Ev Tupis (W2EV)" <w2ev@arrl.net>
Date: Thu, 27 Feb 2003 07:13:18 -0500
X-Message-Number: 10
Bob Bruninga wrote:
>>Receiver Noise Figure
>99% of APRS ops dont know, dont care, and can't measure it
The same can be said for PHG's existing HAAT parameter. I defy more than a
handfull of those that use the HAAT parameter (above) to state that they
followed the proper directions for doing so.
Ev, W2EV
----------------------------------------------------------------------
Subject: Item-by-Item-RX-side issues [was: Holy Grail of APRS Network
PerformanceFrom: "Ev Tupis (W2EV)" <w2ev@arrl.net>
Date: Thu, 27 Feb 2003 07:14:30 -0500
X-Message-Number: 11
Bob Bruninga wrote:
>>Receiver Passband
>15 KHz in the USA
Modulation bandwidth, channel spacing and receiver bandwidth are three
different issues. You appear to be referencing the second...and then only
on the East Coast of the USA. Therefore, it is unknown...yet important
information to have if analyzing a path and communication circuit.
>>RX Antenna Gain
>Same as TX, included in PHG
>>RX Antenna Center - Above Average Terrain
>Same as TX, included in PHG
>
>>RX Antenna Center - Above Sea Level
>Same as TX, included in PHG
WB4APR launches a transmission with a 1/4 wave groundplane, and findU.com
logs it. I go mining for the data for analysis. So... What was the
antenna of the station that IGated the transmission to findU? 10-element
beam? 1/2 wave vertical? Rubber duck (negative gain)? Are they on a
mountian or in the valley (negative HAAT)? No "above sea level" parameter
is found in PHG (that I could locate in my brief search, anyway).
>>DSP factors (many to note, too many to mention here)
>None worth mentioning on APRS
So you are again, making a conscious decision to lock APRS to the 1980's
model of packet radio. Which is fine... as long as you do so with "eyes
open". :o)
Ev, W2EV
----------------------------------------------------------------------
Subject: In conclusion [was: Holy Grail of APRS Network Performance
From: "Ev Tupis (W2EV)" <w2ev@arrl.net>
Date: Thu, 27 Feb 2003 07:20:54 -0500
X-Message-Number: 12
In conclusion...in the search for the Holy Grail...one is settling for a
"cup of Juicy Juice", and calling it the Holy Grail. There is
s-i-g-n-i-f-i-c-a-n-t opportunity to be had here...in designing an extended
PHG system that includes the above needs (and a couple more that I haven't
included) *without* breaking anything in existance today.
Are you interested in considering ways of including these additional
parameters without breaking the existing PHG system or is "Juicy Juice"
fine for now? :o)
Ev, W2EV
--
What's cool in Amateur Radio?
http://www.BEACONet.org or join the on-line community by
sending a blank eMail to: BEACONet-subscribe@yahoogroups.com
----------------------------------------------------------------------
Subject: DIGI_NED & BEACONet [was:Holy Grail of APRS Network Performance
From: "Ev Tupis (W2EV)" <w2ev@arrl.net>
Date: Thu, 27 Feb 2003 07:27:15 -0500
X-Message-Number: 13
Henk de Groot wrote:
>At 12:50 25-2-03 -0500, Ramon F. Kolb wrote:
>>has an inherit mechanism to indicate the number of transmissions per
>>hour (the to-call SSID is used for this).
>
>Oeps! I want to add the generic digipeating rules for BEACONet to DIGI_NED
>but this is realy killing the idea. In APRS the destination call SSIG is
>used for digipeating so I cannot have APRS and BEACONet at the same time.
>Thanks for the remark, I think I have to include a specific rule file for
>BEACONet now instead of adding it to the APRS rules...
>
>I just saw that this TX number is on originator call, but the SSID on the
>desitination call is used for an antenna pointing vector. Anyway, not
>available for digipeating...
Hi Henk,
That is correct. BEACONet does not want (nor does it need) generic
digipeating rules. We require either simplex, TRACEn-n for posit payloads
or SKIPn-N for message payloads for all of our work. Generics don't help
us at all.
Thanks for thinking of us, though! :o)
Ev, W2EV
--
What's cool in Amateur Radio?
http://www.BEACONet.org or join the on-line community by
sending a blank eMail to: BEACONet-subscribe@yahoogroups.com
----------------------------------------------------------------------
Subject: The unstated truth is... [was: Holy Grail of APRS Network Performance
From: "Ev Tupis (W2EV)" <w2ev@arrl.net>
Date: Thu, 27 Feb 2003 07:32:36 -0500
X-Message-Number: 14
Bob Bruninga wrote:
>
>On Wed, 26 Feb 2003, Henk de Groot wrote:
>
>>At 13:08 25-2-03 -0500, Bob Bruninga wrote:
>>>Yes, a great idea, but unfortunately that use of SSID is one of the two
>>>main incompatibilities between APRS and Beaconnet.
>>
>>What is the other incompatibility?
>
>Beacon Net does not use a standard APRS TOCALL. (APxxxx, CQxxxx, BEACON,
>QSTxxx, ALLxxx, or any of the other standard ones)... Thus BeaconNet
>packets are ingnored by any APRS compliant system which filters them out
>(in order to preserve ALTNETS). I had suggested that BeaconNet use
>CQxxxx but BeaconNet wanted to use all 6 bytes to carry information.
>
>THis comes home to you sometimes when you are bored with APRS and want to
>tune your mobile over to the BEaconnet frequency to listen for any DX.
>With the APRS compliant D700 and D7, you can't decode anything because of
>these two bytes.
The "thousands of Kenwoods" out there don't comply with the APRS spec on this
item either. I did a *ton* of work to conform to the CQxxxx and IDxxxx APRS
spec, only to learn that Kenwoods treat them as ALTNET's too.
Also...to correct a continuing misconception... BEACONet is *designed* to
be an ALTNET to APRS. There is nothing broken about it. Properly designed
APRS software and systems (like APRSdos and UI-View, by the way) will have
ways of turning ALTNET filtering "OFF" if they so choose, and viola`
BEACONet is now appearing on your screen. Too easy, huh?
Ev, W2EV
--
What's cool in Amateur Radio?
http://www.BEACONet.org or join the on-line community by
sending a blank eMail to: BEACONet-subscribe@yahoogroups.com
----------------------------------------------------------------------
Subject: APRS Computer - Voice Traffic Logging
From: "Robert Mahoney" <rgmahoney@ameritech.net>
Date: Thu, 27 Feb 2003 7:4:26
X-Message-Number: 15
I'm exploring the possibility of using the excess horsepower of an APRS
computer located in an EOC to record and time-stamp emergency voice
traffic. Has anyone already developed a technical solution? I'd be
interested in the results. My concept is to connect the radio's audio-out
to a sound card's line-in, have a running time-stamp, and good compression
so dead air time doesn't eat up hard drive space. For playback it'd be
nice if it were recorded in a mode so you could pick out transmissions in a
graphical representation. And most important it should play nice with the
version of APRS, which has the primary mission on the machine. Thanks.
----------------------------------------------------------------------
Read previous mail | Read next mail
| |
