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
and
Ahoy-hoy!
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)

Cesium

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.

Untitled

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

NTP

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 127.0.0.1
restrict ::1
restrict source notrap nomodify noquery


The output of the NTP query script looks like this.

Untitled

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.

Untitled

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.

Friday, November 30, 2018

GPS satellite PRN 4

Around 2018-11-29T12:00-07:00 (lunch time yesterday in Denver) I was testing some changes to Hazer, my GPS receiver evaluation project, by comparing its results using the Ublox-8 based BU353-W10 GPS receiver with those of the real-time sky map displayed by the web site in-the-sky.org . I noticed that my BU353-W10 was reporting the satellite GPS PRN 4 as "in view" with a zero elevation and zero azimuth - due north right on the horizon. That vehicle wasn't reported by the sky map.

A little web-search-fu told me that there is no GPS PRN 4. The GPS space vehicle using Pseudo-Random Number code #4 had been decommissioned and its PRN - the numerical key used to uniquely encode data over its CDMA-based air interface - has not yet been reassigned to another satellite. GPS PRN 4 does not appear in the most recent GPS almanac.

Before I could do much else, PRN 4 dropped from view.

PRN 4 reappeared the next morning around 2018-11-30T09:00-07:00 at the same azimuth and elevation. I quickly dumped the raw NMEA strings from the BU353-W10 and verified using [NMEA 0183 Version 4.10 pp. 96-97] that I wasn't decoding the GSV sentences incorrectly.

$GPGSV,4,1,15,04,,,36,05,04,062,22,10,27,253,32,13,32,053,38*43
$GPGSV,4,2,15,15,60,092,39,16,15,289,26,20,53,269,,21,72,336,22*75
$GPGSV,4,3,15,24,06,129,33,26,10,264,15,27,11,322,31,29,36,170,50*78
$GPGSV,4,4,15,46,38,215,45,48,36,220,43,51,44,183,44*43

However, I noticed that the elevation and azimuth for PRN 4 weren't actually zero: they were empty strings, which Hazer numerically converted to a zero. Its signal strength of 36 dBHz was a reasonable value that changed over time. The elevation and azimuth makes sense, considering the vehicle doesn't appear in the GPS constellation's almanac of satellite orbits; the GPS receiver couldn't compute its position. The presence of 04 in the GSV sentence in this case merely means something using PRN 4 is being received, not that the satellite is literally in view in the sky.

I coded up a change to Hazer to detect this and mark it, and to gpstool to display a ? next to that SAT entry. I was able to test this before PRN 4 again dropped from view.

PRN 4 reappeared about twenty minutes later. Here is the new display from the Hazer gpstool. Note the ? marking GPS PRN 4, and a < marking those satellites used as part of the active position fix. (You can click on the images below to see a larger version.)

Screen Shot 2018-11-30 at 10.02.13 AM

GPS PRN 4 continues to drop from view and reappear. Its period of appearance does not coincide with the GPS orbital period.

Neither [NMEA 0183 4.10] nor [Ublox 8 R15] suggests any interpretation of the empty elevation and azimuth fields.

Forty years of experience tells me that this is somehow is a bug in my code, or (less likely) in the GPS receiver. But it does occur to me that PRN 4 would be useful for testing a ground-based GPS transmitter; the erratic daytime period of its appearance would make sense for such an activity in the continental America time zones.

Update (2018-11-30)

In the spirit of We have met the enemy, and he is us, I checked for a Notice To Airmen regarding planned GPS disruptions and found this.

Screen Shot 2018-11-30 at 10.26.46 AM

The UTC time stamps don't quite match up with when I observed GPS PRN 4. But this may yet be more GPS testing at the White Sands Missile Range (WSMR) in New Mexico or (in the last of the three notices) the Yuma Proving Ground (YPG) in Arizona.

Update (2018-12-04)

To give you an idea of the comings and goings of the mysterious GPS PRN 4, here is an excerpt from the system log in which gpstool now logs them, for roughly a twenty-four hour period. An octothorpe indicates an initial state where gpstool has just started and the status of PRN 4 is not yet known. A question mark means GPS PRN 4 came into view (or if the tool had just started, was already in view) with a zero azimuth and elevation. A space means GPS PRN 4 dropped from view. The initial and maximum signal strengths, and the duration in milliseconds, is logged. All times are Mountain Standard.

