| |
ZL3AI > APRDIG 01.03.03 09:37l 252 Lines 9205 Bytes #999 (0) @ WW
BID : 954-ZL3AI
Read: GUEST
Subj: TAPR Digest, Feb 26, 3/7
Path: DB0FHN<DB0ZWI<DB0HST<ON0DXC<WA7V<RZ6HXA<SP7MGD<IK6PYS<VK3TE<VK6HGR<
ZL2BAU<ZL3VML
Sent: 030228/1214Z @:ZL3VML.#80.NZL.OC #:60643 [Chch-NZ] FBB7.00i $:954-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
Subject: RE: OpenTAC - <LYR19806-122101-2003.02.26-00.24.51-
-ssbrockw#swbell.net@lists.tapr.org>
From: "Curt Mills, WE7U" <hacker@tc.fluke.com>
Date: Wed, 26 Feb 2003 10:29:00 -0800 (PST)
X-Message-Number: 14
On Wed, 26 Feb 2003, Miller Scott Contr 30SCS/FTI wrote:
>Someone
>mentioned the possibility of TAPR hosting the mailing list; is that still an
>option? My list manager software is very limited and doesn't have such
>niceties as a web-accessible archive.
Since it's open, you could start a SourceForge project for it,
giving you filespace, mailing lists, web-based forums, etc.
--
Curt Mills, WE7U hacker_NO_SPAM_@tc.fluke.com
Senior Methods Engineer/SysAdmin
"Lotto: A tax on people who are bad at math!"
"Windows: Microsoft's tax on computer illiterates!" -- WE7U
"The world DOES revolve around me: I picked the coordinate system!"
----------------------------------------------------------------------
Subject: APRS and snow depth reporting?
From: Miller Scott Contr 30SCS/FTI <Scott.Miller@vandenberg.af.mil>
Date: Wed, 26 Feb 2003 18:49:25 -0000
X-Message-Number: 15
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.
Scott / N1VG
----------------------------------------------------------------------
Subject: Re: APRS and snow depth reporting?
From: Steve Dimse <k4hg@tapr.org>
Date: Wed, 26 Feb 2003 14:03:56 -0500
X-Message-Number: 16
On 2/26/03 at 6:49 PM Scott.Miller@vandenberg.af.mil (Miller Scott Contr
30SCS/FTI) sent:
>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
----------------------------------------------------------------------
Subject: Re: APRS and snow depth reporting?
From: "Curt Mills, WE7U" <hacker@tc.fluke.com>
Date: Wed, 26 Feb 2003 11:09:19 -0800 (PST)
X-Message-Number: 17
On Wed, 26 Feb 2003, Steve Dimse wrote:
>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.
And the parameter for snow was the same as one of the other
parameters, so there's a conflict w.r.t. that in the APRS spec.
--
Curt Mills, WE7U hacker_NO_SPAM_@tc.fluke.com
Senior Methods Engineer/SysAdmin
"Lotto: A tax on people who are bad at math!"
"Windows: Microsoft's tax on computer illiterates!" -- WE7U
"The world DOES revolve around me: I picked the coordinate system!"
----------------------------------------------------------------------
Subject: Re: APRS and snow depth reporting?
From: Miller Scott Contr 30SCS/FTI <Scott.Miller@vandenberg.af.mil>
Date: Wed, 26 Feb 2003 19:15:51 -0000
X-Message-Number: 18
Hmmm. I'm thinking that if I DO implement a snow depth element in OpenTRAC,
it'll be separate from the primary report element. My thinking is that
people could use it for manual depth reporting (i.e., go outside and stick a
yardstick in the snow), which might be useful for reporting local conditions
in an emergency. Anyway, it should be easy to implement... a 16-bit depth
in millimeters should do it. I don't think anyone needs to report depths
greater than 65 meters...
Which reminds me, I still need to do the ocean swell report format.
Scott / N1VG
----------------------------------------------------------------------
Subject: Re: Holy Grail of APRS Network Performance
From: Bob Bruninga <bruninga@usna.edu>
Date: Wed, 26 Feb 2003 14:48:39 -0500 (EST)
X-Message-Number: 19
Ev gave some good feedback on my proposed addition of TX rate to PHG with
all the things they have included in BeaconNet. But although they are
great for general purpose weak-signal DX propogation studies (BeaconNet),
I can see none that are needed in general purpose APRS at least to the
extent of adding to every packet and obsoleting all existing PHG code..
Here are my comments on each...
On Wed, 26 Feb 2003, Ev Tupis (W2EV) wrote:
>PHG is missing several components that are needed for truly useful path
>analysis. It is fine for "ballpark estimates"... Raw path analysis
>requires the following components be known about the TXing station:
>
>TX Interval
Yes, that is what we are adding with the "probe" concept. I have refined
it to a single additional digit expressesd in packets per hour. Thus its
now in one additional byte on the end of PHG. Yet it gives us full
analysis of packet success rate on each individual station as received
anywhere in the topology of an APRS network..
>RF Frequency of Operation
Not needed on APRS on 144.39
>Modulation Scheme (AX.25, PSK31, etc.) and bandwidth
Not needed on APRS on 144.39
>Power Output at the antenna
Included in PHG
> - RF output minus feeder loss
Included in PHG
>Antenna Gain (including negative)
Included in PHG (down to 0 dB)
>Antenna Center - Above Average Terrain
Included in PHG
>Antenna Center - Above Sea Level
Included in PHG
>Receiver Noise Figure
99% of APRS ops dont know, dont care, and can't measure it
>Receiver Passband
15 KHz in the USA
>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
>DSP factors (many to note, too many to mention here)
None worth mentioning on APRS
>Interestingly, these are issues that the BEACONet community has
>attempted to get the APRS community interested in for years...and the
>primary reason why we finally struck out on our own.
Yep, I think it is great to have a system for weak signal DX as you have
done. But in general, I still dont want to mess up the PHG system and
obsolete all software and add overhead in every position packet for these
additions which have very small application on 144.39 APRS network. Even
if somone does try to hear DX on 144.39, the channel is so saturated that
no one could ever hear a DX packet anyway..
Bob
----------------------------------------------------------------------
Subject: More APRS weather
From: Miller Scott Contr 30SCS/FTI <Scott.Miller@vandenberg.af.mil>
Date: Wed, 26 Feb 2003 19:49:24 -0000
X-Message-Number: 20
Thanks to everyone who's responded with input on snow measurement. Sounds
like there's some interest after all.
Now, what about maritime WX reports? Anyone doing that with APRS, or
wishing they could? So far (in addition to the standard report), I've got
wind wave height and period, swell height, period and direction, cloud
cover, visibility, and water temperature. Of course, if I do that, I'll
probably need to define an aeronautical format, too, with ceiling and such.
But back to the boats for a minute... how do you identify a ship in a
consistent manner? Is there any equivalent to the aircraft registration
(N-number in the States)? Or are you stuck using name and port?
Scott / N1VG
----------------------------------------------------------------------
Subject: Re: Holy Grail of APRS Network Performance
From: Bob Bruninga <bruninga@usna.edu>
Date: Wed, 26 Feb 2003 15:02:48 -0500 (EST)
X-Message-Number: 21
APRS PROBING: (new name "PHGR")
In summary, here is my final proposal for an addition of one byte to PHG
to indicate "packets-per-hour" for the sake of allowing APRS software
anywhere to evaluate real-time network reliability by comparing packets
received versus packets sent. This proposal is 100% backwards compatible:
I call it PHGR (by adding RATE on the end)
PHG was "PHGabcd........"
PHGR is "PHGabcdr/......
Where a,b,c,d are as defined in the APRS spec.
Where r is the integer rate of PHGR packets XMTD in packets per hour
And we add a specific "/" separator between the PHGR and any following
text to help flag this as the new PHGR format. All existing software on
receive should still receive the "PHGabcd" with no impact, since no
following character was ever specified.. But, on transmit, most client
applications transmit either a "/" or a SPACE as a separator before any
free text that follows anyway, so in this case, we are just forcing that
now to be a "/" to add reliability in recognizing the new PHGR
digit.
The uses of this new PHGR digit allows RECEIVEING software to
evaluate the success of the network every Rth of an hour for every
station transmitting a PHGR. A tremendous REAL-TIME tool for
everyone if it is done pproperly...
Imagine how you can make a MAP showing COUTOURS of reliability!
Anything I missed?
Bob, WB4APR
----------------------------------------------------------------------
Read previous mail | Read next mail
| |
