| |
ZL3AI > APRDIG 09.12.03 09:40l 233 Lines 10184 Bytes #999 (0) @ WW
BID : 2447-ZL3AI
Read: GUEST
Subj: TAPR Digest, Dec 04, 2/7
Path: DB0FHN<DB0FOR<DB0SIF<DB0EA<DB0RES<ON0AR<7M3TJZ<LZ3NP<WB0TAX<ZL2TZE<
ZL3VML
Sent: 031209/0721Z @:ZL3VML.#80.NZL.OC #:14231 [Chch-NZ] FBB7.00i $:2447-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
Subject: Peet WX Station decode for APRS
From: Ralph Milnes <ralphmilnes@patmedia.net>
Date: Thu, 04 Dec 2003 14:09:11 -0500
X-Message-Number: 11
At 10:04 AM 12/4/2003, Peet Bros wrote:
>Peet Bros. Co. does listen to the amateur community and tries to work with
>it as best as possible but we regret that it is difficult to make an
>instrument that is primarily a home weather station work with every PC ,Radio
>and Tnc that is make from all over the world.
Dear Peet Bros.
No, I think it would be easier than you think. You would need to add just
*one* additional "APRS" packet statement. It would be used by amateurs who
have a Peet station hooked directly to a TNC, no PC involved (as I do). All
TNCs and radios should be able to use it, just as they use the $ULT and !!
statements now.
Peet already has an edge over your competitors: your units output data
sentences that don't need massaging by a computer program. Adding this new
APRS-specific statement would further add to your edge ($$$) in the APRS
community.
If you were willing to consider this, I would get the APRS community to
come up with the precise format and refresh rate of that packet, but it
would be something like below (extracted from APRS Protocol Specifications).
Ralph Milnes KC2RLM
"cc" to APRS reflector with over 1000 members
*******************
The desired APRS packet to be output by Peet units would be something like
the following (extracted from APRS Protocol Specifications).
We would need to consider the best refreshing rate for such a statement,
but every 1-5 minutes seems like it might work. It would seem that
"continuous" is not necessary, since the time stamp only allows for a
maximum precision of 1 minute:
_10090556c220s004g005t077r000p000P000h50b09900*U2K
where:
_= symbol for positionless WX report followed by 8 digits for month,day,
hour, minute
c = wind direction in degrees. Natl Weather Service (NWS) says this should
be based on a 2 minute average.
s = sustained wind speed in mph over 2 minutes (2 minutes is the NWS
standard; APRS protocol says one minute -- needs to be resolved)
g = gust, but interpreted as peak wind speed in mph ( the NWS standard is
"since last report"; the APRS protocol says the last 5 minutes -- needs to
be resolved)
t = temperature (in degrees Fahrenheit). Temperatures below zero are
expressed as -01 to -99.
r = rainfall (in hundredths of an inch) in the last hour.
p = rainfall (in hundredths of an inch) in the last 24 hours.
P = rainfall (in hundredths of an inch) since midnight.
h = humidity (in %. 00 = 100%).
b = barometric pressure (in tenths of millibars/tenths of hPascal).
* = needed placeholder for parsing? will check if needed; normally used to
indicate software type -- not applicable in this case
U2K = optional 3 digit code for name of station; others could be U-II
(Original Ultimeter U-II) or U5 (Ultimeter 500), etc.
Note: The weather report must include at least the MDHM date/timestamp,
wind direction, wind speed, gust and temperature (in that order), but the
remaining parameters may be in a different order or may not omitted.
There is also provision in the APRS protocol to substitute one or more of
the rain values for other parameters if they are available on some Peet
weather station units, including:
L = luminosity (in watts per square meter): 999 and below.
l (lower-case letter "L") = luminosity (in watts per square meter): 1000
and above.
s = snowfall (in inches) in the last 24 hours (since there is already an
's' used for wind speed, this should be changed, perhaps to 'f' = frozen; I
will find out.)
# = raw rain counter
I would have to ask the APRS community their about their preference if
*both* the rain values (r,p, and P) and the above substitutes were all
available. It may not be possible to append them if the APRS protocol
prescribes a maximum number of bytes per data sentence, and it may be that
we would always prefer to see the r,p. and P values if available, even if
the L,l, f and/or # values were also available.
Note: Where an item of weather data is unknown or irrelevant, its value may
be expressed as a series of dots or spaces. For example, if there is no
wind speed/direction/gust sensor, the wind values could be expressed as:
c...s...g...
or
c s g
^ ^ ^
3 spaces after the c, s, and g.
But remember, the date/timestamp, wind direction/speed/gust and temperature
parameters
must be included in every packet, even though they are not meaningful (i.e.
have dots or spaces).
----------------------------------------------------------------------
Subject: APRS WX Protocol Questions
From: Ralph Milnes <ralphmilnes@patmedia.net>
Date: Thu, 04 Dec 2003 14:06:23 -0500
X-Message-Number: 12
For position-less weather packets:
1. Why is it that "gust" is required in the packet along with temp, speed,
and direction? Gust doesn't seem to be more important than other
non-required measurements, such as rain or pressure.
For that matter, why are any of the 4 mandatory measurements required? If
anything, "pressure" is the measurement most likely to be available from
most wx stations.
2. According to the published APRS specs, "s" can also be used to indicate
both "snowfall" and "sustained wind speed". Using the same indicator for
two different measurements seems like it could cause problems, even though
snowfall is probably not reported via APRS very often. Perhaps "f" for
"frozen" would be a better choice for snowfall.
Also .... while researching the APRS specs, I noticed that the APRS
standards -- and probably the output from commercial weather stations --
for wind speed, gusts, and direction is out-of-line with the US National
Weather Service's "Federal Meteorological Handbook":
http://www.ofcm.gov/fmh-1/fmh1.htm, specifically chapter 5 on Wind:
http://www.ofcm.gov/fmh-1/pdf/ch5.pdf :
c = wind direction: The APRS Spec does not define the measurement period.
The Natl Weather Service (NWS) says to base it on a 2 minute average, not a
momentary measurement.
s = sustained wind speed in mph. The NWS standard is a 2 minute average. It
also says to report in knots. The APRS Spec says one minute average in mph.
g = gust: The NWS has different definitions for "gusts" and "peak wind
speed". The APRS spec says "gust" means "peak wind speed in last five
minutes". The NWS measurement period for peaks is "since your last report".
The NWS also says peak wind speed must exceed 25 knots to be reported.
I don't know if these discrepancies are significant. I'm also not sure how
to resolve them, especially if we are at the mercy of the output from the
manufacturer's weather unit.
This has been problematic since day 1 of weather reporting via APRS --
trying to prescribe "standard" measurements that can't be obtained from our
measurement devices. For example, the $ULT or !! packets from my Peet
U-2000 WX station don't contain a 2 minute wind speed average in knots or a
wind direction based on a 2 minute average . They also don't contain "r" (1
hour) or "p" (24 hours) rainfall periods, the only accepted measurement
periods by the NWS (see 12.7.2 a. (3) in the handbook). They do contain "P"
(since midnight), which is commonly reported on the nightly news, but
that's not an accepted reporting period by the NWS. ("r" and "p" may be in
the other two Peet packet types, but those types can't be decoded by APRS
programs.)
On one hand, it would be nice to give the NWS what they want from APRS.
On the other hand, they may not really care if they have been assuming all
along that APRS weather wind reports are never reported correctly, i.e. by
NWS standards.
Furthermore, reporting wind speeds in knots and not mph is not useful for
the everyday APRS operator, as is seeing "gust" measurements only if peak
wind speed exceeds 25 knots.
So I'm not sure what's best. Just ruminating out loud ...
Ralph KC2RLM
----------------------------------------------------------------------
Subject: I-Gate Without a Computer
From: "Eric Christensen" <christensene@wc.local>
Date: Thu, 4 Dec 2003 14:21:34 -0500
X-Message-Number: 13
At one point there was development on a little box that when connected to a
network (using CAT 5) and connected to a TNC (RS232?) it would act as an
I-Gate without having to have a computer hooked up. I don't remember who
was designing this but where is that project now? Is there any other way
to setup an I-Gate without having a computer?
Thanks,
Eric KF4OTN
----------------------------------------------------------------------
Subject: Re: NMEA at >100,000 feet
From: "Gregg G. Wonderly" <gregg@skymaster.cytetech.com>
Date: Thu, 04 Dec 2003 13:22:01 -0600
X-Message-Number: 14
>Has anyone had any experiences with reed relays at low temperatures? I'm
>thinking of using one to trigger a camera's shutter, and it's rated to -20
>C, but the required activation voltage rises as it gets colder and I'm
>worried about it not being triggered by a TTL output. Also, I was looking
>at the specs for the 78L05 voltage regulator, and the TO-92 package is only
>rated to 0 C. With the amount of power it's dissipating I can't imagine it
>getting too cold, but I'm new to this sort of thing. I think I might pick
>another, lower drop-out regulator anyway.
What some of the guys here have done (http://www.gbronline.com/harrymue/orb6)
is use insulating foam to build a rectangular box that they put all the
equipment into. They've then bought some blocks of dry ice and placed those
inside an icechest with the container for the gear and the gear inside the
container. They've left it in for several hours to see how things stood up to
the temps. They've used a thermometer inside the container to track the temp
over time.
The results that they found is that even with a hole in the bottom for the
camera to see out of, they can do 70k feet. They continue to try and decide
whether they want to go higher, or farther or both.
-----
gregg@cytetech.com (Cyte Technologies Inc)
----------------------------------------------------------------------
Read previous mail | Read next mail
| |
