Xgps

[Millicent]

Included in the package is a sample client called xgps. Itconnects to a gpsd at any host you tell it to, andrequests raw data, so that it can display the current location of allvisible GPS satellites your receiver 'sees'.

The next image shows a good fix. A 3d fix provides latitude, longitudeas well as altitude data, and requires at least four good satellites. A2d fix does not give altitude, but only requires 3 satellites.

gpsd is a GPS service daemon for Linux, OpenBSD and Mac OS X. There's also a Windows version. It can connect to GPS receivers via serial, USB port, Bluetooth, or via another gpsd through the network (TCP/IP connection). Many mapping and map viewing application use it, for example FoxtrotGPS, Marble, Merkaartor, QLandkarteGT, TangoGPS and Viking. Also some navigation applications like GpsDrive, Gosmore, Navit and ShareNav can use it to show current position on map on a laptop computer.

xgps is a simple test client for gpsd with an X interface. It displays current GPS position/time/velocity information and (for GPSes that support the feature) the locations of accessible satellites.

xgps is a simple sample client for gpsd with an X interface. It displays current GNSS position/time/velocity information and (for GNSS receivers that support the feature) the locations of accessible satellites.

In the sky view, satellites are color-coded to indicate quality of signal, consult the data display to the left for exact figures in dB. Diamond-shaped icons indicate GLONASS satellites, squares are used for SBAS (e.g. WAAS, EGNOS), circles indicate GPS, and down-, up-, right-, and left-pointing triangles, respectively, indicate Galileo, BeiDou, QZSS, and other systems' satellites (e.g. IMES, IRNSS, as well as unknown systems). Filled icons were used in the current fix, outline icons were not. Hovering over a symbol with the mouse pointer will temporarily display a small popup window with the satellite details from the Satellite List pane.

Set the format of latitude and longitude reports. The value 'd' produces decimal degrees and is the default. The value 'm' produces degrees and decimal minutes. The value 's' produces degrees, minutes, and decimal seconds.

By default, clients collect data from the local gpsd daemon running on localhost, using the default GPSD port 2947. The optional argument to any client may override this behavior: [server[:port[:device]]]

The XGPSOPTS> environment variable may be set to pass commonly used command line options to xgps. This is often used to set the -u option for locale specific units. XGPSOPTS is processed before the CLI options.

The -u option can be used to set the system units for display; follow the keyword with 'i' for 'imperial' for American units (International Feet in altitude and error estimates, miles per hour in speeds), 'n' for 'nautical' (feet in altitude and error estimates, knots in speed) or 'm' for 'metric' (meters in altitude and error estimates, kilometers per hour in speeds).

LC_MEASUREMENT and then LANG are checked if no unit system has been specified on the command line, in XPGSOPTS or in GPSD_UNITS. If the value is 'C', 'POSIX', or begins with 'en_US' the unit system is set to imperial. The default if no system has been selected defaults to metric.

As the other projects I have lined up for it is to connect my Meade LX200GPS telescope to the local network or to work with my (in prototype) radio telescopes so having an accurate clock is going to be required.

Now the obvious solution here is to use GPS as a time source. GPS works by having a constellation of satellites in orbit and each one carries a highly accurate atomic clock & broadcast both their current position and the time. A GPS receiver then receives these signals and, as long as it has enough satellites and workout where you are by comparing the times from those clocks.

Now we have a working GPS we can now get the PI to use it for setting the time. To do this we need to configure ntp to use the GPS satellites as a time source. Now you should already have ntp installed but if not then you need to install it:

I was just joking with a friend that a NTS server could not only be made with any old computer that could take a GPS but probably even a Raspberry-PI; then I used Google searching on Raspberry-Pi UPS & GPS. Wow!

Saying that it is possible to get that resolution & the pi comes into its own here as you can get gps receivers in component form which you could build a unit for under 15. On ebay theres a UK seller (Brighton) selling some gps receiver chips for 5. These chips support SPI so you can get the pi to talk directly with the receiver. With that and a little programming you could then get millisecond accuracy.

I have same module from Maplin and have tried all your steps. It all works up until the ntpq results. Its just not getting data from the gpsd side I think. Tried restarting gpsd and ntp etc and tried wheezy and Adafruits distro, both give same results. Still its kept me busy for a Sunday evening.

