ademant
/
gpsd


			
				
					
						
						
							1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859606162636465666768697071727374757677787980818283848586878889909192939495969798991001011021031041051061071081091101111121131141151161171181191201211221231241251261271281291301311321331341351361371381391401411421431441451461471481491501511521531541551561571581591601611621631641651661671681691701711721731741751761771781791801811821831841851861871881891901911921931941951961971981992002012022032042052062072082092102112122132142152162172182192202212222232242252262272282292302312322332342352362372382392402412422432442452462472482492502512522532542552562572582592602612622632642652662672682692702712722732742752762772782792802812822832842852862872882892902912922932942952962972982993003013023033043053063073083093103113123133143153163173183193203213223233243253263273283293303313323333343353363373383393403413423433443453463473483493503513523533543553563573583593603613623633643653663673683693703713723733743753763773783793803813823833843853863873883893903913923933943953963973983994004014024034044054064074084094104114124134144154164174184194204214224234244254264274284294304314324334344354364374384394404414424434444454464474484494504514524534544554564574584594604614624634644654664674684694704714724734744754764774784794804814824834844854864874884894904914924934944954964974984995005015025035045055065075085095105115125135145155165175185195205215225235245255265275285295305315325335345355365375385395405415425435445455465475485495505515525535545555565575585595605615625635645655665675685695705715725735745755765775785795805815825835845855865875885895905915925935945955965975985996006016026036046056066076086096106116126136146156166176186196206216226236246256266276286296306316326336346356366376386396406416426436446456466476486496506516526536546556566576586596606616626636646656666676686696706716726736746756766776786796806816826836846856866876886896906916926936946956966976986997007017027037047057067077087097107117127137147157167177187197207217227237247257267277287297307317327337347357367377387397407417427437447457467477487497507517527537547557567577587597607617627637647657667677687697707717727737747757767777787797807817827837847857867877887897907917927937947957967977987998008018028038048058068078088098108118128138148158168178188198208218228238248258268278288298308318328338348358368378388398408418428438448458468478488498508518528538548558568578588598608618628638648658668678688698708718728738748758768778788798808818828838848858868878888898908918928938948958968978988999009019029039049059069079089099109119129139149159169179189199209219229239249259269279289299309319329339349359369379389399409419429439449459469479489499509519529539549559569579589599609619629639649659669679689699709719729739749759769779789799809819829839849859869879889899909919929939949959969979989991000100110021003100410051006100710081009101010111012101310141015101610171018101910201021102210231024102510261027102810291030103110321033103410351036103710381039104010411042104310441045104610471048104910501051105210531054105510561057105810591060106110621063
							<!DOCTYPE HTML>
<html lang="en">
<!-- @MASTER@ -->
<head lang="en">
   <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
   <meta name="Author" content="Eric S. Raymond">
   <meta name="Description" content="GPSD Frequently Asked Questions">
   <meta name="Keywords" content="GPS,gpsd,FAQ,frequently asked questions,android,garmin,raspberry pi,fix">
   <meta name="revised" content="@DATE@">
   <meta name="robots" content="index,follow">
   <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" height="126"
    width="105"><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>&nbsp;</div>

    <a href='http://www.catb.org/hacker-emblem/'><img
    src='glider.png' alt='hacker emblem' height="55" width="55"></a><br>

    <script src="https://www.openhub.net/p/3944/widgets/project_thin_badge.js"></script>

    <hr>
    <script><!--
    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
      src="https://pagead2.googlesyndication.com/pagead/show_ads.js">
    </script>
    <hr>

    <a href="https://validator.w3.org/check/referer"><img
          src="https://www.w3.org/Icons/valid-html401"
          alt="Valid HTML 4.01!" height="31" width="88"></a>
</div>

<div id="Content">

