Re: [Xastir] A problem decoding PHG...
I have been running UI-View32 for a very long time, and use the "add-on" UI-PGH, which at least for UI-View users, draws the Range Circles for stations sending the PHG. For UI-View stations, we can place the PHG in the Comment feild, but it will not show on maps that adhear to the "Specs". On UI-View maps, the Circles appear grey, indicating that the PHG is not in proper place.. The other PHG that is in the Spec location, will appear in color.. I don't remember the outcome when I tried placing the PHG in first spaces of the WX report, as I also run a 24/7 weather station. At least with the UI-View Add-on, we can enjoy the PHG display of the range circles. Robbie Eric Christensen wrote: Makes sense to me. I thing weather packets are long enough as they are without adding a bunch of stuff on to the end of them. Don't worry about me posting anything to the APRSSIG... I left that group many moons ago and don't think I'll be going back. Very unfortunate, though. It could have been a very good place to get information. Eric Tom Russo wrote: On Wed, Nov 15, 2006 at 11:05:58PM -0500, we recorded a bogon-computron collision of the <[EMAIL PROTECTED]> flavor, containing: Okay. So there shouldn't be a PHG statement at the end of the weather data? That is interesting. I know that UIView doesn't integrate the PHG in like Xastir does so John (KE4TZN) was simply putting the PHG statement in the comment portion of the station ID so it would be in there. Ah. Well it's certainly wrong just to bung it into the comment field. The PHG data belongs in a specific place in the information field; specifically PHG belongs in the "Data Extension" field, right after the symbol code in byte 28 of the packet, according to the spec. No spec-compliant software should be decoding it from the comment field. I wonder if there is a way to modify the spec to include these situations? Sigh. The spec is pretty well ossified, although there are a large number of "errata" out there on Bob B's web site. You could always ask on APRSSIG, I guess, but let us know when you before you do so --- I, for one, need to order a new asbestos suit before reading any subsequent traffic over there. If a digipeater were setup to also be a weather station you'd definitely want to know the approximate coverage area. Yep. Such a digi should be transmitting extra packets with a station comment (containing a canonical set of information to show its capabilities) and PHG info. It is not enough for it to just burp weather info. This is usually done by programming a set of beacon strings into its TNC to be sent out at infrequent intervals. ___ Xastir mailing list Xastir@xastir.org http://lists.xastir.org/cgi-bin/mailman/listinfo/xastir
Re: [Xastir] A problem decoding PHG...
Makes sense to me. I thing weather packets are long enough as they are without adding a bunch of stuff on to the end of them. Don't worry about me posting anything to the APRSSIG... I left that group many moons ago and don't think I'll be going back. Very unfortunate, though. It could have been a very good place to get information. Eric Tom Russo wrote: > On Wed, Nov 15, 2006 at 11:05:58PM -0500, we recorded a bogon-computron > collision of the <[EMAIL PROTECTED]> flavor, containing: >> Okay. So there shouldn't be a PHG statement at the end of the weather >> data? That is interesting. I know that UIView doesn't integrate the >> PHG in like Xastir does so John (KE4TZN) was simply putting the PHG >> statement in the comment portion of the station ID so it would be in there. > > Ah. Well it's certainly wrong just to bung it into the comment field. The > PHG data belongs in a specific place in the information field; specifically > PHG belongs in the "Data Extension" field, right after the symbol code in > byte > 28 of the packet, according to the spec. No spec-compliant software should > be > decoding it from the comment field. > >> I wonder if there is a way to modify the spec to include these >> situations? > > Sigh. The spec is pretty well ossified, although there are a large number > of "errata" out there on Bob B's web site. You could always ask on APRSSIG, I > guess, but let us know when you before you do so --- I, for one, need to > order a new asbestos suit before reading any subsequent traffic over there. > >> If a digipeater were setup to also be a weather station >> you'd definitely want to know the approximate coverage area. > > Yep. Such a digi should be transmitting extra packets with a station > comment (containing a canonical set of information to show its capabilities) > and PHG info. It is not enough for it to just burp weather info. This is > usually done by programming a set of beacon strings into its TNC to be > sent out at infrequent intervals. > ___ Xastir mailing list Xastir@xastir.org http://lists.xastir.org/cgi-bin/mailman/listinfo/xastir
Re: [Xastir] A problem decoding PHG...
On Wed, Nov 15, 2006 at 08:49:10PM -0700, we recorded a bogon-computron
collision of the <[EMAIL PROTECTED]> flavor, containing:
> On Wed, Nov 15, 2006 at 10:11:56PM -0500, we recorded a bogon-computron
> collision of the <[EMAIL PROTECTED]> flavor, containing:
> > So I ran into a problem tonight that I thought was interesting. Below
> > is the packet that is received at my station and below that is the
> > decoding of that packet in Xastir.
> >
> > You will see where we were messing around with the way his PHG was being
> > sent. At no time did the software decode his PHG properly. It always
> > displayed the "default". KE4TZN is running UI-View32, btw. Anyone have
> > any ideas?
> >
> >
> >
> > KE4TZN>APU25N,K4ROK-10*,WIDE2-1/1:@160305z3535.79N/07720.76W_072/000g000t066r000p000P000b10120h94/PHG7280
> > {UIV32N}
> >
[...]
>
> I've noticed that xastir will not *transmit* PHG information along with
> my weather information. Other stations in this area that run APRS+SA and
> weather transmit one packet with weather info, then a plain station packet
> with PHG info, and I just guessed that for some reason PHG data extensions
> aren't supposed to be after weather data; but a quick read of the spec just
> now suggests that I'm wrong to guess that.
In reading over the spec again, it looks like in fact weather reports are
not supposed to have PHG extensions attached. Looking at the 1.0 spec, chapter
5, there's a table of report types and their allowed data extensions.
According to that table, the only data extensions that weather reports are
supposed to have are wind direction/speed, and storm data (in the comment
field). PHG is only supposed to be sent by regular position packets.
That explains why APRS+SA sends out a separate position packet with PHG
in addition to the packet with weather data (even though that packet
has position, too). And perhaps why Xastir doesn't look for PHG in a
weather packet.
--
Tom RussoKM5VY SAR502 DM64ux http://www.swcp.com/~russo/
Tijeras, NM QRPL#1592 K2#398 SOC#236 AHTB#1 http://kevan.org/brain.cgi?DDTNM
"And, isn't sanity really just a one-trick pony anyway? I mean all you get is
one trick, rational thinking, but when you're good and crazy, oooh, oooh,
oooh, the sky is the limit!" --- The Tick
___
Xastir mailing list
Xastir@xastir.org
http://lists.xastir.org/cgi-bin/mailman/listinfo/xastir
Re: [Xastir] A problem decoding PHG...
On Wed, Nov 15, 2006 at 11:05:58PM -0500, we recorded a bogon-computron collision of the <[EMAIL PROTECTED]> flavor, containing: > Okay. So there shouldn't be a PHG statement at the end of the weather > data? That is interesting. I know that UIView doesn't integrate the > PHG in like Xastir does so John (KE4TZN) was simply putting the PHG > statement in the comment portion of the station ID so it would be in there. Ah. Well it's certainly wrong just to bung it into the comment field. The PHG data belongs in a specific place in the information field; specifically PHG belongs in the "Data Extension" field, right after the symbol code in byte 28 of the packet, according to the spec. No spec-compliant software should be decoding it from the comment field. > I wonder if there is a way to modify the spec to include these > situations? Sigh. The spec is pretty well ossified, although there are a large number of "errata" out there on Bob B's web site. You could always ask on APRSSIG, I guess, but let us know when you before you do so --- I, for one, need to order a new asbestos suit before reading any subsequent traffic over there. > If a digipeater were setup to also be a weather station > you'd definitely want to know the approximate coverage area. Yep. Such a digi should be transmitting extra packets with a station comment (containing a canonical set of information to show its capabilities) and PHG info. It is not enough for it to just burp weather info. This is usually done by programming a set of beacon strings into its TNC to be sent out at infrequent intervals. -- Tom RussoKM5VY SAR502 DM64ux http://www.swcp.com/~russo/ Tijeras, NM QRPL#1592 K2#398 SOC#236 AHTB#1 http://kevan.org/brain.cgi?DDTNM "And, isn't sanity really just a one-trick pony anyway? I mean all you get is one trick, rational thinking, but when you're good and crazy, oooh, oooh, oooh, the sky is the limit!" --- The Tick ___ Xastir mailing list Xastir@xastir.org http://lists.xastir.org/cgi-bin/mailman/listinfo/xastir
Re: [Xastir] A problem decoding PHG...
Okay. So there shouldn't be a PHG statement at the end of the weather data? That is interesting. I know that UIView doesn't integrate the PHG in like Xastir does so John (KE4TZN) was simply putting the PHG statement in the comment portion of the station ID so it would be in there. I wonder if there is a way to modify the spec to include these situations? If a digipeater were setup to also be a weather station you'd definitely want to know the approximate coverage area. 73s, Eric Matt Werner wrote: > On 11/15/06, Tom Russo <[EMAIL PROTECTED]> wrote: > >> I think that the weather information is the issue. Not sure exactly >> why it >> should be, but I think xastir won't look past it. >> >> I've noticed that xastir will not *transmit* PHG information along with >> my weather information. Other stations in this area that run APRS+SA and >> weather transmit one packet with weather info, then a plain station >> packet >> with PHG info, and I just guessed that for some reason PHG data >> extensions >> aren't supposed to be after weather data; but a quick read of the spec >> just >> now suggests that I'm wrong to guess that. It's something that's >> puzzled me, >> but never enough to get me to look into the code to see why. >> >> It could be that xastir simply isn't looking for data extensions after >> the >> weather data. It certainly doesn't put them in. > > The spec doesn't allow for extensions in a weather packet, only in a > position packet: > > "A fixed-length 7-byte field may follow APRS position data. This field > is an > APRS Data Extension. The extension may be one of the following:" > > -snip- > > "PHGphgd Station Power and Effective Antenna Height/Gain/ > Directivity" > > 73 - Matt > KB0KQA ___ Xastir mailing list Xastir@xastir.org http://lists.xastir.org/cgi-bin/mailman/listinfo/xastir
Re: [Xastir] A problem decoding PHG...
On Wed, Nov 15, 2006 at 09:53:13PM -0600, we recorded a bogon-computron collision of the <[EMAIL PROTECTED]> flavor, containing: > On 11/15/06, Tom Russo <[EMAIL PROTECTED]> wrote: > > >I think that the weather information is the issue. Not sure exactly why it > >should be, but I think xastir won't look past it. > > > >I've noticed that xastir will not *transmit* PHG information along with > >my weather information. Other stations in this area that run APRS+SA and > >weather transmit one packet with weather info, then a plain station packet > >with PHG info, and I just guessed that for some reason PHG data extensions > >aren't supposed to be after weather data; but a quick read of the spec just > >now suggests that I'm wrong to guess that. It's something that's puzzled > >me, > >but never enough to get me to look into the code to see why. > > > >It could be that xastir simply isn't looking for data extensions after the > >weather data. It certainly doesn't put them in. > > The spec doesn't allow for extensions in a weather packet, only in a > position packet: > > "A fixed-length 7-byte field may follow APRS position data. This field is an > APRS Data Extension. The extension may be one of the following:" > Yep. Found that spot in the spec. So in fact, UI-View is doing The Wrong Thing by attaching PHG data to the end of a weather report, and Xastir is doing the Right Thing by ignoring it. Still, it would be nice if there were a way to kick out an extra packet now and then with the station comment and PHG out of xastir. When I remember, I'll put it in as a feature request... -- Tom RussoKM5VY SAR502 DM64ux http://www.swcp.com/~russo/ Tijeras, NM QRPL#1592 K2#398 SOC#236 AHTB#1 http://kevan.org/brain.cgi?DDTNM "And, isn't sanity really just a one-trick pony anyway? I mean all you get is one trick, rational thinking, but when you're good and crazy, oooh, oooh, oooh, the sky is the limit!" --- The Tick ___ Xastir mailing list Xastir@xastir.org http://lists.xastir.org/cgi-bin/mailman/listinfo/xastir
Re: [Xastir] A problem decoding PHG...
On 11/15/06, Tom Russo <[EMAIL PROTECTED]> wrote: I think that the weather information is the issue. Not sure exactly why it should be, but I think xastir won't look past it. I've noticed that xastir will not *transmit* PHG information along with my weather information. Other stations in this area that run APRS+SA and weather transmit one packet with weather info, then a plain station packet with PHG info, and I just guessed that for some reason PHG data extensions aren't supposed to be after weather data; but a quick read of the spec just now suggests that I'm wrong to guess that. It's something that's puzzled me, but never enough to get me to look into the code to see why. It could be that xastir simply isn't looking for data extensions after the weather data. It certainly doesn't put them in. The spec doesn't allow for extensions in a weather packet, only in a position packet: "A fixed-length 7-byte field may follow APRS position data. This field is an APRS Data Extension. The extension may be one of the following:" -snip- "PHGphgd Station Power and Effective Antenna Height/Gain/ Directivity" 73 - Matt KB0KQA ___ Xastir mailing list Xastir@xastir.org http://lists.xastir.org/cgi-bin/mailman/listinfo/xastir
Re: [Xastir] A problem decoding PHG...
On Wed, Nov 15, 2006 at 10:11:56PM -0500, we recorded a bogon-computron
collision of the <[EMAIL PROTECTED]> flavor, containing:
> So I ran into a problem tonight that I thought was interesting. Below
> is the packet that is received at my station and below that is the
> decoding of that packet in Xastir.
>
> You will see where we were messing around with the way his PHG was being
> sent. At no time did the software decode his PHG properly. It always
> displayed the "default". KE4TZN is running UI-View32, btw. Anyone have
> any ideas?
>
>
>
> KE4TZN>APU25N,K4ROK-10*,WIDE2-1/1:@160305z3535.79N/07720.76W_072/000g000t066r000p000P000b10120h94/PHG7280
> {UIV32N}
>
>
> Packets received: 29 Last Heard: 11/15/2006 22:01:27
> Heard via the TNC on device 2, last via Internet on device 0
> Data path: APU25N,WIDE2-2
> Comment 11/15 22:01 : PHG7280 {UIV32N}
> Comment 11/15 22:00 : /PHG7280 {UIV32N}
> Comment 11/15 21:58 : /PHG7280/ {UIV32N}
> Current Power Gain: default (9W @ 20ft HAAT, 3dB omni, range 6.2mi)
> Distance from my station: 4.6 miles Bearing from my station: 97.0?
> Last Position: 11/15 22:01 35 35.790N 077 20.760W
I think that the weather information is the issue. Not sure exactly why it
should be, but I think xastir won't look past it.
I've noticed that xastir will not *transmit* PHG information along with
my weather information. Other stations in this area that run APRS+SA and
weather transmit one packet with weather info, then a plain station packet
with PHG info, and I just guessed that for some reason PHG data extensions
aren't supposed to be after weather data; but a quick read of the spec just
now suggests that I'm wrong to guess that. It's something that's puzzled me,
but never enough to get me to look into the code to see why.
It could be that xastir simply isn't looking for data extensions after the
weather data. It certainly doesn't put them in.
--
Tom RussoKM5VY SAR502 DM64ux http://www.swcp.com/~russo/
Tijeras, NM QRPL#1592 K2#398 SOC#236 AHTB#1 http://kevan.org/brain.cgi?DDTNM
"And, isn't sanity really just a one-trick pony anyway? I mean all you get is
one trick, rational thinking, but when you're good and crazy, oooh, oooh,
oooh, the sky is the limit!" --- The Tick
___
Xastir mailing list
Xastir@xastir.org
http://lists.xastir.org/cgi-bin/mailman/listinfo/xastir
