NOTE: The US Census Buero has shutdown their Tigermap servers. See the June 2010 postings in the Xastir User's reflector archive for details. For us in the "Xastirverse", that means there will no longer be online Tigermaps for Xastir. Instead, we now have OpenStreetMaps support in Xastir-2.0.0 and later.
|
Frequently asked questions (FAQ) about Xastir. If your question is not answered here then please ask for help on our mailing list |
Xastir is an APRS(tm) client program that uses amateur radio and Internet services to convey GPS mapping, weather, and positional data in a graphical application. It has been developed by and for amateur radio enthusiasts to provide real-time data in an easy to use package.
There were already several APRS(tm) client programs available to the Mac/DOS world when Frank Giannandrea, KC2GJS decided to develop a Unix client using the X Window System (X11) and the Motif/LessTiff widget set. From its meager beginnings, Xastir is now a very robust client that meets the needs of the Ham community.
Xastir is an acronym for X Amateur Station Tracking and Information Reporting. Besides it sounds much cooler that those other names ;)
Being actively developed by and for Hams, Xastir is constantly being improved upon to reflect the changing state of APRS(tm). Xastir has all the functionality you would find in any other APRS(tm) client, from any OS, and quite possibly some unique features.
Xastir is currently in use by hundreds of Hams from around the world. The Xastir Group maintains rigorous standards before releasing new versions of our client. When bugs do show up, we release patches and new versions as soon as they are available.
This FAQ may answer many of users frequent questions. However, there are two active mailing lists that users could use to help answer any other questions. Both mailing list are by subscription only and can be accessed through the Xastir web-site. See the top of this document for the addresses. You must be subscribed in order to post messages.
The mailing lists are a good place to bring up bugs or feature requests.
Note: that you must be subscribed in order to post messages. See above.
Another good place to document the request or bug in a more permanent manner is the sourceforge tracker. There are separate bug and feature request trackers, both listed at the Xastir project page, on SourceForge
See the main Xastir web-site for more information. See the top of this document for the addresses. See: XASTIR_Manual
Source code and binaries for several popular Linux distributions is available through the Xastir web-site
If are having trouble running the Xastir software:
The latest version of the Xastir FAQ can be found on the Xastir web-site. See the top of this document for the addresses.
Many Xastir users and developers can be found roaming its virtual halls, so it is suggested that you seek wisdom there. The chances are good that you'll get your question answered there. You must be subscribed in order to post messages.
The Xastir Development Group encourages patches from outside developers. There are two main categories of patches: small bug fixes and general improvements. Improvements, modifications, and additions should follow the instructions below:
In general, the first course of action is to be a member of the "xastir-dev" mailing list. This indicates to the Group that you are closely following the latest developments. Your patch file should be generated using either 'diff -c' or 'diff -u' against the latest CVS tree. To submit your patch, send email to the "xastir-dev" mailing list with a Subject: line that starts with [PATCH] and includes a general description of the patch. In the body of the message, the patch should be clearly described and then included at the end of the message. If the patch-file is long, you can provide a URL of a patch file rather than the file itself. Use of MIME enclosures/attachments should be avoided, as these may be stripped by the mailing list software.
Be prepared to respond to any questions about your patches and possibly defend your code. If your patch results in a lot of discussion, you may be asked to submit an updated patch that incorporates all changes and suggestions.
Anything that works for "you".
The developers make sure that the software builds and works correctly on the platforms available to them; this does not necessarily mean that your platform is one of them. In addition, the Xastir Project is primarily source oriented, meaning that distributing valid and build-able source code is the purpose of a release, not making sure that there is a binary package for all of the supported platforms.
The Xastir developers do not maintain or distribute any binary packages at all. If a distribution of Linux provides a binary of Xastir, it is because someone volunteered to build it and maintain the package. These packages are not part of the Xastir project.
Be warned that is is extremely common for someone to take on the task of creating a binary package for Linux distributions, then lose interest and stop updating it. It is often the case that the binary available through a distributions package maintenance system is quite stale; we have observed one distribution's package as much as two or three years out of sync with the source distribution of Xastir. These old packages fail to provide the user with bug fixes and feature improvements that are present in the current releases.
While binary packages are very convenient, because of this maintenance issue the preferred mechanism for obtaining Xastir is through source code that you build yourself on your own system.
The xastir build procedure requires automake 1.6.3 or later and autoconf 2.53 or later. Using anything older than those will not work.
To be sure of what version of autoconf and automake you're using please examine the output of "automake --version" and "autoconf --version" Do not trust your system's package management software to tell you what version is installed. Some systems install more than one different version of autoconf/automake and you can't be sure which one you're using unless you look at the actual version number reported by the tools themselves.
Worse still, some systems install multiple versions of autoconf and automake and name them in ways that confuses everything (e.g. "automake19" or "autoconf253"). If that's the case on your system, you could either edit bootstrap.sh by hand to force it to find the right ones (adding paths or suffixes or whatever it takes), or you could just end-run the process and download the source code for a suitable version of automake and autoconf from www.gnu.org, use "--prefix=" options when configuring both of them, build them, and install them into someplace your system won't care about. For example, assuming you've untar'ed, say automake-1.6.3 and autoconf-2.57 into the current directory, and that xastir lives in your directory as /home/me/src/xastir:
cd automake-1.6.3 ./configure --prefix=/home/me/src/xastir make install cd ../autoconf-2.57 ./configure --prefix=/home/me/src/xastir make install cd /home/me/src/xastir export PATH=/home/me/src/xastir/bin:$PATH ./bootstrap.sh
This will completely bypass any odd version of automake and autoconf that your system might use, and will insulate you from incompatible changes in those installed tools if you upgrade your OS.
The various configure.ac, acinclude.m4, and Makefile.am files that are used by Xastir's autoconf'd build process were designed for automake 1.6.3 and autoconf 2.53. Using a much more recent version than those could result in warning messages because the tools aren't strictly backward compatible. Most of these warnings are harmless.
If Xastir won't compile on your system, it is probably due to one of the following causes:
This might be either because it's completely unknown or because the specific environment (include files, OS version, etc) isn't explicitly handled. If this happens, you may need to port the software to your OS yourself.
Some operating systems include a default C compiler that is either not ANSI C-compliant or suffers from other deficiencies. The usual recommendation in cases like this is to acquire, install, and use gcc.
In some cases, we have found that a compiler installation or system upgrade has left the C header files in an inconsistent state. Make sure that your include directory tree is in sync with the compiler and operating system.
Xastir depends on at least the X, and Motif or LessTif include files. Be sure these are installed before trying to compile the application. Many Linux distributions name these packages <packagename>-dev or <packagename>-devel.
Note: If you installed ImageMagick from a binary distribution, it will be dependent on the shared libraries for the various graphics formats installed on system on which it was compiled. Be sure you have these same libraries installed, or you'll get a link error.
Note: The ImageMagick-devel package included with RedHat 8 is missing some files needed for Xastir. The version in the beta directory on RedHat's ftp site works.
A message like "*** Cannot find Motif include files" either means that you are missing the development package for Motif/OpenMotif/Lesstif, or that it is installed in a place where configure can't find it. It is recommended that you use Motif or OpenMotif instead of Lesstif, as you'll have few problems with those libraries. For SuSE 9.0, install the "openmotif-libs", "openmotif-devel", and "openmotif" packages. Other distributions have similar naming. If you have the Motif libraries and headers installed in a place where Xastir doesn't look for them, see the references to the "--with-motif-includes" and "--with-motif-libraries" configure options in the INSTALL file.
Software vendors issue new releases for a reason; sometimes to add functionality, but more often to fix bugs that have been discovered. Try upgrading your compiler and/or your operating system.
GCC parses your system header files and produces a modified subset which it uses for compiling. This behavior ties GCC tightly to the version of your operating system. So, for example, if you were running IRIX 5.3 when you built GCC and then upgrade to IRIX 6.2 later, you will have to rebuild GCC. Similarly for Solaris 2.4, 2.5, or 2.5.1 when you upgrade to 2.6. Sometimes you can type "gcc -v" and it will tell you the version of the operating system it was built against.
If you fail to do this, then it is very likely that Xastir will fail to build. One of the most common errors is with readv, writev, or uio.h. This is not a bug with Xastir. You will need to re-install GCC.
This has been seen to occur due to bugs in some versions of LessTif. You may want to try OpenMotif instead if it is available for your distribution. One caveat that was found on Slackware 8.1 is the need to delete all the text in the /usr/X11R6/lib/X11/config/host.def file otherwise it still refers to the LessTif installation.
This is, yet again, an ImageMagick problem. ImageMagick as installed on some systems needs this library linked in. The "Magick-config" script is supposed to supply a list of all of the libraries that ImageMagick needs, but evidently they forgot one. To get around this problem, you can add "-lfreetype" to the link line to get the compile to complete.
This is, yet again, an ImageMagick problem. ImageMagick decided to change their API on us again. Newer releases of Xastir work around this problem by checking the version of ImageMagick you have and changing the function call to match.
You might have forgotten to install both ImageMagick and the ImageMagick-devel RPM. Another possibility is that your particular RPMs might not contain all of the library dependencies that you need, like libcms or zlib. Check carefully through "config.log" to see if the ImageMagick detection code says something like: "ld: cannot find -llcms", "ld: cannot find -lz", or "ld: cannot find -ljpeg". Install the additional libraries that it needs, and perhaps development packages for them as well.
Note: If the "spec" file for the ImageMagick/ImageMagick-devel RPMs had the proper dependencies listed, you would have been asked to install all of the dependent libraries before you could have even installed the ImageMagick RPMs. Encourage your vendor to fix the "spec" files for those RPMs to include all dependencies.
Somewhere around August 2012, Xastir users have begun to report that certain ImageMagick functions are getting reported during the build phase of Xastir as being deprecated. Unfortunately, this means that ImageMagick has begun to phase out some of the functions that Xastir has always used, and that we will need to recode those parts of Xastir to match ImageMagick's current API again.
This is a problem with ImageMagick. In short, your ImageMagick installation has been built with an option incompatible with Xastir.
New versions of ImageMagick include experimental support for High Dynamic Range Images (HDRI). This support changes the data type of a Quantum (pixel value) from an 8- or 16-bit integer quantity to a floating point. Xastir assumes that all pixel values are integer types, and uses operations on those values based on that assumption.
You have two options for getting around this issue -- rebuild ImageMagick without HDRI support, or use GraphicsMagick instead.
As you may see from the many ImageMagick-related questions above, we have some issues with ImageMagick.
ImageMagick is a very good package for image manipulation, but its primary goal is to be on the cutting edge, and as such stability of its API is not its strong point. It has been the experience of Xastir that we have to chase changes in ImageMagick's API every few years, and because we can't be sure that every single Xastir user upgrades ImageMagick at the same time, we have to pepper the code with all kinds of conditionals that check which version of ImageMagick is installed, and use that version's API. This gets old fast, and makes Xastir code a mess.
GraphicsMagick is a fork of the ImageMagick project, and it has as one of its primary goals the stability of its API. This makes it much easier to maintain Xastir, since we don't have to rewrite the GraphicsMagick-dependent parts of Xastir every few years.
There may come a time when the Xastir project abandons ImageMagick and requires GraphicsMagick instead. This has occasionally been brought up on the mailing lists, but the last time we looked into it it was impractical thanks to some Linux distributions having ImageMagick and GraphicsMagick packages that couldn't be installed at the same time, and users who needed ImageMagick for something other than Xastir. This could change.
SourceForge changed things around a bit on Apr 29th, 2004. The changes they made broke CVS for everyone. The error message you get may look like the following:
"Unknown host: cvs.xastir.sf.org"
Luckily the fix is simple. Run these commands from the top directory where you have the Xastir sources:
find -name Root -path \*CVS\* -exec perl -pi.bak -e's/cvs.xastir.sf.net/cvs.sf.net/' \{\} \;
find -name Root -path \*CVS\* -exec perl -pi.bak -e's/cvs.xastir.sourceforge.net/cvs.sf.net/' \{\} \;
Okay, are we having fun yet? They changed things again for us on May 12, 2006. We now want this as the name of the CVS server in the CVS/Root files: "xastir.cvs.sourceforge.net", so the perl command to use after that date has become:
find -name Root -path \*CVS\* -exec perl -pi.bak -e's/cvs.sf.net/xastir.cvs.sourceforge.net/' \{\} \;
The development is done mainly with the English language file, so other languages may not be up to date.
Those texts like IC>PULDNMBC02 are placeholders for missing entries in the language file. You can add the local meaning of that string in the English language file to your language file. And send it to the Xastir development team...
Xastir uses many shared libraries, including lesstif, and perhaps libax25, libproj, libtiff, libgeotiff, libz, libjpeg, etc. These errors indicate ld.so, the Linux dynamic linker, can't find the shared libraries.
As mentioned in INSTALL and helpfile, Xastir must be setuid root to use Linux ax25. This is required because Xastir needs the ability to edit its source callsign, and use other advanced options that the Linux ax25 stack restricts to root.
From a software standpoint, check that you have transmitting enabled on your interface, and that the disable transmission "all" and "my position" options in the Interfaces menu are not enabled. Check that ALTNET support in File|Configure|Defaults isn't enabled.
Also check that your digipeater path is set reasonably; other hams in your area could probably help with this, as the exact settings depend on your setup and on your area's network. The other possibilities are hardware problems: Is the output level on your TNC or soundcard correct? Is PTT on your radio getting triggered? Is your TXdelay set reasonably? All of these possibilities are beyond the scope of this FAQ. An easy way to determine if your hardware works correctly is to try it on conventional packet.
Did you set up your TNC startup files correctly to remove any extra data from the packet headers? Are you using the correct startup file? See the file INSTALL which may be found in the top-level directory of your Xastir source code, in /usr/local/share/doc/xastir, or /usr/share/doc/xastir, depending on how you installed Xastir.
Check that the Display Incoming Data windows is actually showing data coming in. If not, check your radio's volume/squelch levels and your cabling, both between the radio/TNC and between the TNC/Computer.
Check that ALTNET support in File|Configure|Defaults is disabled. If activated, it only shows stations transmitting TO the callsign listed in the box. I sometimes set it to APX or APX190 in order to see who's running Xastir/who's running the _latest_ Xastir. Set it to "WEIRD" and you'll only see those transmitting to "WEIRD".
Check all of your Stations|Filter Data and Stations|Filter Display settings. "Select Stations" and "Display Symbols" must be selected.
If you are using an older version of Xastir, Qxx packets are considered invalid. This is a newer addition to APRS(tm), and recent Xastir releases decode this correctly.
You must be used to conventional packet. APRS™ is inherently different from conventional packet. There are many online resources that explain the basics of APRS™, but I'll try to summarize here. APRS™ is an unconnected protocol, where you broadcast UI (unnumbered information) packets to the world. Since these packets aren't directed toward a specific user, the TO address of the packet is simply a summary of the software you're running. AP=APRS, X=X Windowing System, 110=Version 1.10.
RELAY, WIDE, TRACE, WIDEn-N, and TRACEn-N are aliases for generic digipeaters, although all but the WIDEn-N variants are now deprecated (should no longer be used). Some base stations have their TNCs configured to digipeat with the call of "WIDE1-1" (we used to use "RELAY" for these, but "WIDE1-1" has now taken its place). Newer digipeater software substitutes their own call for "WIDEn-N" to enable people to see who digipeated them. See the README.Getting-Started file for a bit more info on paths, including recommended paths for different types of stations.
To talk to people, you send them messages from within Xastir, you don't "call" them like on typical packet. Most TNCs are set up to ignore classic packet "calls" so you won't get any response. When sending messages to people in your area, do check in their comments that they are people and not stand-alone digipeaters or similar. ;) Thanks to the worldwide APRSserv Internet system, you can send messages to any APRS™ user anywhere in the world, provided they're within range of an Igate. Most users are; if your area isn't and you have a 24/7 Internet connection, Xastir can be your area's Igate! (Please check your local laws, as Igating is illegal in some countries!) There are also experimental systems for sending messages via amateur radio satellites, but that is beyond the scope of this FAQ.
First of all, did you download and install the new shapefile weather maps as described in the INSTALL file? (Running scripts/get-NWSdata automates this somewhat for you now)
Did you compile with shapefile support?
Check that Map|Enable Weather Alerts is enabled, and "Map|Disable All Maps" is not selected .
Did you install libgeotiff before libproj? This error you'll see if you ignored the note in the INSTALL file about this. Recompile libgeotiff and the problem should vanish. If this is not the case, check the datum of the geoTIFF file, and make sure it is one of the ones supported by Xastir. The listgeo program included with libgeotiff can tell you the datum of a map.
There are many things that can effect the speed of your Xastir software, including the speed of the computer, the amount of memory available, the number of active interfaces, the complexity/type/number of maps you use, and the options you used to compile Xastir and helper libraries. The developers aren't aware of any specific cases in which there would be performance problems; generally these are limitations of your computer. Xastir, when using only basic maps, runs reasonably on a Pentium 60. If you use higher detail maps, such as the tiger line maps suggested in README.MAPS, you'll need a faster computer to be able to load the maps quickly. Also be sure you have a few Megabytes of memory available for Xastir, because paging to disk decreases speed rapidly. If you have the Internet interface, as well as TNCs and weather stations all active at the same time, you'll see a slowdown on a slower computer. Also, if you compiled Xastir or libax25/libtiff/libgeotiff/etc with debugging (-g), recompile these software without debugging and with optimization ON (-O2).
The help menu shows the version of lesstif that Xastir was compiled with, not necessarily the version you're running now. Assuming you compiled it with the new version, check that the new version is the only copy installed. If you install in /usr/local/LessTif/, the default location, be sure you remove any older version from /usr/LessTif/ or /usr/X11R6/LessTif/, as some distributions use those locations.
The geoTIFF code must use an API in the TIFF code that is non-public. Unfortunately this means that the geoTIFF code must know more about TIFF than the normal application using the TIFF library. If the private TIFF include file included with the geoTIFF code doesn't match your installed version of TIFF, you can run into seg-fault problems.
Solutions for this include:
Either of these solutions will make the geoTIFF code recognize and use the proper structures in TIFF should prevent the seg-faulting.
In the future we hope that either the geoTIFF code will become part of the TIFF code, or that the private TIFF API will become public. Either of these changes should fix this problem for good.
The RH kernels have implemented the new(er) New Posix Threading Library (NPTL) as well as back-ported many of the new bells and whistles set to appear in the 2.6.x kernels. You might experience a great improvement for apps that are heavily threaded. NPTL is supposed to be backward compatible but we have seen apps that have had problems. You can revert back to the older LinuxThreads implementation by setting the environment variable:
LD_ASSUME_KERNEL=<kernel-version>
in a shell before starting the app The following versions are available:
or, you can disable NPTL altogether for dynamically linked applications by using 'nosysinfo' as a boot time option.
This message and similar have to do with localization and OpenMotif/Lesstif. For most of us this is a benign message and can be ignored. If you simply can't stand it any more set LANG="C" or LANG="en_US". In RH 9 the default LANG is set to en_US.UTF-8 and this is where the warnings are coming from.
A quick way to address this on RedHat 8 and 9 is to edit your /etc/sysconfig/i18n config file. I believe the original file looks like:
LANG="en_US.UTF-8" SUPPORTED="en_US.UTF-8:en_US:en" SYSFONT="latarcyrheb-sun16"
Change the "LANG=" line to:
LANG="en_US"
and reboot.
With the original setting you get some weird character mappings. For example, running "man ls", all of the dashes (-) disappeared from my screen until I changed the LANG setting.
Strong blue (or perhaps other color) tinting of the image may be due to running the display over a Hummingbird eXceed session. Try running it locally and you should see the proper colors. Try changing the eXceed session to use more bits of color.
Xastir saves previous revisions of the config file as "xastir.cnf.1" through "xastir.cnf.3". Look for them in the ~/.xastir/config directory. Kill Xastir, then copy one of the backup files to "xastir.cnf" in order to recover your previous settings. Xastir will use the "xastir.cnf" file the next time it starts up.
Older Xastir versions saved only one copy of the config file as "xastir.bak".
If your LC_NUMERIC environment variable is set to something other than "C", it can cause commas and periods to be swapped when Xastir tries to read/write files. We've tried to address this in the latest Xastir code, forcing LC_NUMERIC="C" inside Xastir itself. Another solution is to type this when starting Xastir (from a BASH shell. If you use another type of shell, modify the syntax accordingly):
export LC_NUMERIC="C"; xastir &
There was a bug in versions of Xastir prior to the CVS version of 4 December 2009 that caused this problem if ImageMagick (or GraphicsMagick) were compiled with QuantumDepth not equal to 16 (GraphicsMagick now defaults this parameter to 8). The bug was fixed, and current versions of Xastir should not have this problem. If you are running an older version than 4 December 2009, updating will likely solve this problem for you.
If you are running a version higher than 1.9.7 or a CVS version checked out after 4 December 2009, then the problem lies elsewhere. As of August 2012, we have not had any complaints of this particular problem in any current version of Xastir, so if you are running the latest code and see a black screen when using ImageMagick or GraphicsMagick-dependent maps, it's a new problem and you should report it on the mailing list.
Use ports such as /dev/cu.usbserial0 for USB to serial adapters on Mac OS X.
Because they are treated as modifiers by Motif. Here's an FVWM2 document (FVWM2 is a window manager) that talks about it.
See section 5.5 of that document which talks about these keys. If you type these commands and then restart your window manager it may take care of your problem, but then those keys will be disabled and you won't be able to use in other applications:
xmodmap -e "clear Lock" xmodmap -e "clear Mod2" xmodmap -e "clear Mod5"
For Linux, try a program called "remserial". It works as a client/server pair to do exactly what you want. Google should find it for you. One user was able to use a spare serial port on his windows box using "remserial" on the Linux computer and a program called "serproxy" on the windows machine. Another one I have to try for windows is comfoolery. See links below.
Another option is to use a Perl script on each end to do the conversion.
Yet another is to use "netcat". "man nc" or "man netcat" should tell you about it. It redirects tcpip data seamlessly under Linux. On SuSE the docs for it are in /usr/share/doc/packages/netcat. Try a command line like this:
cat /dev/ttyS0 | nc -l -p 3000
or
cat /dev/ttyS0 | netcat -l -p 3000
That should make a listening socket at port 3000 which listens to the /dev/ttyS0 serial port. "telnet localhost 3000" should show you any data coming in on that serial port. Connect Xastir across the network to that listening socket to get the data.
If you want to put your GPS on a remote serial port, use the gpsd daemon to do it.
If you wish to put your weather station on a remote serial port, investigate using OWW (for Dallas weather stations), wx200d daemon for some Radio Shack/Huger/Oregon Scientific weather stations, or Meteo daemon for Davis weather stations.
You may also connect to a remote AGWPE instance for using remote TNCs/soundcards. Note that AGWPE runs only on Windows.
Yet another which looks to be netcat recoded/extended: socat
festival_server &
telnet localhost 1314
(SayText "Hello, World")
127.0.0.1 localhost localhost.localdomain
export MAGICK_HOME=/usr
Added to the ~/.profile file, so that the BASH shell gets this defined each time you log in. The location "/usr" will probably be different on a non-Windows machine, so change the line above as required for your system.
http_proxy = http://proxy.yoyodyne.com:18023/ ftp_proxy = http://proxy.yoyodyne.com:18023/
Yes, but you must keep the configuration directories separate for each copy by using a command-line flag. Xastir will create the new config directory and fill it with defaults if it doesn't already exist. Here's the method. Substitute your user name where it says "<user>":
xastir & # starts up first Xastir copy against ".xastir" directory xastir -c /home/<user>/.xastir2 & # starts up 2nd Xastir copy against ".xastir2" directory xastir -c /home/<user>/.xastir3 & # starts up 3rd Xastir copy against ".xastir3" directory
To make the process easier if you use this method a lot, create aliases by editing your .profile (This assumes you're running BASH or Bourne shells):
alias xastir2='xastir -c /home/<user>/.xastir2 &' alias xastir3='xastir -c /home/<user>/.xastir3 &'
After sourcing your new .profile (The command is ". .profile" from your home directory) or logging out and back in again, you can type "xastir2" or "xastir3" as a command to start up the additional copies of Xastir.
Older methods, may still be useful at times:
Do this to allow more than one user to access your X display and to create additional users, each capable of running one Xastir session:
xhost localhost
This lets other users on your machine use the X11 display.
Create another user (or two or three) using whatever facilities your system uses to do this.
xterm & # Start up an xterm window in the background su 2nduser. # su to one of your new usernames xastir & # Start up Xastir as that user, in the background
Optionally:
Set up your 1st Xastir instance with the server port enabled. Connect the 2nd instance to localhost:2023. This way one Xastir will get its feed from the other.
You can start up a third Xastir in the same manner, starting with the "xterm &" command and then doing "su 3rduser" instead, then "xastir &" as that third username.
Many Xastir sessions can all get their feed from one Xastir session, or they can be connected to different TNCs or server ports.
Terraserver is based on the UTM coordinate system. If you're trying to request map images that cross a UTM zone boundary, terraserver may not work at that location. Zoom in closer or pan left/right in order to avoid this problem.
A few of the menu settings do not get saved. This is on purpose. If you are having more serious troubles, like for instance your station location setting isn't getting saved between Xastir runs, check your LANG setting (see question 4.13 above).
VNC may have a different colormap or colordepth than the system Xastir is running on. Here is one invocation that a user used which worked. Substitute the appropriate parameters for your system of course:
vncserver :5 -name melecom -depth 24 -geometry 800x600 -pixelformat rgb565
Some versions of the Lesstif widget set have this bug. Try switching to a different version of Lesstif or switch to OpenMotif and you should see the labels again. So that you can actually operate Xastir, here's what you _should_ have seen:
On the left:
------------
Posit TX Interval (min)
Object/Item TX Interval (min)
GPS Check Interval (sec)
Dead-Reckoning Timeout (min)
New Track Time (min)
RINO -> Objects Interval (min), 0=Disabled
Snapshot Interval (min)
On the right:
-------------
Station Ghosting Time (min)
Station Clear Time (hours)
Station Delete Time (days)
Serial Inter-Char Delay (ms)
New Track Interval (degrees)
Internet Map Timeout (sec)
Editor Note: Need Image File A screenshot on the Wiki of this dialog: <http://www.xastir.org/wiki/Notes:Timing_Slider_Dialog_Screenshot>
This could be one of several things. We'll check them in order:
"Error! can not find color file: /xastir/config/xastir.rgb"
-DXASTIR_DATA_BASE=\"/usr/local/share/xastir\"
cd mv .xastir .xastir.save xastir
change, go back to your original configuration by typing:
cd rm -rf .xastir # NOTE: this will delete ~/.xastir and all contents! mv .xastir.save .xastir
echo $LANG
export LANG=en_US; xastir -geometry -0-0 &
which xastir -or- whereis xastir
./bootstrap.sh ./configure make
Enable Station->Filter Display->Display Trail
File->Configure->Timing->"New Track Time" and New Track Interval should be set above zero. Defaults for these are 45 and 1 respectively.
If this problem and others occur, such as your latitude/longitude getting lost between runs, this might indicate a problem with your LANG variable. See question #4.26 above.
Install the maps in the correct place, normally "/usr/local/share/xastir/maps/" or subdirectories below there. If running LSB-Xastir it's "/opt/Xastir/share/xastir/maps/".
Make sure the map directories and files have read permissions for the user.
Select "Map->Configure->Index: Add New Maps", then check in Map Chooser to see if the map is listed. If not, try the "Reindex ALL Maps" option.
Verify that you have installed the map libraries necessary to handle the types of maps you're wishing to use: "Help->About". Also you can check the messages written to STDERR in the shell you start Xastir from.
Check this file to see if map indexing found the file at all. It's the same file that Map Chooser reads to display the map selections:
~/.xastir/config/map_index.sys
If the map is a raster map, you can check whether your installed ImageMagick or GraphicsMagick can display the image.
For IM: display <filename>
For GM: gm display <filename>
If it's an internet-based map you're trying to download/display, verify in the Xterm that you have internet maps enabled using either libcurl or wget. Check manually whether curl or wget (whichever Xastir is using) can fetch a remote file. Check whether a file like ~/.xastir/tmp/map.gif or map.jpg shows up after you try to fetch a file, even if Xastir doesn't display it. See if one of the above "display" commands will display it if so. Check the File->Configure->Timing dialog for the "Internet Map Timeout" setting: Adjust it upwards if Xastir is timing out fetching the remove map.
If all else fails, try removing the ~/.xastir directory and all contents. Warning: This will cause you to lose all of your personal Xastir configuration, including callsign, location, bookmarks, map levels and other map settings, etc. Once you've done this, verify that your LANG setting is either "C" or "en_US", with no additional characters in there, then start Xastir from that same shell with the correct LANG setting. Xastir should index all of your maps on startup. After it is complete, bring up the Map Chooser and all available maps should be listed.
This is caused by an interaction between "Motif" and "compiz". "compiz" is enabled in some versions of Ubuntu Linux with a "Desktop Effects" menu item. They changed the default to *ON* several releases ago. "compiz" is a window manager which enables eye-candy effects such as animated window opening/closing, 3-D effects, and so forth. To fix this problem, turn *OFF* "Desktop Effects" which will disable "compiz" and re-enable the default window manager.
This was a Fedora X11 bug and has been fixed. Do a "yum update" on your system to get the latest Fedora fixes.
If you're having troubles with another OS, read this thread to get some insight into the problem:
https://bugzilla.redhat.com/show_bug.cgi?id=543647
It appears to be a bug in the X11 server and can affect OpenMotif and Lesstif apps. I didn't read every comment though. There were definitely many dead-ends as they went along discussing it.
You will need the device drivers from FTDI, downloadable from their website at http://www.ftdichip.com/Drivers/VCP.htm
Note: the TNC-X packet datarate is fixed at 1200 baud, however the serial communication with the computer is configurable via internal jumpers. It's been observed that setting the com port to 1200 baud results in a deaf TNC-X. Setting the com port to 9600 baud works well, however.
The problem is that you probably have previously installed a binary version of Xastir from your system's repository --- and Linux packages are set up to install files in /usr (e.g. binaries to /usr/bin, libraries to /usr/lib/, and supporting files to /usr/share). But CVS xastir, like almost all source packages, installs to /usr/local, /usr/local/bin, /usr/local/lib, /usr/local/share). When you de-installed your binary package and installed the source version, it removed the /usr/ stuff and installed the files in /usr/local/.
Your configuration files for Xastir still point to the old locations, and Xastir is confused because files it's expecting aren't there.
You have two approaches to fix this:
1) If you have not used Xastir a lot and don't have a whole lot of custom configurations (map selections, interface properties, etc.) then you can just move your ~/.xastir/config/xastir.cnf file and let Xastir regenerate a default set-up. Many people here recommend that approach because it's just a matter of one command:
mv .xastir/config/xastir.cnf .xastir/config/xastir.cnf_old
But this will blow away all your customizations, so it might not be the best choice. Note that you can still glean information from the old copy of the config file to help set up the new.
2) Change all references to "/usr/" in your configuration files to "/usr/local". Most of these will be in ~/.xastir/config/xastir.cnf so it's just a matter of editing that one file and changing them all.
It is always an issue when you switch from a pre-compiled linux package to a source build.
Probably because someone hasn't taken the time to write the feature or enough people have complained loud enough that it wasn't there. The feature set of Xastir is user/developer driven. So get busy!
If you're running serial-port connected TNCs, the "tnc-startup.*" files that get installed in /usr/local/share/xastir/config should set up your TNC to respond to these packets. Select Interfaces->Properties, then select the interface, click Properties, then select the Setup and Shutdown files at the bottom of that dialog. When an interface is brought up the Setup file will be downloaded to the TNC. "myalias WIDE1-1" is the command most TNCs accept for defining a digipeating alias. That command or similar should be in the Setup file that you use.
Use "myalias WIDE1-1" with the new path scheme discussed on APRSSIG during early April, 2005: RELAY/WIDE/TRACE/TRACEn-n are deprecated (should not be used).
If you're running kernel AX.25 interfaces, then you'll need to run another package to handle digipeating on these interfaces, perhaps digi_ned.
You can cause a snapshot to occur by enabling Snapshot in the File menu. It takes a snapshot every five minutes starting immediately when the togglebutton is first enabled. This means you can change views and disable/enable to take an immediate snapshot each time as well.
You can also send a "SIGUSR1" signal from another process and Xastir will take a snapshot. The feature was added so that someone could press a button on a web page and cause Xastir to make a new snapshot.
For Example, from the shell you can do:
kill -SIGUSR1 `cat ~/.xastir/xastir.pid`
Snapshots will are stored under ~/.xastir/tmp/
As of 9 August 2012 (revision 1.805 of main.c), it is possible to send a "SIGUSR2" to Xastir, which will cause it to transmit its position immediately.
kill -SIGUSR2 `cat ~/.xastir/xastir.pid`
This feature is not available in versions of Xastir prior to that date, and in August 2012 is available only in the CVS version, not any release or stable-snapshot version.
Somewhere around a half-hour or an hour after you start Xastir with a connected TNC, you will begin to see a yellow circle surrounding your station at some zoom levels. This is your "ALOHA Circle," the circle containing approximately the number of stations that should saturate your local APRS channel. See ALOHA Circle Text for details. The short story is you should set your path so your packets don't travel farther than this circle's radius.
This circle is shown when your station is in view and you are zoomed out far enough to contain the circle in the viewport. Its radius is recalculated once every half an hour from the stations you've heard on RF. Stations you hear from internet servers or other non-RF sources are not included in the calculation. The circle can be turned off from the Station->Filter Display menu but it will be enabled again each time you restart Xastir.
Send a SIGHUP to the process. This will cause Xastir to save its configs, exit, then restart with the same environment and command-line parameters as it initially had.
For Example, from the shell you can do:
kill -SIGHUP `cat ~/.xastir/xastir.pid`
Note: This SIGHUP trick doesn't work if you've configured Xastir with profiling ( "./configure --with-profiling" ).