Yes gps fix side works fine, it would make a nice gps display/logger.
I assume the problem lies in ntp getting the data from the shared memory port.
I have a serial gps with a 1pps output somewhere and when I find it will try that on the gpio port.

hi
great article. how stable does NTP report this to be as a reference clock? I can see you have added a fudge factor of 183 milliseconds in an attempt to line the source up with internet sources. I guess the dongle outputs the serial data somewhat late, which is not a problem in itself, but the stability of that latency is critical. the would you have any thoughts on how stable this really is? my guess is the dongle will have hiccups when constellations change, causing delays in the nmea output, which in turn make ntp somewhat unstable.
I am yet to get my hands on my pi, but cant wait to give this a spin

Most USb GPS dongles do not connect the 1PPS to any of the appropriate lines in the UART-USB chip so they are strictly NEMA devices if left unmodified. In theory one could connect a tiny wire from the appropriate wire on the GPS module to the appropriate line on the UART to USB chip so that the emulation of a serial port device would include the DCD or similar 1PPS signal. But the accuracy of the timing would still be dependent on the latency of the USB connection which would mean not so great. Has anybody been able to utilize a kernel 1PPS on the Raspberry Pi? That would be very nice because the inexpensive RPI is fast enough to be a nice NTP server. You could disconnect the GPS chip from the UART-USB and connect the GPS directly to the RPI through the UART interface for the ASCII and use a GPIO for the 1pps

Thanks for your comments. The only problem with the USB device appears to be initial recognition, and if you have Internet NTP servers for the coarse seconds then the PPS is recognised and used to discipline the NTP server. The u-blox device which is serial rather than USB serial showed some slight oscillations during initial tests which I need to investigate further, but it still well within 10 microseconds.

Hi, I have the same GPS as you (25). I am having problems with the first step. I havnt used any of this stuff before and only used windows. I have downloaded gspd software and put it on a usb memory stick and it is connected to the internet. When i first started it did some processing lines then asked if i wanted to use up some space on the SD card it then said problem connecting to websites. so after then connection to the internet it comes up with E: error. any ideas? where do i put the dowloaded files? (taken from here and using the latest update)

statistics loopstats peerstats clockstats
filegen loopstats file loopstats type day enable
filegen peerstats file peerstats type day enable
filegen clockstats file clockstats type day enable

With Raspbian, there is a file /etc/fake-hwclock.data which has the current data and time, updated every so often. I understand that file is used early in the boot process to initialise the system time. There are a few folk reporting GPS issues, with receivers with various firmware, when the date gets within 500, 512 or 768 weeks of a roll-over event. Having a Internet pool servers should help resolve any ambiguity.

I am designing a GPS tracker which will be used to get a distance between two point. I am using Arch linux arm for raspberry pi model b. I am planning to get the data in a file every second and use lat and long parameter to calculate distance with hoversine formula.
my main problem is how to get the data in file instead of gui

Now, if I comment out the other servers (server 0.north-america.pool.ntp.org and so on).and restart ntp service, then neither PPS nor GPSD show any data in the query, only zeroes. In other words, without those external servers, NTP is not working as standalone.

As I already replied to your direct e-mail., likely this is because you are not waiting long enough for the GPS receiver to download the offset between UTC and GPS time. A battery backup for the GPS receiver may help. Please see:

With this article, I was finally able to get gpsd, gpsmon, and cgps all running on the RPi (192.168.1.41) hosting the USB-connected uBlox 6 GPS engine. I can open any number of terminal windows now and run multiple copies of gpsmon, allowing me to validate that gpsd supports multiple clients. That is great.

What I have not been able to do is get gpsmon running on a second RPi (192.168.1.236) to connect successfully to the gpsd on the first unit and display the gps data. I get the following error message when trying:

Thanks for the tutorial. Following your instructions I managed to get the USB GPS receiver to work with the PI 2 and I can get a fix using xgps. I was wondering if you could point me to a tutorial that would help me make a python program that would make use of the information being received from the receiver. My ultimate goal is to make it transmit the co-ordinates via http requests, but for now it would be enough to just get the program to display the latitude and longitude on screen. Thanks!

c80f0f1006