| |
ZL3AI > APRDIG 02.03.03 10:22l 270 Lines 10192 Bytes #999 (0) @ WW
BID : 967-ZL3AI
Read: GUEST
Subj: TAPR Digest, Feb 27, 5/8
Path: DB0FHN<DB0RGB<OK0PPL<OK0PAD<OK0PCC<OM0PBC<HA5OB<HA3PG<7M3TJZ<ON0AR<
WB0TAX<N1UAN<ZL2BAU<ZL3VML
Sent: 030301/0850Z @:ZL3VML.#80.NZL.OC #:60713 [Chch-NZ] FBB7.00i $:967-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
Subject: Re: Item by Item-Power Output at Antenna: Holy Grail of APRS Network
Performance
From: Bob Bruninga <bruninga@usna.edu>
Date: Thu, 27 Feb 2003 14:18:54 -0500 (EST)
X-Message-Number: 33
On Thu, 27 Feb 2003, Ev Tupis (W2EV) wrote:
>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.
WHen I say "transmitter" power, I mean power transmitted. I assumed
everyone would subtract cable loss... I could care less about how much
power someone is throwing away in their coax.
Bob
----------------------------------------------------------------------
Subject: Re: Item-by-Item-Antenna Stuff [was: Holy Grail of APRS Network
Performance
From: Bob Bruninga <bruninga@usna.edu>
Date: Thu, 27 Feb 2003 14:21:04 -0500 (EST)
X-Message-Number: 34
The only thing that matters is HAAT.
If someone has a negative HAAT and operates an HT in his basement on a
rubber duck, I could care less about his propogation on 144.39.
Bob
----------------------------------------------------------------------
Subject: Re: Item-by-Item-RX N.F. [was: Holy Grail of APRS Network Performance
From: Bob Bruninga <bruninga@usna.edu>
Date: Thu, 27 Feb 2003 14:26:37 -0500 (EST)
X-Message-Number: 35
On Thu, 27 Feb 2003, Ev Tupis (W2EV) wrote:
>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.
Anyone with common sense can look out the window on the 4 sides of his
house and knowing where his house is in his neighborhood, can estimate a
reasonable HAAT to within a few dB. I stand by my claim that adding a
noise figure parameter into EVERY fixed APRS position packet on 144.39 is
meaningless for routine operations. Its the TNC performance and audio
levels that varies receive performance by 20 dB!
Bob
----------------------------------------------------------------------
Subject: Re: Item-by-Item-RX-side issues [was: Holy Grail of APRS Network
Performance
From: Bob Bruninga <bruninga@usna.edu>
Date: Thu, 27 Feb 2003 14:30:36 -0500 (EST)
X-Message-Number: 36
On Thu, 27 Feb 2003, Ev Tupis (W2EV) wrote:
>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.
Useless on 144.39 which is the only thing I am addressing in this
discussion.
>
>>>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).
Every IGate these days is supposed to add its callsign into the path of
the packet. Look up his PHG on findu. You have all you need right
there...
>>>>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)
Absolutely not. I am making a conscious decision to not add 15 bytes of
overhead to EVERY APRS fixed station packet on 144.39 for the 0.001%
applicaiton you are addressing...
Bob
----------------------------------------------------------------------
Subject: Re: In conclusion [was: Holy Grail of APRS Network Performance
From: Bob Bruninga <bruninga@usna.edu>
Date: Thu, 27 Feb 2003 14:37:47 -0500 (EST)
X-Message-Number: 37
Thu, 27 Feb 2003, Ev Tupis (W2EV) wrote:
>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.
Sorry Ed, my proposal to add one byte to PHG will gain us orders of
magnitude improvement in ROUTINE operations and real-time network
reliability assessment on 144.39. Your proposal to add 12 bytes of data
to every packet for assessing DX propogation of packets on clear,
uncongested channel have miniscule payback advantages on 144.39.
>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)
Yes, but not by adding 10% of overhead to every fixed station packet
transmitted on 144.39 and which is not backwards compatible with existing
code. I welcome your formats for DX applications where the added
overhead is small compared to the value gained.
Bob
----------------------------------------------------------------------
Subject: Re: The unstated truth is... [was: Holy Grail of APRS Network
Performance
From: Bob Bruninga <bruninga@usna.edu>
Date: Thu, 27 Feb 2003 14:45:28 -0500 (EST)
X-Message-Number: 38
On Thu, 27 Feb 2003, Ev Tupis (W2EV) wrote:
>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?
An ALTNET is a 6 byte TOCALL for APRS packets that everyone in a
specialty net ALL can use on 144.39 and then they ALL see each other and
no one else, and no one else sees them.
BEACONnet (at least as of the last time we had this argument) does not use
a common unique ALTNET call for eveyone. In contrast everyone on beacon
net uses his own personal individual unique ALTNET. So if you have 10
Beaconnet users, you have ten ALTNETS and each altnet has one person on it
and he can only see himmself and no one sees him...
Thus, it is not an APRS compatible use of ALTNETS as defined in the APRS
spec..
So yes, a KENWOOD can set an ALTNET to one particular person, but then
that is the ONLY person he can hear. Think of ALTNETs as a "GROUP CALL".
Everyone in that group uses that call..
Bob
----------------------------------------------------------------------
Subject: RE: TXD (Final answer?)
From: Bob Bruninga <bruninga@usna.edu>
Date: Thu, 27 Feb 2003 14:49:32 -0500 (EST)
X-Message-Number: 39
On Thu, 27 Feb 2003 radio_q@juno.com wrote:
>There is one other unknown and that is the response time of the AGC
>to settle down and not distort the leading edge.
FM receivers have no AGC.
----------------------------------------------------------------------
Subject: Re: Holy Grail of APRS Network Performance
From: Mike Musick <mikemusick@earthlink.net>
Date: Thu, 27 Feb 2003 14:06:39 -0600
X-Message-Number: 40
The concept is laudable, Bob. However:
>Anything I missed?
Yep. Quite a bit, actually.
>addition of one byte
Nitpick - you're adding two - 'r', and the '/'. In the user world,
very few posits go out with nothing after PHG.
>This proposal is 100% backwards compatible:
No, it's not. I've already tested it and know that it will break my parser
- PHG will be extracted, but any following data is now crunched. The
problem is that we are suddenly taking a field which has been spec'ed as
fixed-length for almost a decade and re-declaring it variable length, with
protocol determined by an identifier *after* the data.
>Where r is the integer rate of PHGR packets XMTD in packets per hour
So what is the range of 'r'? 0-9? 0-F (hexadecimal)? Base 92? Logarithmic
(just kidding... please, no...)? None of the single-character expressions
have enough range to cover rates used in practice, which are from < 1 per
hour to the 120 per hour network-cloggers to variable-rate "smart" mobiles.
In addition, this purpose of this breaks down immediately for stations
which vary UI path, such as wide-coverage digis. It is common practice to
have short (local) paths on a frequent rate, with decreasing rates for
progressively longer paths. While you can specify the beacon rate that
relates to each specific beacon and its path, somebody's accuracy is
skunked - if you 'r' for the longest path, the local measurement is wrong,
if you 'r' for the shortest path, anybody who evaluates the DX reception
will get an impression of extreme path loss.
>All existing software on
>receive should still receive the "PHGabcd" with no impact, since no
>following character was ever specified.
Again, no. Check the spec for the DF protocol. Its position depended
on the preceding data item - either PHG or speed/heading - being 7
characters, including specification for seven spaces of padding or '
/ ' if neither PHG or speed/heading were available.
There's a lot more work to be done here. First, we need to get away from
the temptation to create another parsing paradox just because it "looks
elegant". Second, there are position-dependent data elements which in fact
follow the existing PHG. Third, there needs to be enough dynamic range to
cover reality. Finally, the variable path and variable rate issues needs to
be specifically addressed beyond creating another exception or special
case.
...mike
----------------------------------------------------------------------
Read previous mail | Read next mail
| |