<ul>
  <li>Troubleshooting GPSD: the basics
  <ul>
    <li><a href='#verify'>How can I verify operation of a new GPS?</a></li>
    <li><a href='#willitwork'>Will a GPS not on the GPSD hardware list work?</a></li>
    <li><a href='#android'>Android reports that gpsd is draining my battery. Help!</a></li>
    <li><a href='#garmin'>My Garmin USB GPS doesn't work.</a></li>
    <li><a href='#agps'>Can GPSD use Assisted GPS data from cellphone networks?</a>
    <li><a href='#raspberry'>Time is wrong on my Raspberry Pi</a></li>
  </ul>
  </li>
  <li>Licensing and support
  <ul>
    <li><a href='#bug-reporting'>How do I report bugs in GPSD?</a></li>
    <li><a href='#support'>What support channels does GPSD have?</a></li>
    <li><a href='#license'>What is the license of GPSD?</a></li>
    <li><a href='#commercial'>Can I use GPSD in commercial products?</a></li>
  </ul>
  </li>
  <li>GPS performance
  <ul>
    <li><a href='#startup'>Why does getting a fix take so long after powerup?</a></li>
    <li><a href='#timelag'>Why does GPS time lag wall time by 11-15 seconds?</a></li>
    <li><a href='#timelag2'>Why is my GPS time off by exactly one second?</a></li>
    <li><a href='#speed'>Why does my receiver report wildly fluctuating speed?</a></li>
    <li><a href='#accuracy'>How can I improve fix accuracy from my GPS?</a></li>
    <li><a href='#time'>How can I improve time reference accuracy from my GPS?</a></li>
    <li><a href='#waas'>How can I tell if SBAS Augmentation (eg WAAS/EGNOS) is working?</a></li>
  </ul>
  </li>

  <li>Problems with specific applications
  <ul>
    <li><a href='#gpsdrive'>Why do I get implausibly low speeds when using gpsdrive?</a></li>
    <li><a href='#kismet'>Why do I get no results when I try to use <code>gpsd</code> with Kismet?</a></li>
  </ul>
  </li>

  <li>Troubleshooting GPSD: advanced topics
  <ul>
    <li><a href='#baud'>What about serial port speed (baud rate)?</a></li>
    <li><a href='#conflict'>Why does GPSD open non-GPS USB devices?</a></li>
    <li><a href='#efficiency'>What is gpsd's CPU and power overhead?</a></li>
    <li><a href='#usblockup'>My USB port becomes unavailable after gpsd uses it.</a><li><a href='#lockup'>My <code>gpsd</code> sometimes stops responding overnight</a></li>
  </ul>
  </li>

  <li>Application development with GPSD
  <ul>
    <li><a href='#why_not_parse_nmea'>Why use the <code>gpsd</code> protocol rather than parsing raw NMEA?</a></li>
    <li><a href='#interfacing'>How should  I interface my application with <code>gpsd</code>?</a></li>
    <li><a href='#almanac'>How can my application get almanac/ephemeris/pseudorange data?</a></li>
  </ul>
  </li>

  <li>Linux issues
  <ul>
    <li><a href='#bluetooth'>Why do I have to restart <code>gpsd</code> whenever I power-cycle my Bluetooth device?</a></li>
    <li><a href='#sleep'>Why does my GPS get lost when I sleep/wake my laptop?</a></li>
  </ul>
  </li>
</ul>

<p>If none of these FAQs seems to address your problem, look at the <a
href="upstream-bugs.html">Upstream Bugs</a> page.</p>

<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. If your receiver lists in lsusb(1) but doesn't show up as a ttyUSBx
device, don't lose hope.  It might be a ttyACM device, probably
/dev/ttyACM0; some receivers, including for example the u-blox EVK 6H
evaluation kit, announce themselves as USB modems.</p>

<p>3c. 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,
after stopping any instances of gpsd that are running
(eg, <code>killall gpsd</code> ),
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=0x1a86
product=0x7523</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='willitwork'>Will a GPS not on the GPSD hardware list work?</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 a 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.

