Finding Your Way with GpsDrive
The Egyptians invented geometry, the mathematical basis of surveying. The Nile's annual floods removed markers and forced those tidy bureaucrats to re-measure roads, fields and other features of the landscape.
Gunpowder came to western hands, and long-range artillery was invented. This required precisely locating naval and artillery guns, as well as their targets. So, the military has had a longtime interest in the art of locating things, and they have refined the techniques that the Egyptians first pioneered.
In the 1970s, the US Department of Defense (DoD) started work on the Global Positioning System (GPS). This put a constellation of 24 satellites in low-Earth orbit. GPS allowed instantaneous fixes accurate to within a few tens of meters. The Soviets launched a similar system, Glonass, which Russia still maintains. And, the EU has begun work on an improved system of its own, Galileo, to be deployed in 2008.
The military is happy; they now can locate targets with much greater accuracy. However, as with another DoD project, the Internet Protocol, the civil spinoffs may far outweigh any military benefits. We can now use GPS to locate errant hikers, help distressed vessels and search for oil wells far more precisely and cheaply than with previous techniques. Indeed, the EU sees Galileo primarily as a commercial venture.
All three systems are based on atomic clocks aboard the satellites. The receiver uses time signals to tell its distance from each satellite. Spherical geometry tells us that three satellites give a fix in two dimensions. A fix in three dimensions requires a minimum of four satellites. Modern GPS receivers can track as many as 12 satellites, the most they can see at any one time.
Because of the frequencies and signal strengths at which GPS operates, the major constraint on GPS receivers these days is that one must be outdoors, or nearly so, or have a remote antenna, in order to track satellites.
GpsDrive is a program licensed under the GNU General Public License (GPL) for displaying one's position in real time. It operates on most laptops running Linux, and on Linux-driven PDAs, such as the Yopy and Zaurus. Currently, 12 languages are supported.
Before we begin, a word of warning: never consider GPS as anything but an adjunct or supplement to other tools of navigation. The advent of GPS is not occasion to dump your copy of Bowditch.
GpsDrive requires the Gnome Toolkit plus (GTK+), version 2.2 or higher, which comes with most Linux distributions. Anti-aliasing fonts are nice but not required.
MySQL can store waypoints, and GpsDrive will automatically use it if possible.
Kismet is a wireless sniffer, a tool for detecting Wi-Fi access points. As Kismet detects them, GpsDrive automatically turns the contact information into waypoints and stores them in MySQL. This turns GpsDrive into an excellent tool for wardriving.
Festival is a voice output program for Linux. GpsDrive uses it for voice delivery of comments as you approach waypoints. It is an excellent safety feature for mobile GpsDrive users. Flite is a stripped-down version of Festival.
Installing GpsDrive is straightforward for those familiar with typical package installation.
Get GpsDrive from its home page or mirrors indicated on its Web site (see the on-line Resources). You can get tarballs, md5sums and RPM packages for the latest stable versions. You also can get the latest work-in-progress quality version from anonymous CVS. The tarball version is the more flexible, as you can remove some of the components you don't plan to use.
To install a tarball, copy it to a suitable location. Then do the following:
tar -xvzf gpsdrive*tar.gz cd gpsdrive ./configure make
If you are using only the NMEA protocol and don't need the GARMIN protocol, configure GpsDrive with:
You can append --enable-auto-optimization for optimized compiler flags.
Then, as root, install the program, the gpsd dæmon and the language files. Run:
RPM installation is the usual:
rpm -ivh gpsdrive*.rpm
Once installation is complete, you should be able to read the man page, which has the latest information.
The first thing to do is to see if GpsDrive works with your GPS receiver. To test the system, fire up gpsd, a dæmon that serves the raw GPS data. It will listen on /dev/gps, unless you tell it otherwise on the command line with the -p option:
gpsd -p /dev/ttyS1
Because you should run GpsDrive and gpsd as a non-root user, make sure that user has read and write permission on the device.
Once gpsd is running, run:
telnet localhost 2947
When you get the connect message, press the R key, and gpsd will start feeding you raw NMEA sentences, like so:
[ccurley@charlesc ccurley]$ telnet teckla 2947 Trying 192.168.1.32... Connected to teckla. Escape character is '^]'. r GPSD,R=1 $PRWIRID,12,01.05,07/29/96,0003,*46 $GPRMC,235947,V,4333.1694,N,10812.0068,W,0.000,0.0,120895,13.3,E*42 $PRWIZCH,00,0,00,0,00,0,00,0,00,0,00,0,00,0,00,0,00,0,00,0,00,0,00,0*4D ASTRAL ASTRAL $GPRMC,235949,V,4333.1694,N,10812.0068,W,0.000,0.0,120895,13.3,E*4C .... GPSD,R=0 ^] telnet> quit Connection closed.
This works even when the receiver can't get any signal, because the receiver will send data indicating that it doesn't have any signal.
Once you know which device your GPS receiver is on, make a symlink (as root) to /dev/gps so that gspd or gpsdrive can use the default:
ln -s /dev/ttyS0 /dev/gps
You can set the device name in the GpsDrive GUI, but gpsd won't use that setting.
If you are going to use MySQL for waypoint storage, which is required for Kismet, see the file README.SQL. You need to feed the file create.sql into MySQL's command-line client, so you must have appropriate permissions in MySQL. You can use any reasonable MySQL client to edit your waypoints, including OpenOffice.org.
|Designing Electronics with Linux||May 22, 2013|
|Dynamic DNS—an Object Lesson in Problem Solving||May 21, 2013|
|Using Salt Stack and Vagrant for Drupal Development||May 20, 2013|
|Making Linux and Android Get Along (It's Not as Hard as It Sounds)||May 16, 2013|
|Drupal Is a Framework: Why Everyone Needs to Understand This||May 15, 2013|
|Home, My Backup Data Center||May 13, 2013|
- New Products
- Linux Systems Administrator
- Senior Perl Developer
- Technical Support Rep
- UX Designer
- Designing Electronics with Linux
- Dynamic DNS—an Object Lesson in Problem Solving
- Using Salt Stack and Vagrant for Drupal Development
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- Nice article, thanks for the
2 hours 7 min ago
- I once had a better way I
7 hours 53 min ago
- Not only you I too assumed
8 hours 10 min ago
- another very interesting
10 hours 3 min ago
- Reply to comment | Linux Journal
11 hours 57 min ago
- Reply to comment | Linux Journal
18 hours 51 min ago
- Reply to comment | Linux Journal
19 hours 7 min ago
- Favorite (and easily brute-forced) pw's
20 hours 58 min ago
- Have you tried Boxen? It's a
1 day 2 hours ago
- seo services in india
1 day 7 hours ago
Enter to Win an Adafruit Pi Cobbler Breakout Kit for Raspberry Pi
It's Raspberry Pi month at Linux Journal. Each week in May, Adafruit will be giving away a Pi-related prize to a lucky, randomly drawn LJ reader. Winners will be announced weekly.
Fill out the fields below to enter to win this week's prize-- a Pi Cobbler Breakout Kit for Raspberry Pi.
Congratulations to our winners so far:
- 5-8-13, Pi Starter Pack: Jack Davis
- 5-15-13, Pi Model B 512MB RAM: Patrick Dunn
- 5-21-13, Prototyping Pi Plate Kit: Philip Kirby
- Next winner announced on 5-27-13!
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?