diff options
Diffstat (limited to 'www/faq.html.in')
| -rw-r--r-- | www/faq.html.in | 820 |
1 files changed, 820 insertions, 0 deletions
diff --git a/www/faq.html.in b/www/faq.html.in new file mode 100644 index 00000000..39c550b7 --- /dev/null +++ b/www/faq.html.in @@ -0,0 +1,820 @@ +<!doctype html public "-//w3c//dtd html 4.0 transitional//en"> +<!-- @MASTER@ --> +<html> +<head> + <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> + <meta name="Author" content="Eric S. Raymond"> + <meta name="Description" content="GPSD Frequently Asked Questions"> + <meta name="Keywords" content="GPS, translator, GIS"> + <link rel="stylesheet" href="main.css" type="text/css"/> + <title>GPSD FAQ</title> +</head> +<body> + +<div id="Header"> +GPSD Frequently Asked Questions +</div> + +<div id="Menu"> + <img src="gpsd-logo-small.png" alt="Small gpsd Logo" /><br /> + <a href="index.html">Home</a><br/> + <a href="index.html#news">News</a><br/> + <a href="index.html#downloads">Downloads</a><br/> + <a href="index.html#mailing-lists">Mailing lists</a><br/> + <a href="index.html#documentation">Documentation</a><br/> + FAQ<br/> + <a href="xgps-sample.html">Screenshots</a><br/> + <a href="index.html#recipes">Recipes</a><br/> + <a href="index.html#others">Other GPSDs</a><br/> + <a href="hardware.html">Hardware</a><br/> + <a href="for-vendors.html">For GPS Vendors</a><br/> + <a href="wishlist.html">Wish List</a><br/> + <a href="hall-of-shame.html">Hall of Shame</a><br/> + <a href="troubleshooting.html">Troubleshooting Guide</a><br/> + <a href="hacking.html">Hacker's Guide</a><br/> + <a href="protocol-transition.html">Application Compatibility</a> + <a href="references.html">References</a><br/> + <a href="history.html">History</a><br/> + <a href="future.html">Future</a><br/> + + <div> </div> + + <a href='http://www.catb.org/hacker-emblem/'><img + src='http://www.catb.org/hacker-emblem/glider.png' + alt='hacker emblem' /></a><br /> + + <script type="text/javascript" src="http://www.ohloh.net/p/3944/widgets/project_thin_badge.js"></script> + + <hr/> + <script type="text/javascript"><!-- + google_ad_client = "pub-1458586455084261"; + google_ad_width = 160; + google_ad_height = 600; + google_ad_format = "160x600_as"; + google_ad_type = "text"; + google_ad_channel = ""; + //--></script> + <script type="text/javascript" + src="http://pagead2.googlesyndication.com/pagead/show_ads.js"> + </script> + <hr/> + + <a href="http://validator.w3.org/check/referer"><img + src="http://www.w3.org/Icons/valid-xhtml10" + alt="Valid XHTML 1.0!" height="31" width="88" /></a> +</div> + +<div id="Content"> + +<ul> +<li><a href='#verify'>How can I verify operation of a new GPS?</a><br/> +<li><a href='#bug-reporting'>How do I report bugs in GPSD?</a><br/> +<li><a href='#startup'>Why does getting a fix take so long after powerup?</li> +<li><a href='#timelag'>Why does GPS time lag wall time by 11-15 seconds?</a></li> +<li><a href='#speed'>Why does my receiver report wildly fluctuating speed?</a><br/> +<li><a href='#gpsdrive'>Why do I get implausibly low speeds when using gpsdrive?</a><br/> +<li><a href='#kismet'>Why do I get no results when I try to use <code>gpsd</code> with Kismet?</a><br/> +<li><a href='#bluetooth'>Why do I have to restart <code>gpsd</code> whenever I power-cycle my Bluetooth device?</a><br/> +<li><a href='#lockup'>My <code>gpsd</code> sometimes stops responding overnight</a><br/> +<li><a href='#why_not_parse_nmea'>Why use the <code>gpsd</code> protocol rather than parsing raw NMEA?</a><br/> +<li><a href='#interfacing'>How should I interface my application with <code>gpsd</code>?</a><br/> +<li><a href='#agps'>Can GPSD use Assisted GPS data from cellphone networks?</code>?</a><br/> +<li><a href='#accuracy'>How can I improve fix accuracy from my GPS?</a><br/> +<li><a href='#time'>How can I improve time reference accuracy from my GPS?</a><br/> +<li><a href='#sleep'>Why does my GPS get lost when I sleep/wake my laptop?</a><br/> +<li><a href='#baud'>Why is there no option to fix baud rate?</a><br/> +<li><a href='#willitwork'>Will this GPS work? It's not on the hardware list.</a> +<li><a href='#nmea2000'>Does gpsd support NMEA2000?.</a><br/> +<li><a href='#conflict'>Why does GPSD interfere with non-GPS USB devices?</a></br> +<li><a href='#efficiency'>What is gpsd's CPU and power overhead?</a></br> +</ul> + +<h1 id='verify'>How can I verify operation of a new GPS?</h1> + +<p>1. First, check that the GPS has power. If it is a USB device, it +needs to be cabled to a USB port to have power. All Bluetooth GPSes +and some serial GPSes are powered by an on-board battery; check that +the battery is present and charged. The GPS may have an on-off switch +which needs to be in the 'on' position.</p> + +<p>2. Most GPSes have a power-on LED; it should be continuously on +or blinking once a second. If it is continuously off, your GPS is dead +or disconnected. Check that it has power.</p> + +<p>3. For anything other than a serial (RS232) device, there should be +a discovery utility that allows you to check that the device is connected.</p> + +<p>3a. For a USB device, run <code>"lsusb"</code> before and after +connecting your GPS; after, you should see an additional line +indicating a new device. Expect the new line to describe a +serial-to-USB adapter chip, often (but not always) the Prolific +Technology PL2303. Then run "dmesg", looking for a message indicating +a new USB device of that kind and giving you the device path - +<code>/dev/ttyUSBn</code> for some number n.</p> + +<p>3b. For a Bluetooth device, see our <a href="bt.html">Bluetooth +instructions</a>.</p> + +<p>4. If you have installed a GPSD binary package on a Linux system and +are using a USB GPS, you should not need to start gpsd manually, +because the hotplug system will have done it for you. You should be +able to start a test client (such as <code>cgps</code> or <code>xgps</code>) +and watch it report fixes.</p> + +<p>5. If your test client fails to run, a good test to try is to run +<code>gpsmon</code> on the device (give it the device path as an +argument). If yours reports no data at all, you probably have some +low-level system problem with serial or USB that you'll need to fix +before <code>gpsd</code> will operate.</p> + +<p>6. USB GPSes actually emulate RS232 serial using converter chips. +Under Linux, the usbserial kernel module must be loaded for correct +operation of this class of device. Normally this module load should +happen automatically when the device activates, but if you don't +receive data check for it with <b>lsmod(1)</b>.</p> + +<p>On Linux systems with module autoloading disabled or misconfigured, +it is possible you may need to load the module manually with a command +such as <code>sudo modprobe usbserial vendor=0×1a86 +product=0×7523</code>. Do not copy those hex numbers slavishly, they +are examples. To get the right numbers, you will need to dig up the +vendor and product ID of your USB-serial converter device.</p> + +<p>For more detailed troubleshooting instructions, <a +href="troubleshooting.html">see the Troubleshooting Guide</a>.</p> + +<h1 id='bug-reporting'>How do I report bugs in GPSD?</h1> +<blockquote> +<p>When you have a problem with gpsd, here are some steps you can take to +help get your bug resolved as quickly as possible.</p> + +<h3>1. Read this whole FAQ first</h3> + +<p>First, read this whole FAQ before reporting apparent misbehavior as a +bug. You may find a solution here.</p> + +<h3>2. Make sure it's not a problem with your toolchain or OS</h3> + +<p>See our page on <a href='upstream-bugs.html'>upstream bugs</a>.</p> + +<h3>3. Make sure it's not a problem in your client software</h3> + +<p>Make sure it is a real gpsd bug and not a problem with +your client software. A good way to do this is to run your client and +the gpsd test client (xgps) side by side. If xgps seems to report +good numbers but your client does not, you have a client problem. +If xgps reports the same sort of bad numbers as your client, you +have a real <code>gpsd</code> bug.</p> + +<h3>4. Check the latest version of <code>gpsd</code> for the bug.</h3> + +<p>If you are using an old version of <code>gpsd</code>, it is +possible your bug has already been fixed. Download the latest public +version from the <a href='@MAINPAGE@'>project page</a> and test it. +To be really helpful, check out the <a href='@REPOVIEW@'>git head</a> +and test that. We don't mind getting bug reports that say "I saw +version foo had the following bug, but you've fixed it."</p> + +<h3>5. Capture a log that triggers the problem</h3> + +<p>If we can reproduce your gpsd problem, we can usually fix it very +rapidly. If we can't reproduce it, you might get lucky or you might +not — and we try hard, but all too often the result is 'not'.</p> + +<p>Therefore the most important step you can take is to capture a log +of some receiver output that reproduces the bug; <code>gpscat</code> will +help you.</p> + +<h3>6. Trim the capture log that reproduces the problem</h3> + +<p>Your next step should be to feed the log you just captured to a +<code>gpsd</code> instance through <code>gpsfake</code> to verify that +the log does in fact reproduce the bug.</p> + +<p>Once you have the log, trim it to the smallest span of data that +reproduces the bug. A systematic way to do this is to cut the log in +half at the middle and test each half. If one half doesn't reproduce +the bug but the other does, throw away the half that doesn't. Repeat +this procedure on each half that tickles the bug until you can't make +it any smaller. Then send us that.</p> + +<p>If possible, use the -l option of gpsfake to pin down the sentence +or packet that produces the bug, and tell us that.</p> + +<h3>7. Look at <code>gpsd</code> log output to see if it gives you a clue</h3> + +<p>You may get a better handle on your problem by running gpsd in +foreground (-N option) with the -D option set to a high level (-D 5 is +often good). If the transcript has anything that looks like a clue +in it, send it along with your bug report. When in doubt about +whether it holds a clue, send it.</p> + +<p>One of the things this should tell you, if the chip reports it at +all, is the firmware version. You will want that for your report.</p> + +<h3 id="logformat">8. Annotate the capture log and send us a copy</h3> + +<p>We'll describe the annotation steps here for completeness, but the +easiest way to do this is with <a href="@WEBFORM">our web form</a> + +<p>A logfile should consist of an identifying header followed by a +straight unencoded dump of receiver data, whether NMEA or binary. The +header should consist of text lines beginning with # and ending with LF. +Here is the beginning of one log file I already have:</p> + +<pre> +# Name: Magellan eXplorist 210 +# Chipset: unknown +# Submitted-by: "Paul B van den Berg" <paulberg@wanadoo.nl> +# Date: 20 May 2006 +# Location: Groningen, NL, 53.2N 6.6E +# +# mode V2.1 GSA +# Lines up to but not including the first GPGLL are +# `cat /dev/ttyACM0` at startup +# Following lines are +# `cat /dev/ttyACM0` stationary +$GPGSV,3,1,00,,,,,,,,,,,,,,,,*7B +$GPGSV,3,2,00,,,,,,,,,,,,,,,,*78 +$GPGSV,3,3,00,,,,,,,,,,,,,,,,*79 +$PMGNST,01.75,3,F,816,11.1,+00000,20*5E +$GPGSV,3,1,00,,,,,,,,,,,,,,,,*7B +$GPGSV,3,2,00,,,,,,,,,,,,,,,,*78 +$GPGSV,3,3,00,,,,,,,,,,,,,,,,*79 +$PMGNST,01.75,3,F,816,11.1,+00000,20*5E +$GPGSV,3,1,00,,,,,,,,,,,,,,,,*7B +$GPGSV,3,2,00,,,,,,,,,,,,,,,,*78 +$GPGSV,3,3,00,,,,,,,,,,,,,,,,*79 +$PMGNST,01.75,3,F,822,11.2,+00000,20*5A +$GPGSV,3,1,00,,,,,,,,,,,,,,,,*7B +$GPGSV,3,2,00,,,,,,,,,,,,,,,,*78 +$GPGSV,3,3,00,,,,,,,,,,,,,,,,*79 +$PMGNST,01.75,3,F,822,11.2,+00000,20*5A +$GPGSV,3,1,12,09,76,287,,17,38,073,36,26,34,163,,05,33,230,*72 +$GPGSV,3,2,12,29,27,161,,18,24,256,,22,24,299,,28,11,055,*73 +$GPGSV,3,3,12,14,08,319,,11,03,017,,30,02,232,,24,00,084,*71 +$PMGNST,01.75,3,F,822,11.2,-00673,20*5E +$GPGLL,5313.2228,N,00634.4228,E,200619.295,A*35 +$GPGGA,200619.30,5313.2228,N,00634.4228,E,1,05,2.6,00000,M,,,,*2C +$GPRMC,200619.30,A,5313.2228,N,00634.4228,E,00.0,000.0,200506,00,W*59 +$GPGSA,A,3,26,05,22,09,18,,,,,,,,05.1,02.6,04.4*03 +$GPGSV,3,1,10,09,78,288,39,17,38,071,,05,34,230,45,26,33,163,39*77 +$GPGSV,3,2,10,29,26,162,,18,24,255,42,22,24,298,44,28,10,056,*75 +$GPGSV,3,3,10,14,09,319,,11,03,016,,136,27,157,,124,28,162,*71 +</pre> + +<p>The way to fill in the Name, Submitted-by, and Date +headers should be pretty obvious.</p> + +<p>Chipset should include the name and (if possible) model and/or +firmware revision of the chipset in the GPS.</p> + +<p>Please also include a Location header giving your city, +state/province, country code, and a rough latitude/longitude.</p> + +<p>A log file is most useful when it contains (a) some sentences +generated when the GPS has no fix, (b) some sentences representing +a fix with the GPS stationary, and (c) some sentences representing +a fix with the GPS moving.</p> + +<p>If you have notes or comments on the logfile or the GPS, or any +additional information you think might be helpful, add them as +additional # comments (not containing a colon) after these headers. +The test machinery that interprets the headers will ignore these and +any empty comment lines.</p> + +<h3>9. If it's a dual-mode GPS, see if the problem reproduces in NMEA mode</h3> + +<p>If you're using a SiRF, Evermore, iTalk or u-blox GPS in binary mode +(which you can tell from the -D 4 output), switch back to NMEA mode +using the N command (or a vendor-provided tool) and see if the bug is +still reproducible.</p> + +<h3>10. If your bug core-dumps gpsd, send us a stack trace.</h3> + +<p>Though it happens seldom (and we had 2 report since about mid-2005), +badly-formed input from a device with poor standards compliance has been +known to core-dump gpsd. If your gpsd has core-dumped, try to use gdb +or whatever your local symbolic debugger is to generate a stack trace +("bt full") of the crash, and send us that.</p> + +<h3>11. Try to determine what release introduced the bug</h3> + +<p>If you have upgraded from a previous version of <code>gpsd</code>, +and the upgrade broke something that was working previously, the +most useful thing you can do is pin down the release in which the +bug was introduced.</p> + +<p>How efficiently you can do this depends on whether or not you have +a client for the git version control system. If you don't, all +you can do is download and test named releases. If you do, you can +pin down the exact change that introduced the bug. The latter is +far more helpful to us and will get your bug fixed faster, so we'll +describe that procedure here.</p> + +<ol> +<li><p>Follow <a href='@CLONEREPO@'>these instructions</a> to clone +a copy of the source repository.</p></li> + +<li><p>Use <a +href="http://www.kernel.org/pub/software/scm/git/docs/git-bisect.html">git +bisect</a> to locate the exact revision that introduced your bug. +This will happen very quickly, as the number of tests required will be +the log to the base 2 of the number of revisions in your original +span. Even if there are (say) 500 revisions in the span you should +only require 9 tests to nail down the exact change in +question.</p></li> +</ol> + +<h3>12. Include the vendor, mode, and firmware version in your report.</h3> + +<p>Always include with your bug report the receiver vendor and model. Try +to include the firmware version as well. This should be in your xgps +display if your device makes it available; in a form field before +2.35, or as the window title in 2.35 and later. If the ID string is +too long to fit, let the daemon run for a few minutes and issue an "I" +command to it. Alternatively, running the daemon at -D 4 may reveal +the version.</p> + +<h3>13. Report it on the GPSD bugtracker</h3> + +<p>There is a <a +href="@BUGTRACKER">GPSD bug tracker</a>. +Use that. If your bug narrative does not fit the tracker template well, +it's acceptable to send an email report to the gpsd-dev list.</p> +</blockquote> + +<h1 id="startup">Why does getting a fix take so long after powerup?</h1> + +<p>On a Linux machine, the <code>gpsd</code> daemon normally takes +between 0.1 and 0.6 seconds to handshake with your hardware. After +that you will receive GPS reports within a second of when the sensor +issues them. GPSD itself adds <a href="performance.html">almost no +measurable latency</a>, but RS-232 transmission time to +<code>gpsd</code> can be more significant; you can cut this time by +increasing the baud rate.</p> + +<p>Longer handshake delays have been reported from other platforms. +Under OpenBSD, time to handshake with some binary GPSes (including +SiRFs) can be up to two minutes. This seems to reflect some bad +interaction between the autobauding code in <code>gpsd</code> and the +operating system's tty layer; when <code>gpsd</code> is compiled to +use a fixed port speed, handshake times drop to a fraction of a +second.</p> + +<p>If you are starting a GPS for the first time, or after it has been +powered off for more than two weeks, this is a 'cold start'; it needs +to get a new satellite ephemeris to do its job. The satellites +broadcast this information very slowly (at 50bps) on a fixed schedule, +and it can take up to 20 minutes.</p> + +<p>Warm start on a modern GPS with a good skyview (4 or more sats +visible) normally takes about 30 seconds. (Vendor spec sheets fib by +quoting this time only, leaving out the cold-start lag to fetch +ephemeris.) If it's taking longer, the first thing to suspect is that +your skyview is poor. Especially if you're indoors.</p> + +<p>The best advice is: go outside and be patient for a few minutes.</p> + +<h1 id="timelag">Why does GPS time lag wall time by 11-15 seconds?</h1> + +<p>Your GPS may have dropped its leap-second offset. You can tell you +have this problem if your sentence timestamps look wrong at startup. +Wait 20 minutes or so; the lag should go away.</p> + +<p>GPS satellites broadcast time using a clock without a leap-second +correction. They broadcast a leap-second correction once each complete +reporting cycle along with the satellite ephemerides; it's up to the +GPS firmware to add that correction to the time it puts in reports. +If your GPS has forgotten the current correction, you'll have to wait +until the next ephemerides message for it.</p> + +<p>GPSes are supposed to retain the leap-second correction along with +the last fix in NVRAM when they power down, but we've observed that +many seem prone to occasionally drop this information. All you can do +is wait for the problem to resolve itself.</p> + +<p>SiRF-based GPSes have a more specific timelag problem. 4800 is just +a bit too slow for SiRF binary at full flood; the device can actually +fail to ship all its reports before the next once-per-second fix, +producing an accumulating stall. The symptom of this is sentence times that +look right at startup but gradually fall behind clock time. To fix +this, bump your speed to 9600 or higher.</p> + +<h1 id='speed'>Why does my receiver report wildly fluctuating speed?</h1> + +<p>If your problem is wildly fluctuating speed reports on a SiRF, +switching on static navigation mode using <code>gpsmon</code>. Static +navigation mode will freeze your position if your speed is below 1.2 +m/s for three seconds, and will begin updating your position again +when speed exceeds 1.4 m/s. This prevents multipath, weak signals, or +poor constellation geometry from dragging your solutions around too +much. Other receivers may suffer the same problem and may have a +similar solution.</p> + +<h1 id='gpsdrive'>Why do I get implausibly low speeds when using gpsdrive?</h1> + +<p>This is a gpsdrive bug, as you can verify by running +<code>xgps</code> alongside it.</p> + +<h1 id='kismet'>Why do I get no results when I try to use <code>gpsd</code> with Kismet?</h1> + +<p>Your Kismet configuration has to include the setting +"gps=true" This is s a surprisingly easy detail to forget.</p> + +<h1 id='bluetooth'>Why do I have to restart <code>gpsd</code> whenever I power-cycle my Bluetooth device?</h1> + +<p>The Bluetooth stack returns 0 for a read from a missing device, +rather than -1, and doesn't set errno. This is wrong and needs to be +fixed at OS level.</p> + +<h1 id='lockup'>My <code>gpsd</code> sometimes stops responding overnight</h1> + +<p>At one point in the development of <code>gpsd</code> we got a +report of the daemon ceasing to respond to queries when run for +more than a day or so; the user, quite reasonably, suspected some sort +of resource leak in the daemon. On the other hand, other users reported +good operation over much longer periods with the same version of +the software. That suggests a bug at the level of the user's operating +system or local site configuration.</p> + +<p>Nevertheless, the possibility of a resource-leak bug alarmed us +enough that after 2.26 one of us (ESR) built an entire test framework +for auditing the code's dynamic behavior and used it to apply <a +href="http://valgrind.org">Valgrind</a>. You can look at the +resulting script, valgrind-audit, in the source distribution. This +turned up a couple of minor leaks, but nothing sufficient to explain +the report.</p> + +<p>One of our senior developers, Rob Janssen, has seen +<code>gpsd</code> interact badly with overnight backups, pushing the +system load average through the roof. He says: "when you copy many +gigabytes of data from disk to disk, the [Linux] kernel's buffer +management goes completely haywire. [...] I think this is caused both +by allocation of many buffers for reading files, and by accumulation +of many dirty buffers that still have to be written. At some point, +programs like gpsd (but also all interactive programs and the X +display manager) come to a complete standstill while the system is +swapping like mad."</p> + +<p>If Rob's analysis is correct, <code>gpsd</code> is a canary in a +coal mine. If your <code>gpsd</code> locks up after a long period of +operation, you should look at your logs and see if you can connect the +point at which it stopped responding to some kind of resource crisis +brought on by lots of I/O activity.</p> + +<p>Another thing to try is running <code>gpsd</code> under Valgrind overnight +and seeing if it reports any leaks.</p> + +<h1 id='why_not_parse_nmea'>Why use the <code>gpsd</code> protocol rather than parsing raw NMEA?</h1> + +<p>Some applications that use <code>gpsd</code> start raw mode +and parse the NMEA directly. This is not a good idea.</p> + +<p>One problem with raw mode is that NMEA is a poorly specified +standard. There are, for example, two different and incompatible +variants of GPVTG. Another issue is that implementations vary as to +whether they leave fields they don't supply empty or fill them in with +a special value such as 0.0. Interpretation of the different NMEA +status fields is a black art.</p> + +<p>It is all too easy to write an NMEA parser that works well on one +variant but breaks on another, delivering subtly incorrect results or +even crashing your application. Because <code>gpsd</code> specializes +in the job, we collect knowledge on all variants and do parsing that +is much less likely to get tripped up.</p> + +<p>Another issue is that some of the reports your application would +like to have are not generated by all GPSes. Estimated position error +in meters is the most obvious example; climb/sink is another. When a GPS +doesn't supply these, <code>gpsd</code> can fill them in using the +same sorts of computation that more capable GPSes use.</p> + +<h1 id='interfacing'>How should I interface my application with <code>gpsd</code>?</h1> + +<p>The <code>gpsd</code> package provides two ways for C code to get +data from a GPS or AIS receiver. Both go through the libgps.a library, +which supports two sets of entry points. The <a +href="libgpsd.html">low-level interface</a> talks directly to the GPS. +The <a href="libgps.html">high-level interface</a> communicates with +an instance of <code>gpsd</code>, which uses its own copy of libgps.a +to talk to the device.</p> + +<p>A third way would be to open a socket to <code>gpsd</code> and +interpret <code>gpsd</code> protocol or raw NMEA in your application. +Before 2.0, all <code>gpsd</code>-aware applications had to do this +because libgps.a didn't exist. Now that it does, the exercise is +rather pointless. Using libgps.a will probably simplify your code a +lot.</p> + +<p>You will almost always want to use the high-level interface and go +through the daemon; among other things, this means more than one +application will be able to query the GPS without causing confusion. +The only exception will be in very space-constrained single-user +scenarios, perhaps on embedded systems or PDAs. On those it may be +appropriate to use the low-level interface directly, probably with a +build from source that conditions out all but one of the drivers.</p> + +<p>For Python programmers, there is a gps.py module the high-level +interface. It exports a class that encapsulates a GPS session.</p> + +<h1 id='agps'>Can GPSD use Assisted GPS data from cellphone networks?</h1> + +<p>Sadly, no. There are both hardware and software barriers to this.</p> + +<p>Using AGPS would requires picking up and interpreting information +broadcast by cellphone towers, so it would at minimum need another +receiver (separate from the GPS mouse) operating in those frequency +bands. Of course, a cellphone has one of those built in. Standalone +GPS sensors don't.</p> + +<p>There's another level of the problem, too. Supposing we had the +right sort of receiver, AGPS systems are carrier-dependent. As far as +we know there aren't any published standards for the format of the +corrections. So even if we had the signals, GPSD couldn't know what to +do with them.</p> + +<h1 id='accuracy'>How can I improve fix accuracy from my GPS?</h1> + +<p>Use an antenna, and place the sensor (and/or antenna) properly.</p> + +<p>A real antenna can help, especially if you're using PPS as a time +reference. It should be particularly helpful for reducing timing +jitter.</p> + +<p>One common error is to place the GPS or antenna as high as +possible. This will increase <a +href="http://en.wikipedia.org/wiki/Global_Positioning_System#Multipath_effects">multipath +effects</a> due to signal bounce from the ground or water, which can +cause the GPS to mistake its position and the time signal. The +correct location for a boat GPS antenna is on the gunwale rail or +pushpit rail, close to the water and as far from the mast as possible +(to reduce signal bounce from the mast). If you're outside or in a +fixed location, put the GPS antenna as far from buildings as possible, +and on the ground. If you're in a car, don't put the GPS antenna on +the roof, put it on the towbar or some similar location.</p> + +<p>If you're driving in a heavily built up area, you're going to get +signal bounce off buildings and reduced accuracy. That's just how +the physics works. Note, however, that as your velocity goes up it +becomes easier for the convergence filters in your GPS to spot +and discard delayed signal, so multipath effects are proportionally +less important in fast-moving vehicles.</p> + +<p>If you're using <code>gpsd</code> with software that plots your +position on a map, and you seem to be getting latitude/longitude that +is at a fixed offset from reality, it is possible the base datum of +the map is something other than the WGS84 GPS uses. A +frequently-occurring case of this is older maps in the United States +based on NAD27 (e.g., USGS topo maps); you may see a displacement of +as much as 100-150m with respect to WGS84. While modern datums (e.g., +NAD83) are almost all very close to WGS84, typically each area of +world has an older datum that only agrees at the 100m level.</p> + +<h1 id='time'>How can I improve time reference accuracy from my GPS?</h1> + +<p>All the measures you'd take to improve <a href="#accuracy">fix +accuracy</a> will help. Time referencing at accuracies below +0.01sec has its own set of issues related to latency in your +sensor and computer.</p> + +<p>In particular, USB transport is not suited for anything +time-related that requires sub-millisecond accuracy. If a +USB-connected GPS unit wants to tell the computer it's 12:23:45, it +will have to wait for the computer to poll it. This polling happens +1000 times per second, introducing variable latency averaging a +half-millisecond. Furthermore, the USB chip might run at anything +close to 1000 Hz. If it runs at 1000.1 Hz, every 10th second the next +time-report will come 1 whole millisecond earlier. This will have NTP +observing something like a 1ms-high sawtooth in the time-reports.</p> + +<p>For accurate time reference, use a PPS line over RS232 triggering an +interrupt. Serial bus interrupt latencies on modern hardware on the +order of 10 microseconds, roughly a hundred-fold improvement over +USB.</p> + +<p>Don't confuse PPS with conventional, non-PPS data transport over +RS232; the latency on that is much higher. At one character per ten +bits (counting framing at stopbits) a 9600-bps serial link introduces +about a millisecond of latency <em>per character</em>; furthermore, +the Linux kernel will normally delay delivery of characters to your +application until the next timer tick, about every 4 milliseconds in +modern kernels. Both USB and RS232 will incur that approximately +5ms-per-char latency overhead.</p> + +<h1 id='sleep'>Why does my GPS get lost when I sleep/wake my laptop?</h1> + +<p>This is not a GPSD problem, but a result of the way Linux handles +USB serial devices. In a default Linux configuration, USB serial +device name do not depend on which physical port you plug the +USB/serial adaptor, but on what order you plug devices in: 1st device +gets /dev/ttyUSB0, 2nd gets /dev/ttyUSB1, etc.... + +<p>This collides with what happens during a suspend/resume. If you +suspends while <code>gpsd</code> has a device active, it will hold the +device open while your laptop is asleep - but, meanwhile, the suspend +logic is shutting down hotpluggable devices to be recreated at +resume time. On resume, Linux will see that the old device is open +<em>and recreate one with a different name</em>, leaving <code>gpsd</code> +looking at a bad file descriptor.</p> + +<p>There is a solution to this problem: create a stable gps-usb device +that is actually a symlink which gets modified by hotplug events, and +give <code>gpsd</code> that device when you invoke it. You'll need <a +href="70-persistent-usb-gps.rules">these replacement udev rules</a>, +and the experience required to patch them so the vendor ID in the last +one matches your GPS hardware (look in your lsusb output). + +<h1 id='web'>How do I get gpsd data into a web page?</h1> + +<p>The <code>gpsd</code> source-code distribution now includes a PHP +script that makes this easy. The script shows current fix data, a +satellite view, and can even incorporate a Google Maps display +if you have a Google API key. Look at the end of the file INSTALL for +instructions.</p> + +<p>Another way is to use a perl CGI script that leverages +Net::GPSD like this...</p> + +<code><pre> +#!/usr/bin/perl -w +use strict; +use Net::GPSD; + +my $g=new Net::GPSD; +my $p=$g->get; + +print qq{ +<?xml version='1.0'?> +<Report xmlns:gml="http://www.opengis.net/gml"> + <items> + <Item> + <ID>35643563245</ID> + <position> + <gml:Point srsDimension="2" +srsName="urn:ogc:def:crs:EPSG:6.6:4326"> + <gml:pos>}. $p->lat. " ". $p->lon. q{</gml:pos> + </gml:Point> + </position> + </Item> + </items> +</Report> +}; +</code> +</pre></code> + +<p>This will return something like:</p> + +<code><pre> +<?xml version='1.0'?> +<Report xmlns:gml="http://www.opengis.net/gml"> + <items> + <Item> + <ID>35643563245</ID> + <position> + <gml:Point srsDimension="2" srsName="urn:ogc:def:crs:EPSG:6.6:4326"> + <gml:pos>38.865960 -77.108624</gml:pos> + </gml:Point> + </position> + </Item> + </items> +</Report> +</pre></code> + +<h1 id='baud'>Why is there no option to fix baud rate?</h1> + +<p>There is no option to fix baud rate because <code>gpsd</code> is +designed to (a) be autoconfiguring, and (b) handle multiple devices. +There are some more philosophical reasons as well; read the +<a href="hacking.html">Hacker's Guide</a> for discussion.</p> + +<p>Unfortunately, this causes problems with some devices (notably +Bluetooth GPSes) that are designed to operate at fixed baud rates. +Some of these go catatonic if you try to set the baud rate, which is +why we have a -b option that prevents <code>gpsd</code> from trying to +configure the GPSes it talks to.</p> + +<p>On Linux systems, there's a trick you can play to simulate fixing the +baud rate. It utilizes the fact that under Linux, setting baud rate 0 +is interpreted as "use the hardware port's existing baud rate without +change". The autoconfiguring hunt loop in <code>gpsd</code> always starts +with this behavior.</p> + +<p>Accordingly, you can short-circuit the autobaud if you use stty(1) to set +the bit rate just before starting gpsd. For example, suppose you know that +your GPS is on serial port 0 and operates at a fixed bps of 54600. You +can set that up like this:</p> + +<code><pre> + stty speed 54600 </dev/ttyS0 + gpsd -nN /dev/ttyS0 +</pre></code> + +<h1 id='willitwork'>Will this GPS work? It's not on the hardware list.</h1> + +<p>Probably.</p> + +<p>Gpsd's support for the NMEA protocol is mature and stable. If the +specification for your receiver says "NMEA 0183" (maybe with a version 2.x +or 3.x qualifier) it should just work.</p> + +<p>Beware of receivers that do not say "NMEA" somewhere in the specification; +while it may indicate that the receiver only uses a binary protocol, it often +means that the receiver cannot be used as data source for a computer, as is +usually the case with car navigation devices.</p> + +<p>We also support many proprietary protocols, in case your receiver doesn't +emit NMEA. Datasheets often indicate which chip the receiver is based on, for +example a <i>NavCorp NX666</i>. Check to see if other <i>NavCorp</i> receivers +are listed, either as a vendor or a chipset. Compare this with the output of +<code>gpsd -l</code> which will list the protocols compiled into gpsd. If your +receiver doesn't support NMEA and we don't have special driver for the chipset, +talk to us. But it'll probably just work.</p> + +<p>Assuming the receiver has a USB interface, do a web search to see if someone +has tried it with linux already, eg. "<code>NavCorp NX666 linux</code>". Search +for the product and "driver install" to find instructions on installing windows +drivers for the product - these often hint at which bridge chip is used, if the +specifications don't say so. A receiver claiming mac compatibility is usually +based on one of the common bridge chips from FTDI, Prolific or Silicon +Laboratories. These just work.</p> + +<h1 id='nmea2000'>Does gpsd support NMEA2000?</h1> + +<p>The short answer is 'No'. The longer answer is 'Only if you have a +hardware adapter that down-converts it to NMEA 0183 or something else we +understand.' Such devices do exist, they're used to enable navigation +software using NMEA 0183 to NMEA 2000 boat networks.</p> + +<p>NMEA2000 is not a byte-stream protocol; it can't be shipped over +serial or USB links. It relies on a message-oriented physical layer +called Controller Area Network (CAN) that is widely used to network +automotive electronics. Without hardware mediation to map the +message into self-describing packets on a serial link, there's no +way gpsd will ever see these.</p> + +<h1 id='conflict'>Why does GPSD interfere with non-GPS USB devices?</h1> + +<p>Most USB devices have a defined <a +href="http://www.usb.org/developers/defined_class">device class</a> - +mass storage, video, hub, and human interface device are three of the +more common ones. Using GPSD will never interfere with such devices, +nor will they interfere with GPSD.</p> + +<p>Unfortunately, there is no device class for USB GPSes. Nor is there +a device class for USB-to-serial adapter chips. Both are assigned the +catch-all class 0xFF, "Vendor Specific". Every USB GPS we've ever seen +consists of a GPS module with TTL-level RS232 outputs connected to an +RS232-to-USB adapter chip, and presents the class ID 0xFF to your USB +subsystem.</p> + +<p>When you install GPSD, it puts in place rules that watch for +hotplug activation events from devices that might be GPSes. When such +a hotplug event happens, a <code>gpsd</code> instance is started (if +one is not already running) and puts a copy of the device path in an +internal stash list. Later, if a client application requests GPS data, +<code>gpsd</code> will try to read from the device, and discard it +from the stash list if it is not emitting data that <code>gpsd</code> +recognizes.<p> + +<p>GPSD's notion of "might be a GPS" depends on the fact that all USB +GPSes are made with one of a small number of USB-to-serial adapter +chips, the most common of which is the Prolific Logic 2303. GPSD's +hotplug rules expect that anything exhibiting the USB vendor:product +ID pair of one of these chips will be a GPS.</p> + +<p>A problem can arise if you have other devices connected to your +system through one of these specific adaptor chips. When these +activate, the GPSD hotplug rules will believe they are GPSes, and +<code>gpsd</code> will try to read from them when a GPS-ware client +application requests data. We've had reports of this happening with +USB modems and various microcontroller kits. It's not a problem we can +solve with clever programming, the devices simply don't yield +enough information about themselves to avoid conflicts.</p> + +<p>Under Linux, <code>gpsd</code> at 3.1 and later versions checks +each serial and USB device after opening it to see if any other +process has that device open; if so, it'd dropped. This should at +least keep GPSD from usurping data sources belonging to other service +daemons.</p> + +<p>If this sort of conflict becomes a problem, you can work around +it by disabling the GPSD hotplug rules. Unfortunately, this means +you will have to start <code>gpsd</code> manually with a device-path +argument when you want to use a GPS.</p> + +<h1 id='efficiency'>What is gpsd's CPU and power overhead?</h1> + +<p>The daemon, <code>gpsd</code>, is designed to run light so it can be +used in low-power embedded-systems deployments. Data throughput from GPSes +and other navigational sensors is low and tends to be concentrated in bursts +at about one-second intervals; accordingly, <code>gpsd</code> spends most +of its time simply waiting in select(2) at effectively zero CPU cost. Even +with a client session and a GPS active, we have measured gpsd's CPU load +at steadily less than 1% on a low-power, low-speed ARM SBC.</p> + +</div> +<hr/> +<script language="JavaScript" src="datestamp.js" type='text/javascript'></script> +</body> +</html> |