Dealing with GPS

It's been a couple of weeks since my last post, but that's not down to lack of progress, it's down to having to earn some money, fighting with a Linux virus on a handful of machines, and having far too much fun with the RPi!

As this my datalogger blog, I'm not going to cover all the fun I've been having with a PIR detector and hardware PWM for fading LEDs/LCD backlight.  It looks like this will lead to a fancy new lighting system for the kitchen cabinets that come on when you walk into the kitchen - the design and most of the code is done, just need to buy the striplight and wire it up!  Nor will I cover the ongoing work on CatCam - again using a PIR to record what my cats are actually doing when they "knock" at the flat door demanding to be let in!

OK, back to the datalogger.  One of the most important parts of the kit is the GPS unit.  The one that I bought was the Adafruit Ultimate GPS.  It's a high quality GPS unit and perfectly suited to the task.  The main delay was that I had to solder the header pins myself!  If you read the previous post then you'll know that it had been a while since I'd picked up a soldering iron.  Basically I practiced quite a bit on header pins and resistors on veroboard until I felt that I could let myself loose on a £30 component.  In the end, it actually went very well.  One pin is a bit blobby, but I'm never going to use that pin and rather than mess it all up, it's staying that way.

Of course, if Adafruit had released this hat a couple of months earlier, I wouldn't have needed to bother with the soldering at all!  That hat will almost certainly be used in the finished datalogger just because it's going to be much more robust than wires attached to the GPIO pins, and I can mount the other components on it as well.

You'll see that I have attached an external GPS aerial for now as the board lives on my desk and gets absolutely no GPS signal at all!

In terms of software configuration, I am using the built in serial port (UART) as described by Adafruit here.  There's no point using a USB to serial convertor when you have a serial port doing nothing much.  Once the UART was free, all it really took was to get GPSD up and running. To do that, run dpkg-reconfigure gpsd, and feed it /dev/ttyAMA0 for the device, and -n for the flags, which activates the GPS unit even if no clients are connected to GPSD.  Apparently NTP doesn't count as a client.  While GPSD should autodetect the BAUD rate, it's probably worth sticking init_uart_baud=9600 into /boot/config.txt and rebooting.

Now it has a fix, it's time to move on to getting NTP working.  Basically there was a lot of faffing around before I got something that works.  Loads of really good info here and here.  As I wanted time to be as accurate as possible, PPS was the way forward.  Thankfully the recent Raspbian release has PPS support built in, all you need to do is to tell the GPIO PPS kernel module which pin you're using. Do that by adding bcm2708.pps_gpio_pin=18 to /boot/cmdline.txt.  Then add pps-gpio to /etc/modules and reboot.  If the GPS unit has a fix, it should output a PPS waveform, and this can be seen using ppstest

root@raspberrypi:/home/pi# ppstest /dev/pps0
trying PPS source "/dev/pps0"
found PPS source "/dev/pps0"
ok, found 1 source(s), now start fetching data...
source 0 - assert 1421960593.000005477, sequence: 10060 - clear  0.000000000, sequence: 0
source 0 - assert 1421960593.999991566, sequence: 10061 - clear  0.000000000, sequence: 0
source 0 - assert 1421960594.999991654, sequence: 10062 - clear  0.000000000, sequence: 0

The next step is to rebuild NTP with ATOM support.  Hopefully a future Raspbian release will fix that!  I used the dpkg method from one of the docs above so that I can install it on all future builds. Once done, ntp.conf need to be configured as follows:

# gpsd shared memory clock
server 127.127.28.0 minpoll 4 maxpoll 4 prefer
fudge 127.127.28.0 time1 0.490 refid GPSD

# pps-gpio on /dev/pps0
server 127.127.22.0 minpoll 4 maxpoll 4
fudge 127.127.22.0 refid PPS flag3 1  # enable kernel PLL/FLL clock discipline

The time1 offset of 0.490 seconds has been calculated as the average response time for the GPS over UART on this RPi, yours may be different! There are also three standard pool.ntp.org servers there for now, but they'll go at some point soon. This gives decent time sync:

     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
+127.127.28.0    .GPSD.           0 l    9   16  377    0.000  -37.625  43.493
o127.127.22.0    .PPS.            0 l    8   16  377    0.000   -1.817   0.139
*213.171.220.65  158.43.128.66    3 u   31   64  377   25.168    1.595  36.595
+217.114.59.3    158.43.192.66    2 u   25   64  377   26.759   -2.102  37.833
+129.250.35.250  140.203.204.77   2 u   26   64  347   20.654   -2.603  63.899

So, that's GPS pretty much sorted.  Next job is to get the IMU working to measure acceleration/lean angle/heading etc.