| |
ZL3AI > APRDIG 02.03.03 10:08l 250 Lines 9797 Bytes #999 (0) @ WW
BID : 969-ZL3AI
Read: GUEST
Subj: TAPR Digest, Feb 27, 7/8
Path: DB0FHN<DB0RGB<DB0FSG<OE7XLR<OE9XPI<DB0CZ<DB0GE<LX0PAC<LX0HST<ON5VL<
ON0BEL<ON0AR<WB0TAX<N1UAN<ZL2BAU<ZL3VML
Sent: 030301/0859Z @:ZL3VML.#80.NZL.OC #:60715 [Chch-NZ] FBB7.00i $:969-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
Subject: W2EV PHG Wrapup and QRT
From: "Ev Tupis (W2EV)" <w2ev@arrl.net>
Date: Thu, 27 Feb 2003 18:48:32 -0500
X-Message-Number: 46
Here's the paradox:
Bob Bruninga said:
"And I do not want to encumber the simplicity and backwards compatibilty of
PHG on 144.39 with every possible need for DX and HF work which is a
separate issue."
Translation: Bob has no interest in including other parameters that are
important to BEACONet operation in the APRS spec.
Yet...when BEACONet goes out to create it's own protocol to address its
needs, Bob writes...
Bob Bruninga said:
"Im not knocking BeaconNet. It has its purpose, but it is frustrating to
have APRS equipment and software and not be able to monitor BeaconNet
during a meteor shower or any other propogation enhancing event, without
having to use special software. (because of two bytes)..."
I wish I could code myself. I can't. I simply don't have the time.
BEACONet, for the time being, is still controlled by APRS authors, whose
vision is limited to "the vision of 144.39 on 1200 baud AX.25". That is a
shame. The world is so much bigger than that.
I didn't intend for this thread to go to a BEACONet thing. I intended to
offer insights already learned in the BEACONet world as input to the
ehnanced PHG development opportunity. In fact...I will wrap up with the
following suggestion (that never got to be made for all of the posturing of
why more info in PHG isn't needed):
IF... PHG can be redefined as a variable length field with some
end-of-field flag...then what is the harm in adding more parameters to the
end as I suggest? Those that want to use them, may. Those that don't
won't.
I would suggest that it be called PHGX (for PHGeXtended)
This works for Bob's vision of the world of UI-Frame communication (limited
to the needs of 144.39): PHGXabcd/
This works for BEACONet's more broad vision of how this technology could be
used for other purposes: PHGXabcdefghijklm/
But somehow...this discussion got wrapped around an axel of APRS vs
BEACONet...which simply closes minds, sad as that is.
I'm sorry that somehow this came off as argumentative. That wasn't my
intent. I read and reread each note to remove anything that sounded
provacative. I guess I'm just not as silver tongued as I should be. I'm
done. Really.
QRT.
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: Re: APRS and snow depth reporting?
From: Steve Dimse <k4hg@tapr.org>
Date: Thu, 27 Feb 2003 18:58:06 -0500
X-Message-Number: 47
On 2/28/03 at 12:23 AM wolf.hoeller@gmx.net (Wolf Hoeller) sent:
>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 ... !?
Easy to do, send it as telemetry...
As has been mentioned, the spec for snowfall is hourly rate, not
accumulation, and furthermore is incorrectly listed in the spec.
Steve K4HG
----------------------------------------------------------------------
Subject: Re: APRS and snow depth reporting?
From: James Jefferson <jjeffers@aprsworld.net>
Date: Thu, 27 Feb 2003 18:39:33 -0600
X-Message-Number: 48
>As has been mentioned, the spec for snowfall is hourly rate, not
>accumulation, and furthermore is incorrectly listed in the spec.
Steve, what is the correct listing? I would love to have snowfall
capabilities in aprsworld.net and maybe develope some hardware for
measuring it and sending APRS frames. Right now that seems to be impossible
because sustained wind speed has the same identifier, in the spec at least.
-Jim KB0THN
----------------------------------------------------------------------
Subject: Extensible PHGx
From: Bob Bruninga <bruninga@usna.edu>
Date: Thu, 27 Feb 2003 19:50:18 -0500 (EST)
X-Message-Number: 49
On Thu, 27 Feb 2003, Ev Tupis (W2EV) wrote:
>Here's the paradox:
>
>Bob Bruninga said: "And I do not want to encumber the simplicity and
>backwards compatibilty of PHG on 144.39 with every possible need for DX
>and HF work which is a separate issue."
>
>Translation: Bob has no interest in including other parameters that are
>important to BEACONet operation in the APRS spec.
Nope, false translation. I say to you over and over again, I am willing
to add your DX propogation ideas to APRS, but it is not part of the
current debate of 144.39 network reliability assessment which is my
current focus.
>Yet...when BEACONet goes out to create it's own protocol to address its
>needs, Bob writes...
>
>Bob Bruninga said: "Im not knocking BeaconNet. It has its purpose, but
>it is frustrating to have APRS equipment and software and not be able to
>monitor BeaconNet during a meteor shower or any other propogation
>enhancing event, without having to use special software. (because of two
>bytes)..."
>
>I wish I could code myself. I can't. I simply don't have the time.
>BEACONet, for the time being, is still controlled by APRS authors, whose
>vision is limited to "the vision of 144.39 on 1200 baud AX.25". That is
>ashame. The world is so much bigger than that.
>
>I didn't intend for this thread to go to a BEACONet thing. I intended
>to offer insights already learned in the BEACONet world as input to the
>ehnanced PHG development opportunity. In fact...I will wrap up with the
>following suggestion (that never got to be made for all of the posturing
>of why more info in PHG isn't needed):
>
>IF... PHG can be redefined as a variable length field with some
>end-of-field flag...then what is the harm in adding more parameters to
>the end as I suggest? Those that want to use them, may. Those that
>don't won't.
>
>I would suggest that it be called PHGX (for PHGeXtended)
Now that IS a good idea!
>This works for Bob's vision of the world of UI-Frame communication
>(limited to the needs of 144.39): PHGXabcd/
>
>This works for BEACONet's more broad vision of how this technology could
>be used for other purposes: PHGXabcdefghijklm/
>
>But somehow...this discussion got wrapped around an axel of APRS vs
>BEACONet...which simply closes minds, sad as that is.
I dont see anything closed about my mind, I only offer counter
discussion, when someone proposes someting that WONT work, and I point
out why it WONT work, that is not a closed mind, it is an open mind
offering facts.
>I'm sorry that somehow this came off as argumentative. That wasn't my
>intent. I read and reread each note to remove anything that sounded
>provacative. I guess I'm just not as silver tongued as I should be.
>I'm done. Really.
But I can assure you, that if we try to get ANY TWO authors to agree to
your good idea of an extensible PHG of variablelength to accomodate all
kinds of new stuff, they will all see it as such a bow-wave of effort that
it will KILL any hope of even getting the one additinal byte I want added.
I have worked with APRS authors (including me) for many many years, and
the sureest way to kill ANY good idea is to make it something that
requires dedicated attention, thought and discussion over a protracted
period of time involving a dozen people who have to agree.
This is NOT their fault. They are all too busy with so many other issues
to resolve... So burdening anything down in APRS with a whole boatload of
new features is one sure way of guaranteeing nothing will happen. The
only way it happens is for someone to do it, and see if they follow...
Though I do not advocate that either becasuse it leads to incompatible
systems.
But I can support your idea of extensible PHG digits, they dont do any
damage and people can ignore them if they want... but for now, Im focused
on the first digit...
Bob
----------------------------------------------------------------------
Subject: Re: APRS and snow depth reporting?
From: Steve Dimse <k4hg@tapr.org>
Date: Thu, 27 Feb 2003 20:59:01 -0500
X-Message-Number: 50
On 2/27/03 at 6:39 PM jjeffers@aprsworld.net (James Jefferson) sent:
>Steve, what is the correct listing? I would love to have snowfall capabilities
>in aprsworld.net and maybe develope some hardware for measuring it and
>sending APRS frames. Right now that seems to be impossible because sustained
>wind speed has the same identifier, in the spec at least.
I don't know that this has ever been resolved...
Steve K4HG
----------------------------------------------------------------------
Subject: Re: APRS and snow depth reporting?
From: Bob Bruninga <bruninga@usna.edu>
Date: Thu, 27 Feb 2003 21:06:55 -0500 (EST)
X-Message-Number: 51
On Thu, 27 Feb 2003, Steve Dimse wrote:
>On 2/27/03 at 6:39 PM jjeffers@aprsworld.net (James Jefferson) sent:
>
>>Steve, what is the correct listing? I would love to have snowfall
>>capabilities in aprsworld.net and maybe develope some hardware for
>>measuring it and sending APRS frames. Right now that seems to be
>>impossible because sustained wind speed has the same identifier, in the
>>spec at least.
But sustanined wind speed is position dependent and is a required field
that only appears in the WinAPRS positionless weather format. Thus it is
easy to distinguish from a snow field which can only occur later in the
format.
Or is "s" what we are talking about? Im only half paying attention...
Bob
----------------------------------------------------------------------
Read previous mail | Read next mail
| |
