| |
ZL3AI > APRDIG 02.03.03 10:21l 266 Lines 10137 Bytes #999 (0) @ WW
BID : 968-ZL3AI
Read: GUEST
Subj: TAPR Digest, Feb 27, 6/8
Path: DB0FHN<DB0RGB<OK0PPL<OK0PAD<OK0PCC<OM0PBC<HA5OB<HA3PG<7M3TJZ<ON0AR<
WB0TAX<N1UAN<ZL2BAU<ZL3VML
Sent: 030301/0855Z @:ZL3VML.#80.NZL.OC #:60714 [Chch-NZ] FBB7.00i $:968-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: "Ronald Reams" <wa4mjf@worldnet.att.net>
Date: Thu, 27 Feb 2003 15:50:49 -0500
X-Message-Number: 41
Why not say ERP?
73 de Ronnie
----- Original Message -----
From: "Bob Bruninga" <bruninga@usna.edu>
To: "TAPR APRS Special Interest Group" <aprssig@lists.tapr.org>
Cc: "TAPR APRS Special Interest Group" <aprssig@lists.tapr.org>
Sent: Thursday, February 27, 2003 14:18
Subject: [aprssig] Re: Item by Item-Power Output at Antenna: Holy Grail of
APRS Network Performance
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: Holy Grail of APRS Network Performance
From: Bob Bruninga <bruninga@usna.edu>
Date: Thu, 27 Feb 2003 16:26:56 -0500 (EST)
X-Message-Number: 42
Mike raised some excellent points about the PHGR concept. ANd I will
adjust the PHGR SPEC accordingly. Good feedback. Fortunately, almost all
of them are the result of attempting to use PHGR for applications that
were never part of the intent of PHGR in the first place. So we just need
to make sure people understand PHGR and use it for its intended purpose.
See detail comments:
On Thu, 27 Feb 2003, Mike Musick wrote about the PHGR idea:
>The concept is laudable, Bob. However:
>
>Nitpick - you're adding two - 'r', and the '/'. In the user world,
>very few posits go out with nothing after PHG.
But all have some kind of delimeter, so its a no-cost byte. Im just
finally nailing down that delimiter to make it easier to recognize...
>>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.... [right shifted one byte]
Good point. But the only field after PHG is a variable length
free-text comment field. Thus, the only impact is that for those stations
that send PHGR, that their comment text gets a "/" added to the front of
the post-parsed comment. No big problem...
>So what is the range of 'r'? 0-9? 0-F (hexadecimal)? Base 92? 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.
Mobiles never use PHG. PHGR is only designed to be used by fixed stations
in locations where we want to measure network performance. The range of r
is 1 to 9. With r=0 meaning a null entry to be ignored.
>In addition, this purpose of this breaks down immediately for
>stations which vary UI path, such as wide-coverage digis.... [with
>variable rates and paths]...
Yes, Such variable path digis should not use PHGR. PHGR is for measuring
user network reliability from "intended typical user stations" in the
"intended area of coverage"...Besides, Network reliability as we are
trying to analyze with this byte has hardly anything to do with the
success of a digipeater.... eveyone can hear it. So I never intended it
to be for digis... although it could be useful for small short range
fill-in digis to assess their reliability...
But good point, I need to make sure people understand that PHGR is NOT a
replacement for PHG in the concept by spelling it out tht this should not
be used for any station with variable paths and should only be used for
stations situated for properly using it for its intended purpose.
>>All existing software on receive should still receive the "PHGabcd"
>>with no impact, since no following character was never 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.
PHGR is not intended for use with a DF station sending DF bearings.
Thanks. We will note that exclusion if it was not obvious...
>Second, there are position-dependent data elements which in fact follow
>the existing PHG.
Yep, thanks. I think I addressed all of them above. If there are more,
let me know..
>Third, there needs to be enough dynamic range to cover reality.
No. Rememmber the intent of this PHGR, and dont try to apply it to every
station on the air. Reality is that no fixed station in routine
operations for which this whole network-reliability idea is trying to
measure would fit into the category of "intended typical user" if he was
sending more than 6 packets per hour nor sending less than 1. The NET
cycle time of APRS for direct communications is 10 minutes (6 per hour).
For regional coverage it is 30 minuets (2 per hour). If someone is
sending less than one packet per hour, then his data is meningless in
"real-time" assessment of channel reliability...
>Finally, the variable path and variable rate issues needs to be
>specifically addressed beyond creating another exception or special
>case.
Good points all. We must make sure that people understand the specific
purpose of PHGR and use it that way and not abuse it. Ill clarify those
understandings in the draft PHGR SPEC.
Thanks!
Bob
----------------------------------------------------------------------
Subject: PHGR refinements
From: Bob Bruninga <bruninga@usna.edu>
Date: Thu, 27 Feb 2003 16:53:52 -0500 (EST)
X-Message-Number: 43
Here is the text I added to the PHGR idea to make sure everyone
understands that it has an intended purpose and should be used for thta
intended purpose and does not make sense to attempt to apply it elsewhere:
EXCEPTIONS:
1) If a PHGR packet is sent out of its normal schedule (for example, in
response to a QUERY), then the "R" byte is stuffed with a "0" to show that
it is an unscheduled PHGR packet and should not be used...
2) It is very important that EVEYONE understand the purpose of PHGR is
for measuring network reliability from a "typical intended user" at
a "particular location in an intended area of coverage" and that by that
definition, it should not be applied to non typical user stations such as:
* Digipeaters (we can all hear them anyway...)
* Digipeaters or ANY station with variable rates or paths
* Moving stations,
* any stations beaconing more often than once every 6 minutes
* any stations beaconing less often than once every hour
* any DF station sending a DF report
3) If you want to measure a mobile over an area, then you dont need PHGR!
Simply set a fixed rate, drive around, and count your own hits.
Hope that clears it up...
Bob, Wb4APR
----------------------------------------------------------------------
Subject: PHGR summary
From: Bob Bruninga <bruninga@usna.edu>
Date: Thu, 27 Feb 2003 18:08:52 -0500 (EST)
X-Message-Number: 44
I am aware that I am talking out both sides of my mouth...
Telling Ev that we can't add all the bytes of propogation data to PHG
beacuse it will add overhead to every fixed station packet and telling
Mike, that PHGR is not for every situation.
So I am just searching here for the right way to add this one byte of TX
rate data for this need. And there has been good feedback. Still adding
"R/" to PHG works perfectly with APRSdos and the Kenwoods because we both
always defined the first byte after the PHG to be assumed to be a
delimiter and so when "PHG1234R/testing" is transmitted, both APRSdos and
Kenwoods display:
Transmitted: PHG12345/testing <== meaning PHG1234 and 5 pkts/hr
-------------------- ----------------
Received as:
-------------------- ----------------
APRSdos PHG: PHG1234
APRSdos Comment text: /testing
Kenwood D7 & D700: PHG1234
Kenwood Comment text: /testing
PocketAPRS: PHG1234
PocketAPRS comment: 5/testing
Which actually is kinda neat beacuse when you konw what that looks like,
you can easlily tell that this station is transmitting PHGR at 5 packets
per hour...
Any other unusual effects?
Bob
----------------------------------------------------------------------
Subject: Re: APRS and snow depth reporting?
From: Wolf Hoeller <wolf.hoeller@gmx.net>
Date: Fri, 28 Feb 2003 00:23:16 +0100
X-Message-Number: 45
Am Donnerstag, 27. Februar 2003 06:01 schrieben Sie:
On Donnerstag, 27. Februar 2003 06:01 you wrote:
>>Does APRS have any support for snow depth reporting? Does
>>anyone use APRS for such things? Does anyone WANT to?
>>What about other weather phenomena besides the standard
>>weather and storm reports? I'm a bit weak on this
>>topic, seeing as I live in an area that doesn't actually HAVE
>>any weather.
>>
>The APRS spec does include a parameter for inches of snow in the
>last 24 hours, but AFAIK no one supports it, findU certainly
>does not, it is not even on my do list, as no one has asked for
>it.
>
>Steve K4HG
>
Hi Steve and Others!
We are running a complete weatherstation here in the Tyrol - in the heart
of the european Alps - one of hundrets of similar stations for
disasterprevention (summer and winter). But it is really funny - I thought
by my self to bring some of the collected data into the aprs-network! One
of the data is the snowdepth in the range from 0 - 5.5m, measured with a
ultrasonic sounder.
It could be interresting to compare data from the Antarctic (KE6JAB-1 and
-2) and from the European Alps (OE7XVR) - perhaps direct in findU ... !?
--
73 de Wolf, oe7ftj
ax25-mail: oe7ftj@oe7xlr.#oe7.aut.eu
email: oe7ftj(at)gmx.at
Have a look where I am:
http://www.findu.com/cgi-bin/find.cgi?oe7ftj%2A
----------------------------------------------------------------------
Read previous mail | Read next mail
| |
