Tuesday, March 19, 2019

Automatic Pilot

My 2016 Subaru WRX has a Continuously Variable Transmission (CVT), with which the WRX simulates a six-speed in software, and the EyeSight driver assist feature which includes lane keeping, collision avoidance, and intelligent cruise control. I had the WRX only a few months before Mrs. Overclock and I attended MidAmeriCon II, the 74thWorld Science Fiction Convention, in Kansas City Missouri. Having driven my WRX from Denver to KC, we afterwards drove to Branson Missouri, which is near the Arkansas border.

2016 Subaru WRX Limited

I routinely used the intelligent cruise control on that trip, which was a marvel: automatically slowing down and then speeding back up as traffic allowed. I did play with the lane keeping on a lightly populated stretch of the Kansas Turnpike. I typically don't use the lane keeping feature in "active" mode, preferring instead to merely have it warn me of a "lane departure". But on the Turnpike, active mode worked as advertised; it was spooky to feel the steering wheel being turned underneath my hands to keep the car in the lane.

Mrs. Overclock and I were on a four lane divided highway in Missouri - maybe US65 - that was not controlled access: it had roads - sometimes gravel - branching off at right angles into the woods on either side of the highway. I had EyeSight fully engaged.

I was in the right hand lane when a local in a car right out of the Duke's of Hazzard came roaring past me in the left lane like his hair was on fire. Maybe he suddenly realized his turn was imminent. He cut in front of me and slammed on his brakes to make his turn.

I was paying attention, had my hands on the wheel, and saw all of this. I barely got my foot off the accelerator to apply the brakes when EyeSight simultaneously chopped the throttle, downshifted several times, and slammed on the brakes.

Mrs. Overclock and I were thrown into our seatbelts. My WRX slowed down, the local made his sharp right hand turn onto a gravel road, and we missed rear-ending him. After he turned, EyeSight let off the brakes, accelerated, upshifted, and resumed our prior cruising speed as if nothing had happened.

I'd like to think I could have done as well... but I'm just has glad I didn't have to prove that. It was a remarkable experience.

Never the less, I wouldn't trust EyeSight in my WRX - or Autopilot in your Tesla - to drive the car for me under all foreseeable conditions. EyeSight is good. But not perfect.

In daily driving I've had EyeSight in my WRX, and in Mrs. Overclock's 2016 Subaru Outback station wagon, turn itself off when visibility was very bad due to heavy rain or snow, the lane markings were so worn I couldn't even tell where the lane was, or temporary markings due to construction appeared unclear or ambiguous. Even doing something as mundane as driving through the car wash requires I disable the collision avoidance feature so that the computer doesn't freak out.

Most recently, EyeSight was useless as we crawled home in the Outback from Denver International Airport during the "bomb cyclone" - our flight from Chicago O'Hare (a Boeing 757 in which I am quite sure our pilots kept their hands firmly on the controls) was one of the very few arrivals not cancelled that day - because the ground blizzards reduced visibility to just a few feet beyond the hood of the car. Near the airport, where it was at its worst (it looked like a war zone) we had to resort to using GPS to determine when we were approaching a major intersection, and what intersection it was, visibility was so poor. (The fact that GPS - possibly augmented by cell tower triangulation - worked at all is a remarkable technical achievement in signal processing.)  What we did may have been risky, but it kept us from being among the four thousand passengers that ended up sleeping at DIA that night because the arrival and departure boards were a sea of CANCELLED.


Automation works great... until it doesn't. Driver assist automation is great for augmenting our abilities, but not replacing them.

Automation for self-driving vehicles is a frequent topic of discussion amongst my real-time/embedded colleagues. It may be that it only has to do better than the average human at driving in conditions ranging from ideal to adverse. But our experience driving home from DIA suggests to me that that bar may not actually be all that low.

It's also hard not to ponder the unintended side effects of automation - particularly automation that overrides the human at the controls - when reading about the Boeing 737 MAX 8 story. But that's a topic for another day, when the facts are in.

Wednesday, January 23, 2019

Nothing Is Ever Simple (January 2019 Edition)

I recently discovered, completely by accident, that some of the photographs in my blog were not displaying. It's an issue somewhere along the pipeline with the Safari browser on my Mac (which ultimately renders the embed HTML), Google's Blogger (which has hosted my blog since 2006), and Flickr (which has hosted my photographs since 2004). The embed HTML that serves up the photograph is, these days, provided directly by Flickr; but Blogger also provides a image embed button, and that may well be what I used in the dim past.

So far I've only found two broken articles
DTMF Tones, Fourier Transforms, and Spectral Analysis
among the 290 that I have written. I believe I've fixed both of them.

These two related articles were written about the same time, February and March of 2014. The embed HTML in both articles that references photographs uses the iframe HTML tag. Articles in my blog written before and after that reference photographs do not use iframe, and seem to render okay. 

Some judicious web searching led me to some discussions amongst Flickr users as to the iframe embed code no longer being supported by Flickr. My current thinking is that that at some point Blogger generated the iframe HTML tag to embed images, and Flickr eventually declined to support it.

Thanks, Cloud.

If you come across an article in my blog that has a big block of white space where you think an image ought to be, please comment on that article and I'll do my best to fix it.

Thursday, December 27, 2018

Monitoring GPS and NTP: Yet Another Raspberry Pi Project

TechRepublic recently published an article on the history of the Raspberry Pi, the single board computer that changed the way I work. Long time readers (there are a few) will already know that various generations of the Raspberry Pi have been the platform of choice for many of the projects I have written about here.