<p>A GPS receiver claiming Macintosh compatibility is usually based on
one of the common bridge chips from FTDI, Prolific or Silicon
Laboratories. These will just work.</p>

<h1 id='android'>Android reports that gpsd is draining my battery.  Help!</h1>

<p>Yes, Android 4.0 and later versions use gpsd to interpret the data
stream from the onboard GPS.  No, the battery drain is not actually
due to a GPSD bug or design error.</p>

<p>You probably have a badly-written or buggy app installed that is
running in background, keeping gpsd awake by keeping a client session
to it constantly open; this can happen if the app is using "Fine
Location" rather than computing its location the cheaper way using
cell-tower signal strengths ("Coarse Location").  What you need to
do is identify that app, and decide if you wish to remove it.</p>

<p>On the Samsung Galaxy SIII, vendor firmware provides a "Remote
Location" service with a similar bug. You can disable this through
Settings.  See <a
href="http://www.gadgethelpline.com/gpsd-stop-samsung-galaxy-siiis-battery-life/">this
blog post</a> for a fix.</p>

<h1 id='garmin'>My Garmin USB GPS doesn't work.</h1>

<p>Garmin binary protocol is weird enough that it can't be handled
through the regular serial-device layer of Linux - you couldn't tell
where the packet boundaries are. To deal with it, you need a special
loadable kernel module called 'garmin_gps'.</p>

<p>The most common cause of problems with these devices is that the
module is failing to load as it should when the Garmin USB ID is
recognized. Here is a typical resolution:</p>

<blockquote>
After several more days of effort I did eventually get it to work
[under Ubuntu 12.4]. It turned out that garmin_gps was on the black
list and this needed to be commented out. I then had to 'sudo apt-get
install gps-clients gpsbabel' and a 'sudo modprobe garmin_gps' and all
was working.
</blockquote>

<p>On the BSDs and Mac OS X, you're out of luck. As of April 2013 we
don't know of any shim that makes USB Garmins work on these.</p>

<h1 id='raspberry'>Time is wrong on my Raspberry Pi</h1>

<p>The Raspberry Pi has no real-time clock.  Without this, the GPS may
not return sufficient information to for GPSD to pin down which GPS
clock rollover period you are in.  If you set the system clock to
some date in the current year <em>before</em> launching gpsd you
will see correct time reports.</p>

<h1 id='bug-reporting'>How do I report bugs in GPSD?</h1>

<p>Note: Because we have been informed that some people are insane
about this, we shall state the obvious: we welcome security-related
bug reports and will <em>not</em> sue people who send them to us.  If
your report includes sensitive information or discloses an exploit,
please email the maintainer rather than letting it all hang out on
the public bugtracker. We will fix such bugs promptly.</p>

<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>

<blockquote>
<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='@DOWNLOADPAGE@'>download page</a> and test it.
To be really helpful, check out git head
and test that.  We don't mind getting 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 &mdash; 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>

<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
# Submitter: "Paul B van den Berg" &lt;paulberg@wanadoo.nl&gt;
# Date: 2006-05-26
# 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, Submitter, 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 (we've had only 3 such reports 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>

<p>Very occasionally we have also received reports of core dumps in
gpsfake and gpson.  A stack trace is also useful in those cases.</p>

<p>A good technique in all such cases is to try to reproduce the bug
by feeding a log with the bad packet in it to gpsdecode.  This utility
exercises the same packet decoders as gpsd/gpsfake/gpsmon but without
involving nearly as much other code.  If you can send a test log that
crashes gpsdecode, you can expect the bug to be fixed very quickly.</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='https://help.github.com/en/articles/cloning-a-repository'
>these instructions</a> to clone
a copy of the source repository.</p></li>

<li><p>Use <a
href="https://mirrors.edge.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>