Dec  3 09:32:06 gpstool: phantom GPS PRN 4 was '#' now '?' at 25dBHz
Dec  3 09:42:03 gpstool: phantom GPS PRN 4 was '?' now ' ' at 38dBHz for 597010ms
Dec  3 09:48:59 gpstool: phantom GPS PRN 4 was ' ' now '?' at 34dBHz
Dec  3 09:58:51 gpstool: phantom GPS PRN 4 was '?' now ' ' at 36dBHz for 592009ms
Dec  3 10:01:11 gpstool: phantom GPS PRN 4 was ' ' now '?' at 35dBHz
Dec  3 10:29:57 gpstool: phantom GPS PRN 4 was '?' now ' ' at 40dBHz for 1726038ms
Dec  3 10:30:11 gpstool: phantom GPS PRN 4 was ' ' now '?' at 38dBHz
Dec  3 10:32:34 gpstool: phantom GPS PRN 4 was '?' now ' ' at 39dBHz for 143006ms
Dec  3 10:33:14 gpstool: phantom GPS PRN 4 was ' ' now '?' at 35dBHz
Dec  3 10:34:27 gpstool: phantom GPS PRN 4 was '?' now ' ' at 40dBHz for 72998ms
Dec  3 10:34:50 gpstool: phantom GPS PRN 4 was ' ' now '?' at 33dBHz
Dec  3 10:35:38 gpstool: phantom GPS PRN 4 was '?' now ' ' at 37dBHz for 48001ms
Dec  3 10:35:50 gpstool: phantom GPS PRN 4 was ' ' now '?' at 37dBHz
Dec  3 11:37:43 gpstool: phantom GPS PRN 4 was '?' now ' ' at 43dBHz for 3713086ms
Dec  3 11:42:22 gpstool: phantom GPS PRN 4 was ' ' now '?' at 29dBHz
Dec  3 11:49:29 gpstool: phantom GPS PRN 4 was '?' now ' ' at 36dBHz for 427014ms
Dec  3 11:59:15 gpstool: phantom GPS PRN 4 was ' ' now '?' at 25dBHz
Dec  3 11:59:16 gpstool: phantom GPS PRN 4 was '?' now ' ' at 25dBHz for 999ms
Dec  3 13:35:06 gpstool: phantom GPS PRN 4 was ' ' now '?' at 23dBHz
Dec  3 13:35:07 gpstool: phantom GPS PRN 4 was '?' now ' ' at 23dBHz for 998ms
Dec  3 16:37:48 gpstool: phantom GPS PRN 4 was ' ' now '?' at 31dBHz
Dec  3 16:45:52 gpstool: phantom GPS PRN 4 was '?' now ' ' at 36dBHz for 484015ms
Dec  3 17:08:03 gpstool: phantom GPS PRN 4 was ' ' now '?' at 29dBHz
Dec  3 17:11:16 gpstool: phantom GPS PRN 4 was '?' now ' ' at 36dBHz for 193003ms
Dec  3 17:14:37 gpstool: phantom GPS PRN 4 was ' ' now '?' at 30dBHz
Dec  3 17:19:16 gpstool: phantom GPS PRN 4 was '?' now ' ' at 34dBHz for 279011ms
Dec  3 17:26:53 gpstool: phantom GPS PRN 4 was ' ' now '?' at 31dBHz
Dec  3 17:41:51 gpstool: phantom GPS PRN 4 was '?' now ' ' at 36dBHz for 898023ms
Dec  3 18:00:33 gpstool: phantom GPS PRN 4 was ' ' now '?' at 30dBHz
Dec  3 18:06:14 gpstool: phantom GPS PRN 4 was '?' now ' ' at 36dBHz for 341011ms
Dec  3 18:09:17 gpstool: phantom GPS PRN 4 was ' ' now '?' at 33dBHz
Dec  3 18:22:07 gpstool: phantom GPS PRN 4 was '?' now ' ' at 37dBHz for 770011ms
Dec  3 18:26:10 gpstool: phantom GPS PRN 4 was ' ' now '?' at 34dBHz
Dec  3 18:59:11 gpstool: phantom GPS PRN 4 was '?' now ' ' at 39dBHz for 1981048ms
Dec  3 19:00:54 gpstool: phantom GPS PRN 4 was ' ' now '?' at 33dBHz
Dec  3 19:30:34 gpstool: phantom GPS PRN 4 was '?' now ' ' at 38dBHz for 1780046ms
Dec  3 19:33:50 gpstool: phantom GPS PRN 4 was ' ' now '?' at 31dBHz
Dec  3 19:44:47 gpstool: phantom GPS PRN 4 was '?' now ' ' at 36dBHz for 657014ms
Dec  3 19:55:24 gpstool: phantom GPS PRN 4 was ' ' now '?' at 27dBHz
Dec  3 20:02:55 gpstool: phantom GPS PRN 4 was '?' now ' ' at 33dBHz for 451009ms
Dec  4 05:52:37 gpstool: phantom GPS PRN 4 was ' ' now '?' at 26dBHz
Dec  4 05:52:39 gpstool: phantom GPS PRN 4 was '?' now ' ' at 26dBHz for 2001ms
Dec  4 05:52:40 gpstool: phantom GPS PRN 4 was ' ' now '?' at 26dBHz
Dec  4 05:52:41 gpstool: phantom GPS PRN 4 was '?' now ' ' at 26dBHz for 1007ms
Dec  4 08:10:39 gpstool: phantom GPS PRN 4 was ' ' now '?' at 31dBHz
Dec  4 08:16:56 gpstool: phantom GPS PRN 4 was '?' now ' ' at 33dBHz for 377014ms
Dec  4 08:19:21 gpstool: phantom GPS PRN 4 was ' ' now '?' at 29dBHz
Dec  4 08:22:17 gpstool: phantom GPS PRN 4 was '?' now ' ' at 31dBHz for 176011ms
Dec  4 08:28:52 gpstool: phantom GPS PRN 4 was ' ' now '?' at 32dBHz
Dec  4 08:40:15 gpstool: phantom GPS PRN 4 was '?' now ' ' at 34dBHz for 683019ms
Dec  4 09:03:34 gpstool: phantom GPS PRN 4 was ' ' now '?' at 33dBHz
Dec  4 09:17:36 gpstool: phantom GPS PRN 4 was '?' now ' ' at 38dBHz for 842031ms
Dec  4 09:22:47 gpstool: phantom GPS PRN 4 was ' ' now '?' at 35dBHz
Dec  4 09:39:55 gpstool: phantom GPS PRN 4 was '?' now ' ' at 35dBHz for 1027038ms

