Re: [Xastir] Re: Installing on Ubuntu 6.10
Tom Russo wrote: On Tue, Nov 14, 2006 at 12:39:47PM -0500, we recorded a bogon-computron collision of the [EMAIL PROTECTED] flavor, containing: The challenges with a live CD is that you cannot save your settings. Every time you start the Live CD, the PC is dedicated to the Live CD and you have to enter the settings all over again. Live CDs usually don't work very well with wireless cards either - my experience. Not to mention it is slow. Maybe I missed some thing here but. I was under the impression that most Live CD's had the option to create a persistent boot image where your settings would be saved. Mike WN5PMR ___ Xastir mailing list Xastir@xastir.org http://lists.xastir.org/cgi-bin/mailman/listinfo/xastir
Re: [Xastir] Festival Speech
On Tue, 14 Nov 2006, Tom Russo wrote: Yes, festival is speech synthesis as opposed to playing canned sounds. You can configure xastir to read out the call-signs of new stations (really annoying in busy areas), the fact that you have incoming messages and who they're from (sometimes useful), the contents of those messages (sometimes useful, especially while driving), and also read out proximity alerts, as in Proximity Alert, KM5VY five miles from station KM5VY-9 I had my first message read to me by Festival while I was driving, in my noisy Jeep down the freeway. I had just mentioned to another friend on a 2m repeater that I had voice running. Yet another friend decided it'd be the perfect time to send me a message. Was probably funny watching me try to drive, shift, talk on the 2m, and listen to the message all at the same time. For the most part I don't use Festival, but I like to use it sometimes when I'm driving to/from hunting or SAR missions. Keeps me entertained. I have found that festival, while occasionally useful and initially entertaining, is more often an annoyance that I turn off most of the time. Your mileage, of course, may vary dramatically. The best use of it is for demo's. The wow factor. -- Curt, WE7U. APRS Client Comparisons: http://www.eskimo.com/~archer Lotto:A tax on people who are bad at math. -- unknown Windows: Microsoft's tax on computer illiterates. -- WE7U The world DOES revolve around me: I picked the coordinate system! ___ Xastir mailing list Xastir@xastir.org http://lists.xastir.org/cgi-bin/mailman/listinfo/xastir
Re: [Xastir] shape lib problems
On Tue, 14 Nov 2006, Jeremy Utley wrote: The main reason for including shapelib by default is so we can have a shapelib-based map come up right from the very start. Well, at this point the main reason is to have weather alerts from the start, but it still requires the user to run the get-NWSdata script (to download and install the NOAA data files) in order to make that functional. We have a default map in the distribution now but it's a WinAPRS map, created by Keith Sproul. I would have liked a Shapefile map in there but didn't find one I liked that was small enough to add to the distribution. If we come across one later we can add it easily enough though. -- Curt, WE7U. APRS Client Comparisons: http://www.eskimo.com/~archer Lotto:A tax on people who are bad at math. -- unknown Windows: Microsoft's tax on computer illiterates. -- WE7U The world DOES revolve around me: I picked the coordinate system! ___ Xastir mailing list Xastir@xastir.org http://lists.xastir.org/cgi-bin/mailman/listinfo/xastir
Re: [Xastir] Festival Speech
Festival could be a lot more useful if the proximity alerts didn't get fired off by the movement of your station. For a fixed station wathcing people drive by, it works pretty good. Every time the mobile station moves, it will tell you the callsign and distance information for that station. I tried it while driving one day, and I had the audio queued up for 1/2 an hour because I drove past 2 fixed stations within the alert proximity. I was 40 miles down the road by the time that Xastir stopped telling me that VE6*** was 5 miles away. (That can get the XYL a little upset!) Xastir needs to ignore movement updates of itself for creating audio alerts. At least it needs to ignore most of them, perhaps firing off an alert every 1/2 mile or so. This could be a user configurable parameter. It should always fire off an audio alert when remote stations send APRS position updates, but hold off due to it's own position updates. James VE6SRV ___ 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 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
[Xastir] Support for PHGR
While doing research on my previous question I ran across this document (http://eng.usna.navy.mil/~bruninga/aprs/probes.txt) in reference to PHGR which adds a figure on the end of the PHG statement to represent the number of times it transmits its' position data ever hour. This was put in the APRS Spec Erratta (http://eng.usna.navy.mil/~bruninga/aprs/errata.html). Eric ___ 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?
KE4TZNAPU25N,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...
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...
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