<p>In 3.10 and newer versions, runing gpsctrl with your GPS's device
path as an argument will produce a report that includes both the GPS
type and subtype, if that information is available at all.</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 and
you've done these data-gathering steps, it's acceptable to send an
email report to the <a href="mail:@DEVMAIL@">GPSD developers'
list</a>.</p>
</blockquote>

<h1 id='support'>What support channels does GPSD have?</h1>

<p>If you are submitting a code patch or a technically detailed bug
report, write the <a href="mail:@DEVMAIL@">GPSD developers'
list</a> (and see the previous entry on how to report bugs).</p>

<p>Please do <em>not</em> write to the dev list unless you are willing
to actively work with our developers on a solution. If you are
non-technical and confused, the <a href="mail:@USERMAIL@">GPSD users'
list</a> will be more appropriate.</p>

<p>GPSD developers are often, though not predictably, available in
real time <a href="@IRCCHAN@">on IRC</a>.</p>

<p>Commercial users: senior GPSD developers are available for contract
engagements at reasonable rates. If you have a hard problem or a tight
deadline or both, request an engagement via the dev list or IRC. We're
professionals and experts and we deliver results.</p>

<h1 id="license">What is the license of GPSD?</h1>

<p>Most of GPSD is under the permissive BSD license.  Some portions
are under other permissive licenses, including the MIT/X license and
the ISC license.</p>

<h1 id="commercial">Can I use GPSD in commercial products?</h1>

<p>Yes, GPSD code can be used in commercial and for-profit deployments
without restrictions.</p>

<p>If you use GPSD to make money, please show some concern for the project's
sustainability; @TIPLINK@.</p>