You can see that the duration that the transmission using PRN 4 ranged from a second to a half an hour. The times of the transmissions stopped at 20:00 (8PM) MST and resumed at 06:00 (6AM) MST. That's even more evidence to suggest that this is a rogue terrestrial GPS transmitter using PRN 4 somewhere in the continental U.S.

Update (2018-12-04)

The U. S. Coast Guard straightened me out.
*** GENERAL MESSAGE TO ALL GPS USERS ***
ON APPROXIMATELY 10 OCT 2018 SVN36 WILL RESUME TRANSMITTING L-BAND UTILIZING PRN04. AT L-BAND ACTIVATION, SVN36/PRN04 WILL BE UNUSABLE UNTIL FURTHER NOTICE. ADDITIONALLY, NO BROADCAST ALMANACS WILL INCLUDE SVN36/PRN04 UNTIL FURTHER NOTICE.
*** GENERAL MESSAGE TO ALL GPS USERS ***
Mystery solved!

Update (2018-12-06)
"SVN36 was removed from the active GPS constellation on 21 February 2014 (ref. NANU 2014019). It is now a "reserve" satellite, located near slot C2. SVN36 temporarily transmitted L-band signals as PRN10 between 17 September and 16 October 2015 inclusive (ref. IGS monitoring). It was set unhealthy and not included in broadcast almanacs (ref. NANU 2015080). SVN36 transmitted L-band signals as PRN04 between 20 July and 28 November 2017 (ref. NANU 2017070 and IGS monitoring). It was not set healthy and not included in broadcast almanacs."
- from U. of New Brunswick (CA) Geodesy & Geomatics Engineering web site
Update (2019-01-03)

In an interesting turn of events, the recently launched SVN74, a new Block IIIA GPS satellite that is the first of an upgrade to the GPS constellation that will bring a variety of new capabilities, will be using PRN4, the same pseudo-random noise code that was being used by the decommissioned SVN36 that I've been watching.
*** GENERAL MESSAGE TO ALL GPS USERS ***
GPS III SVN74 (PRN04) WAS LAUNCHED ON 23 DEC 2018 (2018 JDAY 357) AT 1351 ZULU. THIS SATELLITE WILL UNDERGO EXTENSIVE ON-ORBIT CHECK OUT AND TESTING PRIOR TO BEING SET HEALTHY.
A USABINIT NANU WILL BE SENT WHEN THE SATELLITE IS SET ACTIVE TO SERVICE.
*** GENERAL MESSAGE TO ALL GPS USERS ***
I have to wonder if the use of PRN4 in SVN36 was some kind of test with ground systems done in advance of the SVN74 launch.