Because so many of my paying gigs are ARM based, the Pi has become my go-to prototyping platform. Because it's so inexpensive yet so capable - the latest version is about US$35 and has a Broadcom four-core 1.4Ghz ARMv7 processor - it's become my standard platform on which I build almost all of my side projects.
Some of my smaller projects - particularly those that have run on batteries or even on solar power - have been based on one flavor or another of the Arduino board. The Arduino uses an Atmel AVR eight-bit microcontroller, which is perfect for these small projects, but it's too resource limited for more ambitious tasks.
For my really resource intensive projects, even the Raspberry Pi is too limited. I have used the tiny Intel NUC platform with an i7 processor. The Next Unit of Computing is a full blown PC in a tiny form factor, extremely powerful - 3.5GHz for my latest one - but too pricey to permanently dedicate to a single project.
I've also had good experiences with other single board computers like the BeagleBoard. But those other SBCs were, at least initially, too expensive for me to deploy at scale, or lacked the hardware and software ecosystems that make it easy to use the Pi for the kinds of things I do.
Sitting here in my home office, there are four Raspberry Pis running inside projects sitting around, and one more on my LAN that I use as a development platform, all running the Debian-based Raspbian distro of Linux. There's even one sitting in my living room - a "mantle clock" (shown below; you can click on any of the images to see a larger version) that includes a cesium chip-scale atomic clock. In the basement, there are probably a dozen older first and second generation Raspberry Pis sitting in storage boxes, the remnants of one archived project or another.

Astrolabe (O-2)


One of my more recent applications of a Raspberry Pi was a tool I built a few months ago to constantly monitor the Global Positioning System (GPS) and the six Network Time Protocol (NTP) servers - two commercial, four home brew, one with the aforementioned atomic clock - on my home LAN. This project is code-named Cesium. Cesium uses a Raspberry Pi 3B with a 7" touch-sensitive LCD display all inside a nice case. Here's a photograph of Cesium sitting on a shelf on my desk.

Lady Heather running on Cesium

When Cesium boots up, it automatically starts three monitoring tools, each in its own window. I implemented this by enabling auto-login on the Pi, and added a script to the default user's .profile that starts each tool in the background using lxterminal. You can select what window you want to view in the foreground just by touching the appropriate tab on the display.

Lady Heather

The first window runs Lady Heather, an open source and remarkably comprehensive tool used to monitor GPS-disciplined oscillators. The tool is configured to use the NaviSys Technology GR-701W, a USB-attached GPS receiver that delivers not just positioning, navigation, and timing (PNT) data via the usual NMEA sentences, but also, via the DCD modem control line, a one pulse per second (1PPS) frequency reference derived from the GPS signal.

Lady Heather can be configured to display all kinds of information. The display shown below is just what I chose as the most useful for my purposes.


The sub-displays can be embiggened by just selecting them using the touch-sensitive display. This is particularly useful for the sky map in the lower right-hand corner that shows the positions of the visible GPS satellites according to their current azimuth and elevation, along with some of the more obvious astronomical objects like the sun and the moon.

Lady Heather "Watch" Display


The second window runs a shell script that periodically queries the NTPsec ntpd NTP daemon on Cesium. This daemon monitors the six NTP servers on my home LAN and compares their results with those of both the NIST NTP servers at time.nist.gov and those of the pool of NTP servers at pool.ntp.org. The configuration file /etc/ntp.conf on Cesium looks like this.

# Copyright 2018 by the Digital Aggregates Corporation, Arvada Colorado USA.
server hourglass
server sundial
server waterclock
server astrolabe
server obelisk
server candleclock
server time.nist.gov
server pool.ntp.org

driftfile /var/lib/ntp/ntp.drift

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

restrict -4 default kod notrap nomodify nopeer noquery limited
restrict -6 default kod notrap nomodify nopeer noquery limited
restrict ::1
restrict source notrap nomodify noquery

The output of the NTP query script looks like this.


Interestingly enough, over the very long run, the NTP algorithm pretty consistently prefers Astrolabe, the NTP server I built that has the cesium atomic clock, probably because it has the best long term stability of all the NTP servers Cesium monitors. Over time, the algorithm's least favorite time sources are typically Obelisk, an NTP server I built that is disciplined to the WWVB long-wave radio signal from Fort Collins Colorado, and Candleclock, an NTP server I built that uses another GR-701W GPS receiver and whose 1PPS reference is badly jittered by the USB interface. NTP is also usually pretty happy with Hourglass, a GPS-disciplined NTP server I built that uses a Raspberry Pi GPS expansion board the provides NMEA and 1PPS via a serial port, and Sundial, a commercial LeoNTP server that I like a lot.

Hazer gpstool

Hazer is my own C-based library and toolkit that parses standard NMEA sentences, and proprietary UBX packets from those Ublox-brand receivers that provide them. I find Hazer's gpstool utility useful for evaluating new GPS receivers, of which I have tested many.

I also discovered that gpstool is useful for monitoring the GPS and GLONASS satellite constellations, having used it to discover, mostly by accident, that a GPS satellite identified as PRN 4 (that being its Pseudo-Random Noise code number) was transmitting even though it was out of service. (This was intentional and documented, but the exact reason why has never been disclosed as far as I know.)

The gpstool display is continuously refreshed as the second GPS receiver connected to Cesium, a GlobalSat BU-353W10, transmits updates over its USB connection. This GPS receiver has the added capability of being configurable to detect jamming and spoofing.


I like this display because it shows more of the low level detail about the output of the GPS receiver than the Lady Heather display. And I wrote the software, so of course it is automatically interesting to me. Plus, this is a kind of long-term test of Hazer.

I Smell Pi

I've successfully used Raspberry Pis in a slew of projects. As have others. I've seen my clients whip up WiFi and LTE test beds, remote embedded web servers, and all sorts of other useful stuff, all because they could buy a powerful Linux system for just a little bit of money. The Raspberry Pi is the little computer that could.