<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, but this can
vary widely.  After
that you will receive GPS reports within a second of when the sensor
issues them.  GPSD itself adds <a href="/performance/performance.html"
>almost nomeasurable latency</a>, but RS-232 transmission time to
<code>gpsd</code> can be more significant; you can cut this time by
increasing the serial port speed (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 a few weeks, this is a 'cold start'; it needs
to get a new satellite <i>almanac</i> 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>Without an almanac, your GPS has trouble finding the satellites.
The satellites broadcast on a known frequency, but they are moving,
and that gets shifted all over the place by the Doppler effect.  ("All
over" means a big shift relative to the bandwidth of the signal.)</p>

<p>If you have a recent almanac and you know the date/time and location, then
you can compute the Doppler and look in the right frequency and find the
satellites quickly.  In this context, "find" means hearing a signal at an
expected frequency.  If you don't hear anything where you expect it, then you
get to check nearby frequencies.  If you don't find anything nearby, you get
to give up and start searching the whole Doppler range.  This is the difference
between warm start and cold start.</p>

<p>Once you do see one or more satellites, you can figure out the
date/time and location and after a while get a new almanac. This will
be stored in non-volatile memory in your devices and make subsequent
satellite acquisitions faster, until it gets stale.</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
almanac.) 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, as the almanac is updated.</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 almanac; 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 an updated almanac is downloaded (should be less than 20 minutes).</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="timelag2">Why is my GPS time off by exactly one second?</h1>

<p>This can happen if (a) there has been a recent <a
href="ftp://maia.usno.navy.mil/ser7/tai-utc.dat">leap-second
adjustment</a>, (b) you have a version of GPSD that was built before
the adjustment, and (c) your GPS doesn't ship the current leap-second
offset in a form GPSD can see.  If this happens, GPSD will fall back
to a compiled-in default that is off by one</p>

<p>Some SiRFs have a particularly insidious version of this.  They are
supposed to ship a MID52 sentence (which GPSD knows how to interpret)
containing the current leap-second offset.  But there is at least one
firmware revision that ships a damaged version of MID52 with a garbled
start sequence or a zero length field.  GPSD cannot handle this.</p>

<p>The bad revision is 2.3.2-GSW2-2.05.024-C1Prod1.1; there may be
others.  Suspect this if you have persistent off-by-one errors. If you
are able to identify other bad firmware versions, please let us
know about it.</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,
switch on static navigation mode using the <code>M</code> command in
<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='accuracy'>How can I improve fix accuracy from my GPS?</h1>

<p>Use an external antenna, and place the sensor (and/or antenna) properly.</p>

<p>A good 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="https://en.wikipedia.org/wiki/Error_analysis_for_the_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, far forward on the dashboard, 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>There is now a <a href="gpsd-time-service-howto.html">GPSD Time
Service HOWTO</a> that gives detailed setup instructions.</p>

<h1 id='waas'>How can I tell if SBAS Augmentation (eg WAAS/EGNOS) is working?</h1>

<p>The earliest SBAS systems were WAAS (North America) and EGNOS
(Europe).  Multiple such systems exist, covering Japan (MSAS),
India (GAGAN), etc, with more being deployed.</p>

<p>In your skyview, look for GPS sats with numbers 120 and above;
those are the Space Based Augmentation System (SBAS) birds. For U.S.
users 138 is the most likely PRN to show up.
If your GPS receiver can see them at all, it can probably use them
for correction when you're within the coverage area of a
SBAS. But you can't be sure of this unless
they're marked as part of the satellite set for a fix. On the other
hand, some receivers may use them <em>without</em> marking the SBAS
satellites as part of the fix set. Vendor documentation in this area
tends to be murky or nonexistent.</p>

<p>If your receiver emits the NMEA GGA sentence, look at field 6 right
after the E or W qualifier for the latitude.  This is the GPS fix
quality indicator field. 2 indicates that the receiver is getting and
using differential-GPS corrections.  On a consumer-grade GPS this
usually means SBAS is in use.</p>

<p>Unfortunately, the mere presence of "WAAS" in your receiver's
feature list is not a guarantee that WAAS is actually supported.  This
feature causes significant additional power usage, and OEMs sometimes
condition it out of their firmware builds without documenting that
fact.</p>

<p>It has been found that while SiRF-II chips generally had WAAS
working, SiRF-III support varies by firmware level.</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='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 a surprisingly easy detail to forget.</p>

<h1 id='baud'>What about serial port speed (baud rate)?</h1>

<p>The <code>gpsd</code> code is designed to be autoconfiguring for both
static and hot-plugged devices.  The <code>gpsd</code> command line
options are only for problem solving or odd configurations.</p>

<p>One common problem is GNSS receivers that operate over Bluetooth.
Changing the speed of these is difficult to impossible.  Some go
catatonic if you try to change the serial port speed 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>Another problem is that some systems may have long autobaud detection
times, or be set to impossible to detect framing, like 8O1.
On most systems, simply set the speed and framing before calling
<code>gpsd</code> and <code>gpsd</code> will try those settings first.
This works for both devices specified on the <code>gpsd</code> command
line and those hot-plugged with <code>gpsdctl</code>.</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>

<pre><code>
        stty -F /dev/ttyS0 speed 54600
        gpsd -n /dev/ttyS0
</code></pre>

<p>If you have a Trimble that needs 115200 and 8O1, do this:</p>

<pre><code>
        stty -F /dev/ttyS0 speed 115200 parodd
        gpsd -n /dev/ttyS0
</code></pre>

<p>If you only have one device connected to <code>gpsd</code> and
that device is specified on the command line, then you can instead
specify the speed with the -s [SPEED] option and/or the framing
with the -f [FRAMING] option.</p>

<p>For more details and discussion about autobaud refer to the
<a href="hacking.html">Hacker's Guide</a>.</p>

<h1 id='conflict'>Why does GPSD open non-GPS USB devices?</h1>

<p>Most USB devices have a defined <a
href="https://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". Almost 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. The only exceptions we know of are some u-blox modules that
pretend to be USB modems.</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's dropped.  This should at
least keep GPSD from usurping data sources belonging to other service
daemons.</p>

<p>Note that GPSD never tries to configure USB devices until it has
identified them as sensors of a known type. Also, it tries to open with
TIOCEXCL and thus will not open devices that another process already
has open. So the worst case is a race between GPSD and another process
to open a device not in use, in which the other process's open fails.</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>

<h1 id='usblockup'>My USB port becomes unavailable after gpsd uses it.</h1>

<p>Occasionally we get a bug report from a user who says a USB port
locks up or becomes unavailable after <code>gpsd</code> has closed it.
Such problems may persist until the USB port is unplugged and
replugged, or until all devices in that root hub are unplugged and
replugged, or even until a reboot.</p>

<p>This is not a GPSD bug.  Bugs in the serial-device layer of your
operating system, tickled by gpsd's unusual autobauding loop and
serial-parameter changes, can cause problems like this. They may be
driver-specific bugs, or they may be due to bad interactions between
ioctl() and select() in the kernel's generic tty code. Bugs in the USB
chipset on your motherboard or in a hub can do it, too.</p>

<p>Here are some possible fixes:</p>

<dl>
<dt><b>1. Suppress the autobauding loop</b></dt>
<dd>The autobauding hunt loop in <code>gpsd</code> stresses chipsets and
drivers in unusual ways, which is why these sorts of bugs show up more
often under <code>gpsd</code> than most other USB-using software.  The first
thing to try is to <a href="#baud">suppress the autobauding loop</a>.</dd>

<dt><b>2. Upgrade your kernel</b></dt>
<dd>Upgrading your kernel may help. Obscure tty-layer kernel bugs pop
up relatively often and are usually fixed pretty quickly.</dd>

<dt><b>3. Try a different USB-to-serial chip</b></dt>
<dd>Another thing to try is a GPS with a different USB-to-serial chip.
You probably do not have a a chip-specific problem if you're using
a PL23203, as those drivers have been tested a lot.  But we've seen
reports that were definitely chip-specific on less common chipsets
such as FTDI. The CP210x chips are also known to be problematic,
mainly because the vendor refused to release enough programming
information to allow a decent open-source driver to be written.</dd>

<dt><b>4. Replace your USB hub</b></dt>
<dd>Some USB hubs are flaky. You may need to replace yours.</dd>
</dl>

<p>When you have had such a problem with <code>gpsd</code>, and are
able to work around it or fix it, please inform us so we can
improve this FAQ.</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="libgps.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='almanac'>How can my application get almanac/ephemeris/pseudorange data?</h1>

<p>Sorry, there's no easy way to do these things through GPSD yet.
The reason is that there is no consistent way to make GPS receivers
report this information.</p>

<p>Many don't ship it at all.  Others (including some but not all
devices shipping SiRF binary packets) ship it occasionally in SUBFRAME
information, but you have to know exactly how to grovel through the
SUBFRAME fields to get it and the documentation of those in
IS-GPS-200E (the over-the-air protocol used by GPS satellites) is
extremely obscure.  Still others report varying subsets of
almanac/ephemeris/pseudorange data in reasonably straightforward ways,
but in vendor-proprietary sentences that are extremely specific to
individual receiver types, poorly documented or undocumented, and
often needing to be activated by control sequences that are equally
specific and even worse documented.</p>

<p>We'd like to do a better job of extracting this information, but
handling all the potential variations would be an extremely difficult
and messy job.  It's hard to know what to do, and even harder to know
how to test the correctness of the extraction code once you think you
have it. The spectacularly bad design and documentation of most
vendor-specific GPS reporting protocols is at its abysmal worst in
this exact area.</p>

<p>On a SiRF-based device you might be able to get some use out of
the SUBFRAME JSON.  If you succeed in extracting
almanac/ephemeris/pseudorange data from those raw fields, we salute
you - and please share that code with us!</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='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>

<p>This collides with what happens during a suspend/resume. If you
suspend 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).</p>

<hr>
<script src="datestamp.js"></script>
</div>
</body>
</html>