Blogging has been light recently because I’ve been working very hard on a major GPSD release, which I just shipped. This is mostly new features, not bugfixes, and it’s probably the most new code we’ve shipped in one release since about 2009.
The most user-visible feature of 3.10 is that 1PPS events are now visible in gpsmon – if you have a GPS that delivers this signal you can fire it up and watch how your system clock drifts in real time against the GPS top of second. Also you’ll see visible indicators of PPS in the packet logging window at the start of each reporting cycle.
For those of you using GPSD with marine AIS radios, the Inland AIS system used on the Thames and Danube receivers is now fully decoded. We’ve also added support for the aid-to-navigation messages used in English and Irish coastal waters. There’s a new AIS data relay utility, gps2udp, that makes it easy to use GPSD to feed AIS aggregation sites like AISHub. AIS report control has been cleaned up, with text dumping of controlled-vocabulary fields no longer conditional on the “scaled” flag (that was dumb!) but done unconditionally in new JSON attributes paired with the numeric ones.
There’s alpha-stage RTCM3 decoding; I expect this to become more fully baked in future releases. No ADSB yet, alas – we’ve had people express interest but nobody is actually coding.
The usual bug fixes, too. Use of remote data sources over TCP/IP is much more reliable than it was in 3.9; more generally, the daemon is less vulnerable to incorrectly dropping packets when write boundaries from an I/O source land in the middle of packets. Mode and speed changes to u-blox devices now work reliably; there had been a race condition after device startup that made them flaky.
The most significant changes, though, are in features related to time service. GPSD, which is used by quite a few Stratum 1 network time servers, now feeds ntpd at nanosecond rather than microsecond resolution. The PPS drift report that is part of gpsd’s JSON report stream if your GPS emits 1PPS is now nanosecond-resolution as well.
And, after weeks of effort, we’ve shipped along with 3.10 the first edition of the GPSD Time Service HOWTO. This document explains in practical detail how to use GPSD and a 1PPS-capable GPS to set up your own Stratum 1 time server.
This might not seem like a big deal, but the HOWTO is actually the first explanation accessible to ordinary mortals of a good deal of what was previously black magic known only to a handful of metrologists, NTP maintainers, and time-nut hobbyists. What happened was that I cornered several domain experts and beat them mercilessly until they confessed. :-)
Now I’m gonna go catch up on my sleep…
I cannot parse this sentence:
“1. Ensure that either gpsd and either ntpd or chronyd are installed on your system.”
I suspect the first “either” is erroneous.
>I suspect the first “either” is erroneous.
Correct. Now fixed.
In the “1 PPS quality” section, it says “Navsys GR601”. That should be “Navisys” with an “i” in the middle. There is a company called “Navsys”, and they do esoteric things with GPS, but don’t make receivers.
>That should be “Navisys” with an “i” in the middle.
Thanks, fixed.
How come I can’t find anything about license on home page or faq?
Is it even free software at all?
>How come I can’t find anything about license on home page or faq?
It does say “open source: repeatedly. License is BSD.
@Josh:
I can’t find anything on the website either (though I haven’t looked exhaustively), but the Wikipedia article lists it as being BSD licensed, which fits with what I know of esr’s philosophy and licensing habits.
Completely OT:
FDA is trying to shut down 23andme:
http://www.theguardian.com/science/2013/nov/25/genetics-23andme-fda-marketing-pgs-screening
Perhaps our esteemed host should contact them and convince them to open source the diagnostic code, and simply provide raw results for the $99.00. You know, really detailed data that lets you check ancestry, that sort of thing…
Question: Assuming my needs are in the quantiy (1) range and assuming my solder-fu is mighty enough to solder a few wires or make custom cables, which GPS module should I buy (today) to wire up to my beaglebone black?
>which GPS module should I buy (today) to wire up to my beaglebone black?
The u-blox 6, aka LEA-6H. Beats the crap out of every other receiver I know of on multiple axes; the most conspicuous is that it has good enough signal sensitivity to be pretty reliable indoors. Every Beaglebone and Raspberry-Pi-based custom build I’ve seen uses these.
I have a u-blox 6 eval kit that I like working with, so with respect to GPSD the chip has most-favored-nation status.
The” Bluetooth and gpsd” mini-howto page at http://gpsd.berlios.de/bt.html assumes that the reader is using a dedicated-purpose Bluetooth GPS device, and therefore tells the user to use channel 1. However, I posit that many readers looking at that page will be using something like [GPS2BT] on Android, which will turn a GPS-capable Android smartphone into a generic NMEA GPS device running over Bluetooth.
Hence it might be advisable to update the instructions to include something like the following after configuration step 2:
Get the channel number the GPS service is using. On a dedicated GPS receiver, this will generally be 1, but on some devices, especially smartphone GPSes, this will be something else:
# sdptool browse xx:xx:xx:xx:xx:xx
You’ll be looking for something like the following:
Service Name: GPS2BT
Service RecHandle: 0x1000b
Service Class ID List:
UUID 128: 00001101-0000-1000-8000-00805f9b34fb
Protocol Descriptor List:
“L2CAP” (0x0100)
“RFCOMM” (0x0003)
Channel: 4
Use the channel number for the rfcomm configuration in the next step. If GPSD keeps telling you “connection refused” when trying to open up the /dev/rfcomm0 port, it is almost definite that you have specified the wrong channel number.
[GPS2BT] https://play.google.com/store/apps/details?id=com.cajax.gps2bt2&hl=en
>Hence it might be advisable to update the instructions to include something like the following after configuration step 2:
Dude, send me a patch. If I try to incorporate that from here I’ll probably garble it.
Patch is here:
https://drive.google.com/file/d/0B0dDtsAZK2yqQnRFaEhOZENFcVU/edit?usp=sharing
>Patch is here:
Merged and pushed, thanks.
I found the FAQ fascinating, as I’ve read your various reports on 1PPS work. It was interesting to see all of the information in one place. While reading, I found a few typos:
Section Feeding NTPD from GPSD:
In a binary-package-based Linux distribution it is probable that ntpd will already have brrn launched at boot time. (brrn -> been)
End of same section:
Uf your GPS is not present in [HARDWARE], or doesn’t have a recommended fudge, or you see a fudge value very different dfrom what’s there, send us the output of the “ntpq -p” command and the make and type of receiver. (Uf -> If, dfrom -> from)
Section Performance and Tuning:
(Long term aging is a third property that is interesting, but ntpd and chrony both a use a drift history that is relatively short; thius, this is not a significant cause of error.) (thius -> thus)
(For an example, see [ADEV-PLOT]. (Missing close parenthesis.)
Subsection NTP Performance Tuning
Note that a chimer can be a poor performer for either of three reasons. (either -> any)
Ooh. I don’t know why I never looked at the whole source tree before. I had an idea for a Python client that would serve KML via a Web server a while back, and come to find out it’s basically already half-written. :) Should be a cakewalk.