Showing posts with label Geolocation. Show all posts
Showing posts with label Geolocation. Show all posts

Wednesday, March 20, 2024

Converting GPIO from the legacy sysfs ABI to the ioctl ABI in Diminuto and Hazer

It could be that no one but me is using my "Hazer" GNSS library and toolkit, or the "Diminuto" C-based systems programming library on which it depends. But just in case: I'm close to finishing testing of the develop branch of both repos, both of which have some major changes to how General Purpose Input/Output (GPIO) - the generic term for controlling digital input and output pins in software - and merging develop back into the master branch.

This was all motivated by my being one of the lucky few to get a backordered Raspberry Pi 5, and putting the latest version of Raspberry Pi OS, based on Debian "bookworm" and Linux 6.1, on it, only to find when unit and functional testing my code that the deprecated sysfs-based GPIO ABI no long worked. This wasn't a big surprise - I had read at least two years ago that the old ABI was being phased out in favor of a new ioctl-based ABI. My code makes heavy use of GPIO for a lot of my stuff, e.g. interrupts from real-time sensors, the One Pulse Per Second (1PPS) signal from GNSS receivers, status LEDS, etc. So it was finally time to bite the bullet and replace all the places where I used the sysfs-based Diminuto Pin feature (diminuto_pin) with a new ABI using the ioctl. Hence, the Diminuto Line (borrowing a term from the new ABI) feature (diminuto_line).

Line is now used in place of Pin in all of the Diminuto functional tests that run on  hardware test fixtures I wired up many years ago just for this purpose, and all the functional tests work. The Hazer gpstool utility has similarly been converted to using Line instead of Pin and has been tested with an Ardusimple board using a u-blox UBX-NEO-F10T GNSS receiver.

IMG_5717

(That's a Pi4 on the left connected to my test fixture, and a Pi5 on the right connected to the GNSS receiver.)

Two complaints.

[1] The new ABI is woefully under documented. However, I found some code examples in the Linux kernel source repo under tools/gpio that were essential to my understanding. (I chose not to use the new-ish libgpiod for my work, for reasons, but that is a story for another time. I have no reason to believe that it's not perfectly fine to use.)

[2] The way the ioctl GPIO driver is implemented on older versus newer Raspberry Pi OS versions makes it difficult - I am tempted to say impossible, but maybe I'm just not that smart - to write code that easily runs on either platform using the new ABI. Specifically, the GPIO device drivers in the OSes use a different symbolic naming scheme, making it impossible for application code to select the correct GPIO device and line offset portably on the two platforms. But maybe I'm just missing something. (I hope so.)

I like the new ioctl ABI, and expect to use it exclusively moving forward, even though this will orphan Pis I have that might run older versions of the OS. (I think I have at least one example of every Pi version ever sitting around the Palatial Overclock Estate. Ten of them run 24x7 in roles such as a web server, an Open Street Map server, a Differential GNSS base station, and an NTP server with a cesium atomic clock for holdover.) I have tagged the last version of both repos that still use the sysfs ABI.

That's it.

Update (2024-03-23)

I merged the develop branch in to the master branch this morning. Both the Diminuto build and the Hazer build passed sanity and functional testing (and I'm currently running the long-running "geologic" unit test suite against Diminuto). I had tagged the old master branch in both repos with the name sysfsgpio in case I needed to build them, but I don't anticipate any further development of the old code.

Friday, January 05, 2024

Right to Repair, Polish Train Hackers, and the NSA's Ghidra

Google "Polish train hackers" and you'll find dozens of articles in the tech press about this story. Here is the link to the one I read, which was translated from the original Polish. It's terrific. Compelling reading if you're interested in the misuse of Digital Rights Management or the Right To Repair movement. Or if you're into embedded systems development and troubleshooting. Or just if you're into stories of heroic efforts by engineers.



Polish embedded systems hackers use (get this) the U.S. National Security Agency's open source Ghidra tool, originally intended to reverse engineer binaries of computer viruses and other malware, to figure out why high-tech passenger trains, like in the video above, quit working after undergoing routine maintenance - following the train manufacturer's own two thousand page maintenance manual - by a third-party.

What did they discover in various versions of the train software/firmware?

  • Odometer checks that prevent a train from running after a million miles.
  • Year, month, and day checks that prevent a train from running after a certain date.
  • Geofencing checks (naturally the trains have GNSS receivers) that prevent a train from running if it is within the boundaries of a competitor's maintenance depot.

I've used Ghidra myself, and written about it in my blog. The tool includes not just a disassembler similar to objdump, but also a remarkable decompiler that can translate machine code using common C compiler idioms and patterns back into C code. Ghidra understands a wide variety of Instruction Set Architectures. Just recently I've been using it to study the binaries of my own code compiled for a RISC-V target.

DRM and Right To Repair is a big deal in the U.S., Manufacturers of agricultural equipment, like farm tractors costing six figures, have resorted to similar shenanigans to prevent even the farmers who own the equipment from repairing their own stuff. So much so that Right To Repair legislation is coming to the forefront of both state and federal legislators.

Saturday, July 22, 2023

Using Microsoft's Windows Subsystem for Linux on Windows 11

I recently bought a new laptop that runs Microsoft Windows 11.

And I didn't immediately install a Linux distro over top of Windows.

Shocking, I know, for a guy who for years has been, and remains, firmly in the Apple ecosystem: laptop, desktop, phone, and tablet. And who, for the past few decades, has been writing software for the Linux ecosystem (including for Android). But I didn't own a hardware platform that can run Windows 11, which only works on systems that have a Trusted Platform Module (TPM). And a lot of the commercial tools for embedded systems, and vendor tools for GNSS devices, that I use only run on Windows.

I bought a 2022 HP Envy x360 Convertible Model 15. That's a laptop with a 15.6" touch sensitive screen that folds up to convert into a tablet. It's the first hardware platform I've run my code on that uses an AMD processor: a Ryzen 7 5825U. It came with Windows 11 Professional. It has 64GB of RAM, and a 2TB PCIe SSD.

So of course almost the first thing I did was get Microsoft's Windows Subsystem for Linux (WSL) working on it. This allows you to run a full blown Linux/GNU distro - not an emulation layer - with a Linux kernel, in a highly optimized virtual machine environment native to Microsoft. Then I got my own software running on it, my Diminuto and Hazer repositories.

It was mostly straightforward, although getting a USB device (in my case, a GNSS receiver dongle) attached to the Linux environment was a little weird - definitely weirder than doing the same thing using the commercial VMware software, which I have done many many times.

Here's a snapshot of my GNSS software, gpstool, running under Ubuntu Linux, under Windows 11, on the new laptop.

Hazer on HP Envy x360 15 Convertible

I have come to think of the WSL window as the "system console" for the running Linux. If you do an ifconfig command in this window, you can get the local IP address for the Linux instance. Using that address, you can ssh into Linux from Windows and have multiple concurrent Linux sessions. I use the popular Windows app PuTTY - which I also use to connect to serial-attached devices - but anything similar, like using the Windows' native ssh command from a PowerShell console, should work.

You can easily tell that the NMEA 0183 data stream from the GNSS device is running through some kind of USB bridge software layer under Windows that adds significant latency. My GNSS software displays, second by second, both the local system clock (LOC) and the GPS time from the incoming NMEA data (TIM). On this system, they consistently differ by one second, TIM running one second late. I have seen this also when running under VMware, but never when running natively on a system. Definitely won't be using this approach for precision timing, but it should be fine for geolocation.

I've found an issue with one of my USB-attached GNSS receivers, that the optional Windows usbipd utility, which you use to manage the connection of USB devices to WSL, refuses to attach to Linux: "device is in an error state". It's the one dongle I have that uses the Data Carrier Detect (DCD) indication to provide the GNSS one-pulse-per-second ("1PPS") signal. It works fine natively with Linux on, for example, a Raspberry Pi. Other USB-attached GNSS devices have worked fine.

Otherwise: so far, so good.

Monday, July 03, 2023

Hazer with the U-blox NEO-F10T GNSS Receiver on the Ardusimple SimpleGNSS Board

It's been a while since I talked about my GPS/GNSS efforts. Some time ago I bought a SimpleGNSS board from Ardusimple to try out. The SimpleGNSS has the new U-blox NEO-F10T GNSS receiver. This was my first experience using a new U-blox generation 10 device. It is the first GNSS device of any kind I've used that includes features specific to the latest version 4.11 of the National Marine Electronics Association 0183 standard. And it's the first I've used that's capable of receiving the new L5 band signal from the latest Block III GPS satellites.

I was about ready to dismantle this experiment. But before I removed it from my workbench, I thought I'd update y'all on my latest version of the Hazer library and its gpstool utility.

Hazer is a Linux/GNU/C-based library that supports the processing not only of the usual NMEA 0183 output of GNSS receivers, but also proprietary binary output like UBX from U-blox devices, and CPO output from Garmin devices. It also handles input and output of RTCM messages in support of differential GNSS, yielding geolocation precision down to about a 1.5 centimeters. (I run a DGNSS fixed base and a stationary rover 24x7 at the Palatial Overclock Estate.)

gpstool is the Swiss Army Knife of Hazer. It's one of those old-school tools that has a nightmare of command line options. I use it to functionally test the library, and also as the main component of most of my GNSS efforts. You wouldn't want to use gpstool to navigate cross-country (although I have used it in conjunction with OpenStreetMap to generate a moving map display in real-time). But I find it really useful for testing and evaluating new GNSS devices and just generally futzing around with geolocation and precision timing.

(You may want to click on the short video clips to view them on YouTube instead of from this blog; the UI seems to crop the images, losing some information. You can also click on photographs to see a larger image.)

Here is a short video clip of a Raspberry Pi 4B running gpstool with the NEO-F10T connected via USB.

Besides processing the output of the U-blox device, gpstool is following the 1 Hz One Pulse Per Second (1PPS) digital output signal from the device, which is syntonized to GPS time, and strobes another digital line on the Raspberry PI, syntonized to 1PPS (subject to software latency), to which I've attached a red LED.

Here is a short screen capture that shows the output from gpstool. I've SSHed into the Raspberry Pi from my Mac desktop to run gpstool. The utility uses some simple ANSI screen controls to update the display in real-time. I'm viewing standard output directly from gpstool, but the utility also has the ability to run headless in the background as a daemon, and you can view this real-time display remotely at leisure. (This is how I run my DGNSS systems.)

If you have perused the output of gpstool in any of my prior articles, you may notice a new field in the SAT lines showing the frequency band used by the device to receive data from the indicated satellite, e.g. L1 C/A. Some GNSS devices (like this one) may receive data from the same satellite over more than one band. (I confess this "new feature" is a long delayed bug fix because I botched the handling of new fields in version 4.10 of the NMEA 0183 spec. I have no excuse.)

gpstool isn't just a passive monitor. You can use its command line options to send NMEA, UBX, and other message formats to the device to interrogate and configure it. I did this with the NEO-F10T. Here is a screen shot of a snippet of a script similar to the one I used to generate the output shown in this article.  It sends a batch of UBX messages, sequentially, waiting for an acknowledgement for most of them, to configure the device.

Screen Shot 2023-07-06 at 13.28.38

You can find this script in its entirety in the Hazer repository on GitHub.

Finally, in addition to the standard output, gpstool generates log output on standard error, which here I capture in a file. (If you run gpstool headless, log output can also be automatically directed to the system log without any need for a command line option or API call.)

Hazer gpstool Example Log File

In this example, I have the log output level set to INFO (informational) and above; setting it to the DBUG (debug) level and above generates more output than I typically need unless I am actually debugging new code. (The logging system is a feature of Diminuto, my Linux/GNU/C-based systems programming library on which Hazer and gpstool are built; Diminuto has its own ginormous feature set.)

That's a quick update of some of my latest poking around with GNSS. I'm always on the lookout for new (to me, anyway) GNSS devices to play with!

Sunday, February 12, 2023

Bob Greene Road

It will probably come as no surprise that I'm all about Google Maps: the maps, its Satellite View, its Street View, all that stuff. If I see a street address in something that interests me, pretty much for any reason, I'll look it up on Google Maps, check out the Satellite View, drop into Street View and look at the 360º image.

Growing up I used to spend my summers living in the old Greene family home, the house my mom grew up in, in eastern Kentucky, not far west of the West Virginia line (Bruin, Kentucky, along State Route 7; Elliott County, county seat Sandy Hook; nearest sizable town Grayson, near Grayson Lake State Park, in Carter County).

So it was only natural when Google Maps became a thing, I'd bring up Google Maps and revisit my old childhood haunts from time to time. I found that old house, which had electricity (on good days), but no heating (other than a fireplace), and no running water (other than what I ran out to the well and got). The toilet was an outhouse, which was a fair trek out the back door and beyond the old chicken coop (but not as far as the barn) on a cold night. I also found the homes of my cousin Bob Greene and some other relatives in the neighborhood, which were just on the hillside on the other side of the hollow ("holler") to the north of our house.

Until one day, I couldn't find it. I could find other landmarks, like Route 7, the tributary of Grayson Lake that was in the neighborhood, and the old Horton Flat Road, but I couldn't recognize anything where I thought the old house should be, nor any of the homes I knew to have been near it.

I was mystified for months, until some judicious Googling led me to a page of the Kentucky Department of Transportation that explained that the short section of Route 7 on which the house sat had been completely rerouted, the road straightened out, and widened, and it now ran west of the old house, behind the hill on which the house had been built, instead of in front of it. And the original narrow, winding, sometimes treacherous section of Route 7, on which the gravel driveway up the hill to the old house was, was now an unnamed road off the shiny new Route 7.

A couple of days ago I revisited my old stomping grounds again, the very place where I learned to shoot a gun, first rode a motorcycle, read Frank Herbert's novel Dune on the front porch, and lots of other stuff, only to find that the old former Route 7 segment was now officially named "Bob Greene Road". 

Which made me really happy.

Screen Shot 2023-02-12 at 11.23.32

Friday, August 19, 2022

Playing with a RISC-V SBC running Linux

Recently I began playing with a VisionFive RISC-V-based Single Board Computer (SBC). It was designed by StarFive. I purchased it from ameriDroid.

StarFive VisionFive 2-core RISC-V SBC "boron"

RISC-V ("risk five") is a relatively new Instruction Set Architecture (ISA), developed by a team at UC Berkeley, that is entirely open source, unlike Intel and ARM processor ISAs. This is the first RISC-V board I know of that is designed to run Linux (in this case, based on the Fedora distribution). It has two 64-bit 1GHz SiFive U74 CPU cores and eight gigabytes of RAM.

"boron" is my code name for this project. (Every project gets a code name.) I added the nylon feet to hold the board up off the anti-static mat on my workbench. I started out with a keyboard, mouse, and HDMI display attached to the board, but since it supported SSH right out of the box, I quickly reverted to using the command line to build and test my SW, my preferred approach. Also, it reduces the cable clutter on my workbench, which is supporting another project at the moment.

The two projects of mine that I use the most, Diminuto (a C systems-programming library) and Hazer (a GNSS toolkit), were unusually easy to clone, build, and run; unlike most other Linux distros, I didn't have to install any optional packages (much to my surprise). I have successfully completed running all the unit tests for both projects, and am now moving on to functional testing and practical use.

Since my work tends not to be very CPU intensive, I haven't run any performance tests. I'll probably leave that to someone else. I was more worried about SW functionality. But note that this board is more expensive, and and its processor slower, than the ARM-based Raspberry Pi 4 SBCs I use these days.

But the ARM processor design, and the BroadCom implementation of it, on the Pi is closed, and I appreciated the chance to try my stuff out on the open RISC-V, after having read so much about it over the past few years.

Update: 2022-08-20

Just to provide some evidence that I have non-trivial stuff running on the VisionFive, here's a screen snapshot of gpstool running on the board.

Screen Shot 2022-08-19 at 16.22.19

gpstool is the Swiss Army knife of the Hazer toolkit, which is built on top of Diminuto. Here, it's processing input in real-time from a GlobalSat BU-353W10 GNSS receiver. The receiver, a USB dongle, is based on the widely used U-blox UBX-M8030 module.

Update (2023-03-06)

I participated in crowd funding the StarFive VisionFive 2 SBC, which has four 1.5GHz RISC-V processor cores and 8GB of memory.

Calcium

I got the board a few weeks ago and just recently got around to booting up the Debian-based Linux image provided by StarFive. Next step is to get my own software working on it.

Thursday, August 04, 2022

It's About Time

Disclaimer: I am but a humble software/firmware developer. I can barely do basic soldering. But my projects often require that I step out of my comfort zone and come to at least a dilettante's understanding of what is going in the bare metal of the embedded and real-time systems I help develop. In this article, I have left my comfort zone so far behind that I can only see it dimly in the distance, as it waves to me from the horizon.

How do you test the accuracy (correctness) and precision (repeatability) of a clock? By comparing it to another clock. Presumably a more accurate and precise clock. How do you know your reference clock is more accurate and precise? 

Studying this problem is how I learned the term clock trip. This is when you, for example, run a cesium atomic clock on batteries, synchronize (match the clock time) and syntonize (match the frequency) it with a reference clock, take the portable atomic clock on a long airplane flight, and then compare it with the clock under test.

Or, at least, that is how it used to be done. These days, everyone compares their clocks with GPS time, which anyone with a GPS receiver can access. When you synchronize and syntonize a clock with a GPS receiver, it is said to be GPS-disciplined. Then, how good your clock is depends in part on how good your GPS receiver is, how good its own internal clock is, and how good the atomic clocks are in the GPS satellite constellation. But at least you save on plane fare.

I'm not new to the idea of characterizing one clock with another clock.

Timegrapher 

(Click on any image to see a larger version.)

Untitled

Here is a tool I have used to test mechanical watches: the Timegrapher. It has a sound transducer (a fancy name for a type of microphone) that listens to the ticking of a mechanical watch placed in its test fixture, compares it to its internal quartz oscillator, and displays the results.

I don't find any information about the quartz oscillator used in the my Timegrapher in its documentation. This is a common refrain when testing clocks. But any quartz oscillator - including the one in your quartz wristwatch, if you care to wear one - is likely to be far far better than the spring-driven mechanical movement in the Rolex GMT Master II shown above, and at a tiny fraction of the cost. The same cannot be said, alas, when comparing a quartz oscillator to a clock that is disciplined - that is, continually steered or adjusted - to a GPS reference.

Network Time Protocol

I currently have six small Network Time Protocol (NTP) servers on the local area network at the Palatial Overclock Estate. Two are commercial devices, and the rest are ones I designed and built myself. All but one are GPS-disciplined; the odd one out has an AM radio receiver it uses to pickup and decode the NIST WWVB time transmission. One of the GPS-disciplined servers I built has a cesium chip-scale atomic clock (CSAC) it uses as a frequency source.

Exactly how does one assess the accuracy and precision of a GPS-disciplined clock - especially one that incorporates a cesium atomic clock, a technology from which is currently derived the literal definition of the second - without having a clock that is even more accurate and precise?

That's the problem I continually face: any test instrument - like a digital oscilloscope - that I am able to afford, even one with an oven-controlled quartz oscillator (OCXO) or a temperature-compensated quartz oscillator (TCXO), either of which is far better than the quartz oscillator in my Timegrapher, is likely to be not nearly as good as the GPS-disciplined clock I built. If I try to measure the jitter (short term variation) or drift (long term variation) in my GPS-disciplined clock, am I measuring the error in the clock, or the error in the instrument?

Cesium NTP Monitoring Tool

I addressed this problem with my NTP servers by building a little test system, Cesium, using open source NTP software. Cesium runs 24x7, and periodically requests the time from all of my NTP servers plus some public NTP servers on the Internet. The statistical tests in the NTP software score each server. I wrote about this in Monitoring GPS and NTP: Yet Another Raspberry Pi Project

What clock is Cesium using? It's Raspberry Pi has a 19.2MHz crystal oscillator (later Pi models use a 54MHz crystal oscillator). The Raspberry Pi oscillator is not temperature compensated, nor is it GPS-disciplined. And its frequency isn't the final word in how precise or accurate it is. This little tool is useful at a gross level, but it is in no way adequate for more rigorous testing.

UBX-ZED-F9T

This problem came to light again recently when I purchased a Sparkfun board with a U-blox ZED-F9T Global Navigation Satellite System (GNSS) receiver. When its antenna remains in a fixed position over a long period of time (like the window of my home office), so that the long term weighted average of its navigation solution has a low error, the F9T can act as a very accurate and precise time and frequency source. It bases its solution on an ensemble of satellites that are part of the U.S. GPS, Russian GLONASS, Chinese BeiDou, and European Galileo GNSS constellations.

SparkFun: U-blox ZED-F9T

The ZED-F9T is another example of the ninth generation of U-blox GNSS receivers, like the ones I have used in my Differential GNSS (DGNSS) projects that I wrote about in Practical Differential Geolocation. This receiver, though, is especially designed to be a time and frequency source. The SparkFun board is equipped with three SMA connectors: the center one is the input for the receiver's active multiband GNSS antenna, and the other two are outputs for software-configurable digital timing pulses.

Untitled

Who doesn't need a GPS-disciplined time and frequency source? I decided to set up test bed using the ZED-F9T - ignoring the fact that I don't have a high-quality laboratory-calibrated oscilloscope (the cost of which could easily run into five or even six figures) - and see what I could see.

The documentation for the F9T say it can emit an output pulse with a frequency up to 25MHz. Although the internals of the F9T are proprietary, this is likely to be a performance limit of its baseband processor, which is probably has some kind of ARM core. The F9T (and in fact all GNSS receivers) has a broadband processor where the digital signal processing of the gigahertz GNSS signals is done, and a more conventional baseband processor where solution computations and input and output messaging is performed. F9T docs say that the device's real time clock (RTC) is driven by a 32KHz crystal oscillator, and suggest that it is not temperature compensated. The F9T's datasheet claims an output time pulse jitter of ±4 nanoseconds. The device is marketed as being suitable for stringent 5G cellular network timing.

 I wrote a script, using my Hazer open source GNSS toolkit, to configure the F9T's first time pulse output to emit a 1Hz pulse, and its second time pulse output to emit a 10MHz pulse. 1Hz, a.k.a. one pulse per second (1PPS), is a commonly used mechanism to syntonize a time clock to GNSS time, while 10MHz is (as we will soon see) a commonly used frequency reference for test and measurement equipment.

Arrayed next to the F9T on my workbench is Rhodium, a Raspberry Pi, and my modest test equipment (described below). The Pi is where my software runs. The Pi has a Universal Serial Bus (USB) connection to the F9T to provide power and a serial connection for configuration and monitoring.

TAPR TICC

The TAPR TICC is a time interval counter with claimed 60 picosecond resolution. It is produced by the Tucson Amateur Packet Radio (TAPR) organization. It consists of a specialized board mated to an Arduino Mega 2560. It has three SMA connectors: one for its reference clock input (more on that below), and two channels of input that it can timestamp, either in absolute or differential terms. It uses the Arduino USB connection for power, and as a serial connection for configuration and monitoring.

TAPR TICC    

The TICC is a relatively low frequency (albeit high resolution) device, because it outputs a line of ASCII text for every pulse it detects. This makes it suitable for characterizing the 1PPS output of the F9T.

The TAPR TICC documentation has this to say about its timing capabilities.

The TAPR TICC is a two-channel timestamping counter with better than 60 picosecond resolution and less than 100 picosecond typical jitter. It has an Allan Deviation noise floor below 1e-10 for a one second measurement.

The TICC requires an external 10 MHz reference clock at nominally +3 dBm.

The 10MHz reference clock required by the TICC was provided by a LeoNTP, one of my commercial GPS-disciplined NTP servers, manufactured by Leo Bodnar Electronics. I've had the LeoNTP on my home network for several years. It consistently scores well with my Cesium NTP monitoring tool. I also find its front-panel user interface easy to use. That's two of the reasons I chose it as my reference clock. Another is that it has a BNC connector with a 10MHz output for just this purpose.

Sundial

The docs for the LeoNTP has this to say about its timing accuracy and precision of its BNC time pulse output.

3.3V into High Impedance, 1.5V into 50Ohm PPS/1Mhz/10Mhz Accuracy 30ns RMS, 60ns 99%

While this isn't bad, you'll notice that it's not nearly as good as the claimed performance of the F9T. One of the applications I hope to use the F9T for is as a GPS-disciplined 10MHz reference clock for the TICC and other such devices.

UBX-ZED-F9T-1PPS-metronome-taprticc

This is a screen snapshot of the output of the TICC as it timestamps the 1PPS time pulses from the Z9T. You can see the difference between the time pulses are in generally the range of single digit nanoseconds. Given that its reference clock has a claimed precision that is about an order of magnitude worse than that of the Z9T, this is pretty good, although it's not clear whether I'm really measuring the Z9T, or the LeoNTP.

Digilent Analog Discovery 2

The Diligent Analog Discovery 2 is a recent generation USB oscilloscope. The device claims it can sample analog inputs 100 million times a second (100MS/s). Since the 10MHz (100ns wide) time pulse output of the Z9T generates 10MS/s, I had some hope that this handy tool would serve. (Long time readers will know that this is not my first USB oscilloscope. But it is the first one with this high a sampling rate.)

Digilent Analog Discovery 2

All the sampling and measurement hardware is in the little palm-sized pod, which is USB-connected to a host computer (a Lenovo laptop running Windows 10 in my case) for power and to provide the graphical display. The laptop runs Digilent's WaveForms software.

Digilent Analog Discovery 2

One great feature of the AD2 that sets it apart from other USB scopes is that it has an optional adaptor board for BNC connectors. This allows you to use conventional oscilloscope probes with it. Or, in my case, BNC-to-SMA cables.

Hint: if you buy an AD2, regardless of what you use it for, you really want the adaptor board. Depending on your application, you may also want to switch the blue jumper blocks, visible here on the adapter, from the AC pins - as shipped - to the DC pins. Failure to do so causes waveforms like the 1PPS time pulse to look really funky, as the underlying circuitry tries to remove the underlying DC component from the AC signal.

The AD2 documentation has some useful information about the device's clock generator, much of which is over my head.

A precision oscillator (IC31) generates a low jitter, 20 MHz clock.
The ADF4360-9 Clock Generator PLL with Integrated VCO is configured for generating a 200 MHz differential clock for the ADC and a 100 MHz single-ended clock for the DAC.

Analog Devices ADIsimPLL software was used for designing the clock generator. The PLL filter is optimized for constant frequency (low Loop Bandwidth = 50 kHz and Phase Margin = 60°). 

The Phase jitter using a brick wall filter (10.0 kHz to 100 kHz) is 0.04° rms.

The AD2 is capable of being both an oscilloscope and a wave form generator. I'm guessing the former uses the Analog-to-Digital Convertor (ADC), and the latter uses the Digital-to-Analog Convertor (DAC), mentioned above. (The AD2 can also be used as a digital logic analyzer, suitable for commonly used external interfaces on microcontrollers and embedded processors, like SPI, I2C, and UART.)

Low Frequency Events

Pointing the AD2 at the 1PPS time pulse output of the F9T yielded the following wave form.

UBX-ZED-F9T-1PPS-metronome-DC

Once I collected some 1PPS output samples in the AD2, I used the software's built in capability to measure the period between two successive pulses.

UBX-ZED-F9T-1PPS-measurement-1

The AD2's measurement of the pulses being 1.002 seconds apart (a period equivalent to a frequency of about 9.98MHz) is not great, and not typical of the timing reported by the TICC. Once again, it's not clear I'm measuring the F9T, or the goodness of the AD2. But given the AD2's sampling rate of 100MHz, I would expect a measurement error of as much as ±10ns, once again not as good as the F9T's claimed ±4ns. (You're probably detecting a theme here.)

UBX-ZED-F9T-1PPS-blowup-1

Cranking the display resolution up on the stored samples, in effect zooming in on the graph, the WaveForms tool shows what the docs say is a "noise band indicating glitch or higher frequency components than the sampling frequency". (It's not clear to me how the device knows anything about what's going on above its sampling frequency.)

UBX-ZED-F9T-1PPS-blowup-2

Cranking the resolution a little higher shows a graph that indicates the actual points at which the 1PPS wave form was sampled. Now we can see some ground truth (which was probably already obvious to the hardware folks): the display consists of straight lines between successive sampling events. The rise of the 1PPS output line from ground to VDC (the 3.3V logic level of the F9T) cannot be instantaneous, and in fact is captured by the 100MHz sampling rate of the AD2. This explains the slight jog in the leading edge of some of the 1PPS pulses that is visible in the lower resolution displays. (This insight will be even more useful shortly.)

High(er) Frequency Events

Pointing the AD2 at the F9T's 10MHz time pulse output, we would expect see even more measurement artifacts, since the AD2's sampling rate is merely ten times the frequency of the signal we are measuring.

UBX-ZED-F9T-10MHz-metronome-DC

The 10MHz time pulse is a digital signal, but not a sine wave. But its visualization by the AD2, and the fact the output signal cannot change instantaneously, makes it look like one.

UBX-ZED-F9T-10MHz-measurement-2

Measuring the period of the time pulse becomes even more challenging. At what point do we compare successive pulses? The TAPR TICC, for example, counts anything that rises above a threshold of 1.7V as a pulse. Doing so here gives us a frequency of about 9.83MHz.

UBX-ZED-F9T-10MHz-measurement-3

It occurred to me that measuring at the point in the pulse where it starts to rise might be a better indication of the goodness of the F9T. Doing so gives us a frequency just barely short of 10MHz, off by a claimed 0.2ns, probably within the measurement error of the AD2, and certainly within the claimed precision of the F9T. (0.2ns is smaller than the period of the sampling rate, 10ns, so once again it's not clear to me how the instrument knows this.)

UBX-ZED-F9T-10MHz-measurement-5

Cranking the display resolution a little higher shows us the AD2's sampling points on the 10MHz wave form. (It also shows us why the wave form is a little funky looking, as the straight lines between samples become more obvious.) We can more carefully choose the data points that we used to measure the interval between time pulses.

UBX-ZED-F9T-10MHz-measurement-4

It occurs to me (again, probably obvious to the hardware folks) that how good the 10MHz output of the F9T appears will depend upon both the input impedance - effectively the speed at which the analog signal can change, due to the electrical characteristics of the circuit - and the measurement threshold (e.g. 1.7V?) of the device that is making use of it.

Conclusions

Neither TAPR TICC nor the Digilent Analog Discovery 2 are good (read: expensive) enough to really judge the quality of the output of the U-Blox ZED-F9T. I'll leave that to the folks with the $25,000 (or more) oscilloscopes with the oven-controlled quartz crystals. However, they were absolutely indispensable at debugging my configuration script for the F9T.  Without them, I would have had no idea if I were even in the ball park with the fairly complex messaging my software was sending to the F9T. For no other reason than this, I recommend cost effective instruments like these for any embedded software developer's toolkit.

As for my own applications of the F9T, my opinion is: if it's good enough for 5G, it's probably good enough for me.

Tuesday, April 12, 2022

The Virtual Body Politic

Recently I had the opportunity to educate U.S. legislators on two topics that I'm concerned about: the vulnerability of our encrypted data to - eventually - being cracked by quantum algorithms and why that poses a risk today, and the lack of resiliency in the U.S. Global Positioning System on which so much of our modern infrastructure now depends.

(I continue to correct and amend this article as new information comes to light.)

IEEE-USA Congressional Visits Day

The past few days I've been doing a lot of talking to people - for just a few minutes at a time - about two topics of personal concern: post-quantum cryptography, and GPS resiliency. This was part of IEEE-USA's 2022 Congressional Visits Day. IEEE is the Institute for Electrical and Electronics Engineers, an international professional society to which I belong.

For the CVD, the U.S. arm of IEEE recruits and trains volunteers from its members in congressional districts in every state to meet with legislative aids/assistants (LAs) and other staff of their elected officials in the U.S. Senate and House of Representatives. This year, I was one of these volunteers. At one time this was actually done in person; these days it's done with Zoom - apparently the preferred videoconferencing solution of the U.S. Congress - which is a lot more cost effective considering these meetings last at most half an hour. Be prepared, be brief, be polite, be respectful, be clear, talk fast, or don't talk at all.

Team Colorado (my term) consisted of myself and three other IEEE members from Congressional districts covering municipalities like Boulder, Aurora, Broomfield, Westminster, Arvada, all part of the Denver/Boulder metro area. (IEEE has over 4000 members in Colorado alone, and over 500 in the Congressional district in which I live, CO-7; I live in Arvada, and have worked in Boulder, Westminster, and Broomfield.) All of the teams took more than three hours of Zoom-based training and practice from IEEE-USA's Director of Government Relations, with the assistance of a consulting firm that specializes in helping to plan, schedule, and manage activities just like this.

To be clear, this isn't lobbying. On each team were voting constituents of senators and representatives with whose staff we were meeting. For sure, IEEE-USA hopes at least some of us choose to promote the bills and agendas which which the organization is concerned, like the CHIPS Act, which would promote the rehoming of chip manufacturing back to the United States, and they were careful to let us know what those bills and agendas were. But we're encouraged to talk about whatever we are concerned about (and, hopefully, something our elected officials can do something about), as long as we can do so in just a few short minutes.

After soliciting suggestions from several of my clients and former colleagues in the Boulder, Westminster, and Broomfield areas, post-quantum cryptography and GPS resiliency are the two topics on which I chose to spend my speaking time. Since the President's budget is just now being sent to Congress for debate and compromise, this is an excellent time for such discussions to take place (which I am sure was no accident of scheduling).

Much of my concern has to do with the pressure the currently high rate of inflation has on the actual spending power of those budget dollars. Budget numbers may seem like increases when compared to last year, but are in fact decreases when the effect of inflation is taken into account. This will create incentives to delay or even cancel projects and activities that may seem to be addressing very long term concerns (long term being anything longer than of a term of office), or even that are just hard to understand. Fortunately, explaining stuff is part of my job.

Ultimately Team Colorado met for a half hour each - an extraordinarily generous amount of time, given these people's schedules - with aids and staffers from the offices of

  • Senator John Hickenlooper (CO-S),
  • Senator Michael Bennet (CO-S),
  • Representative Edwin Perlmutter (CO-07, which includes Arvada and Westminster),
  • Representative Jason Crow (CO-06, which includes Aurora), and
  • Representative Joe Neguse (CO-02, which includes Boulder and Broomfield).

(Rep. Perlmutter is my representative, and I was delighted to meet him in person one day a few years ago as I was doing chores in my front yard and he was canvassing my semi-rural neighborhood.)

Here, in a more verbose form, is what I talked about.

Post-Quantum Cryptography

For sure, this sounds like an extraordinarily esoteric topic. It doesn't help that much of what we hear and read about quantum computing is just hype. Unless there are some unexpected breakthroughs (which is of course possible), we are a decade or maybe two from a quantum computer that isn't at best a research topic.

But once we do, it will be capable of breaking most of the encryption algorithms in common use today. This is because there is already a quantum-based algorithm - Shor's Algorithm - to factor very large numbers. Large number factorization is the basis for most modern encryption algorithms that use public and private keys. There is also a known quantum-based search algorithm - Grover's Algorithm - that can be used to break shared encryption keys.

Why might this be a near-term problem, if we're twenty years away from such a capability? It is believed that hackers are already breaking into commercial and government systems and stealing (I'm told the term of art is exfiltrating) sensitive encrypted data with long-term value, with the expectation that they will eventually be able to decrypt it. They are most likely state sponsored, for example by China, North Korea, Iran, and Russia, and are known as advanced persistent threats. Their sponsors are playing the long game.

The National Institute of Standards and Technology (NIST, part of the Department of Commerce) has already solicited candidates for quantum-resistant encryption algorithms, and the process of evaluating and winnowing down the candidates into just a few is now being done. The next step will be to have working reference implementations that can be tested, so that a handful can be blessed for use. Then to define these algorithms precisely into public standards. Then to implement these new standards into existing cryptographic software products. And finally - the big task - will be to convince everyone to migrate over to them, not just for data "in flight" or "on the wire" but for data "at rest" that has long term value. This could take years, since we're talking about huge existing repositories of stored data that could be compromised. (And it's already too late for the data that has already been exfiltrated, which I am told is the technical term of art).

New cryptographic algorithms are only as good as it takes for someone to find a way to crack them. This is a kind of arms race fought by mathematicians. Adopting quantum-resisted algorithms and migrating our data to them is a big job. The sooner we get started the better off we'll all be.

NIST has requested FY2023 budget to increase their investment in fundamental measurement, quantum science, and measurement dissemination portfolio by $15 million. Providing this budget item remains intact, I'm fairly confident that progress in this area will continue to be made.

Like any threat that is not well understood, this one has brought out a lot of folks claiming to have solved this problem. Some - maybe most - are charlatans, merely taking advantage of FUD: fear, uncertainty, and doubt. Not too long ago, one of my clients asked for my help in evaluating the claims of a start-up pushing its own proprietary cryptographic technology that it claimed to be  quantum-resistant. I'll tell you the same thing I told them: don't buy into it. This area is the realm of Ph.D. mathematicians who specialized in it. If the vendor's claims are legitimate, they will submit their algorithm to peer review through the NIST process. Wait for an officially approved suite of rigorously evaluated and tested post-quantum cryptographic algorithms that have been put into a recognized standard and implemented in the widely used software packages. If you're going to have to go through this costly and time consuming encryption migration process, you want to make sure you are better off when you finish than when you started.

GPS Resiliency

I spent some of my brief allotted time talking about the fragility of the U.S. Global Positioning System (GPS) and how dependent the U.S. was on it for Positioning, Navigation, and Timing (PNT). Virtually every telecommunications technology we care about, from our mobile phones to the internet connections to our homes and workplaces, relies, directly or indirectly, on GPS as a precise timing reference. And precision agriculture depends on GPS, with differential corrections, as a geolocation reference with centimeter precision.

Short term outages - hours, days, maybe even weeks - which can be due to ground or space system failures, deliberate jamming, or sunspots (I personally have witnessed the effects of all of these on my own equipment), aren't a problem, as long as telecommunications providers continue to furnish their systems with highly precise holdover clocks - typically cesium or rubidium atomic clocks. Short term outages do, however, disrupt geolocation applications.

It's the long term stuff - over thirty days maybe - that I worry about. Russia and China have each demonstrated anti-satellite weapons. And it only takes one Mad Russian to decide to burn the world. A study sponsored by NIST estimates that after thirty days of GPS outage, the U.S. would be losing about US$1B a day in lost productivity and capability; far more if it occurred during planting season, such is the impact of geolocation technologies on precision agriculture.

I should also mention that the GPS constellation serves a dual purpose: the satellites also carry the space-based portion of the U.S. nuclear detonation detection system.

In 2017, Senator Ted Cruz (R-TX) sponsored Senate bill S.2220, "National Timing Resilience and Security Act of 2017", co-sponsored by Senator Edward J. Markey (D-MA).

"This bill requires the Department of Transportation to provide for the establishment, sustainment, and operation of a complement to and backup for the timing component of the Global Positioning System (GPS). (GPS satellites contain atomic clocks that provide precise time data and allow GPS receivers to synchronize to those clocks.) The system must: (1) reduce critical dependencies on the GPS network; (2) ensure the availability of uncorrupted and non-degraded timing signals for military and civilian users if GPS timing signals are corrupted or otherwise unavailable; and (3) be land-based, operational in 2 years, and capable of operation for 20 years."

President Donald Trump signed this act with its bi-partisan support into law in 2018. The DoT has provided a roadmap for this effort. The DoT FY 2023 "Budget Highlights" doesn't mention it as far as I can tell. Certainly it was not implemented during the two year deadline. (BTW, this is not the "Wide Area Augmentation System for GPS", which is the WAAS system that virtually all of our GPS systems already use, whether we know it or not.)

The RAND Corporation produced a pretty interesting book on the topic, Analyzing a More Resilient National Positioning, Navigation, and Timing Capability, under contract to the Department of Homeland Security; I bought a nice bound copy from Amazon, but the PDF is available online as well. I have come to agree with the authors of the book that GPS backup is a remarkably difficult problem to solve - well, not technically, but economically and politically. It's hard to come up with a satisfactory solution that does not 

  1. put the U.S. government in direct competition with the private sector;
  2. provide perverse incentives for the private sector to do something you don't want them to do (like eliminate their expensive holdover clocks from their telecommunications systems); or
  3. micromanage the precise solution in a kinda of classically inefficient Soviet way.

Some of GPS's strengths are also weaknesses: it's globally ubiquitous, it's wireless, it generally works well, and it's virtually free: there are no subscription fees, and the receivers are relatively inexpensive and simple to use. This creates a certain amount of dysfunction in the market for geolocation and precision timing services when you find yourself shopping for a commercial alternative. We are, in some respects, victims of the success of GPS.

I don't find much evidence of progress on this topic, other than the RAND study I cited. Bill S.2220, both explicitly and tangentially, refers to the old LORAN (LOng RAnge Navigation) system - a radio geolocation technology based on hyperbolic navigation that was developed around the close of WWII - by virtue of the fact that it talks about the U.S. Coast Guard, which is responsible for the old LORAN system, turning equipment over to the DoT. The RAND study finds enhanced LORAN (eLORAN) adequate for precision timing, but not for all of the precision geolocation applications for which GPS is used. For example, tests in the U.K. demonstrated that, with differential corrections, eLORAN was capable of a timing precision of 50ns, and a positioning precision of less than 10m. (Differential GPS is capable of positioning precision of a centimeter or less, making it useful for precision agriculture.)

(I have read suggestions of using the emerging 5G cellular system as a PNT system. But IMO that begs the question of how the 5G system derives its own timing. If the 5G base stations are disciplined to GPS, that isn't really helpful.)

Funding for the ground-based GPS resiliency effort described in S.2220 have not materialized. I suspect it's another example of an unfunded mandate. In a discussion on this topic in an internet forum, someone remarked that little progress on this is likely to be made unless a crisis occurs. I tend to agree. I am reduced to saying "I am really concerned about this."

It occurred to me that an interesting fictional - I hope - techno-thriller would feature Russia having clandestinely equipped all of their GLONASS satellites - a Global Navigation Satellite System (GNSS) similar in function to the U.S. GPS - with GPS jamming transmitters. Because of its low power (a mere 44.8 watts at an altitude of 20,200 kilometers/12,500 miles), and its use of code division multiplexing (a technology that makes extremely efficient use of precious radio frequency spectrum), GPS is trivially easy to jam. So equipped, Vladimir Putin could flip a switch to turn the unencrypted GLONASS signals off (while leaving its encrypted signals intact) and deny the use of GPS with jamming. (Commercial geolocation devices these days commonly use both GPS and GLONASS; the more expensive and later ones may also use the E.U. Galileo and PRC BeiDou GNSS satellite constellations as well.) This could deny the use of both GPS and GLONASS to commercial geolocation equipment.

Update 2022-04-16

This isn't really my area, but from a practical perspective - and given the lack of competency and relatively primitive equipment displayed by Russian forces in Ukraine - I can't see Russia destroying all thirty-one satellites in the GPS space segment using anti-satellite weapons, no matter what Vladimir Putin threatens. Russia could perhaps destroy enough to make GPS coverage intermittent, despite the U.S. having spare GPS satellites already in orbit. This would have little or no effect on the use of GPS as a precision timing and frequency reference, thanks to Stratum 0 holdover clocks used by telecom providers. It would however have a serious and long term impact on the use of GPS for geolocation: continuous positioning and navigation would no longer be possible.

The worse case scenario is the destruction of one or more GPS space vehicles in Medium Earth Orbit triggering the Kessler Syndrome: debris from the GPS satellite destroying other space assets in MEO, the debris from which causes yet more destruction of other assets also in MEO, in a cascading failure - including, possibly, destroying Russia's own GLONASS satellites. This might be enough of a deterrent to prevent Russia from using such a strategy.

I would think for sure using anti-satellite weapons against GPS space vehicles would be considered an act of war against the U.S. But GPS satellites may be disabled in other ways, some of which I've already described, such as being jammed from orbit. That would not be as escalating as destroying them, and could be maintained for a long enough time to impact their use as timing and frequency references.

Epilogue

I found the IEEE-USA CVD effort time consuming but enlightening. I fell down a rabbit hole or two while researching these topics to provide follow-up information to questions asked by the legislative aids, which included a legal counsel (i.e. lawyer), and a Brookings Institution fellow who specialized (coincidentally) in GPS and space policy. I would do it again. Thanks so much to the hard-working folks in Washington D.C. for their time.

Sources

116th Congress, "CHIPS for America Act", H.R. 7178, 2020-06-11, https://www.congress.gov/bill/116th-congress/house-bill/7178

The White House, "Biden-Harris Administration Bringing Semiconductor Manufacturing Back to America", fact sheet, 2022-01-21, https://www.whitehouse.gov/briefing-room/statements-releases/2022/01/21/fact-sheet-biden-harris-administration-bringing-semiconductor-manufacturing-back-to-america-2/

OMB, Budget of the U.S. Government Fiscal Year 2023, Office of Management and Budget, ISBN 978-0-16-095232-6, 2022, https://www.whitehouse.gov/wp-content/uploads/2022/03/budget_fy2023.pdf

Post-Quantum Cryptography

Patrick Howell O'Neill, "The quest for quantum-proof encryption just made a leap forward", MIT Technology Review, 2020-08-03, https://www.technologyreview.com/2020/08/03/1005891/search-for-quantum-proof-encryption-computing-nist/

Eric Hysen, "Preparing for Post-Quantum Cryptography", PD 140-15, Department of Homeland Security, 2021-09-17, https://www.dhs.gov/sites/default/files/publications/usm_quantum_memo_0.pdf

DHS, "Preparing for Post-Quantum Cryptography", infographic, Department of Homeland Security, 2021-10, https://www.dhs.gov/sites/default/files/publications/post-quantum_cryptography_infographic_october_2021_508.pdf

The President, "Improving the Nation's Cybersecurity", EO 14028, 2021-05-12, Federal Register 86.93, 2021-05-17, https://www.govinfo.gov/content/pkg/FR-2021-05-17/pdf/2021-10460.pdf

DHS/CISA, DoC/NIST, "Post-Quantum Cryptography Frequently Asked Questions", FAQ, Department of Homeland Security/Cybersecurity and Infrastructure Security Agency, Department of Commerce/National Institute of Standards and Technology, 2021-10, https://www.dhs.gov/sites/default/files/publications/post_quantum_cryptography_faq_3_seals_october_2021_508.pdf

Patrick Howell O'Neill, "The US is worried that hackers are stealing data today so quantum computers can crack it in a decade", MIT Technology Review, 2021-11-03, https://www.technologyreview.com/2021/11/03/1039171/hackers-quantum-computers-us-homeland-security-cryptography/

DHS, "Post-Quantum Cryptography", Department of Homeland Security, 2021-12-14, https://www.dhs.gov/quantum

Sankar Das Sarma, "Quantum computing has a hype problem", MIT Technology Review, 2022-03-28, https://www.technologyreview.com/2022/03/28/1048355/quantum-computing-has-a-hype-problem/

DoC/NIST/CSRC, "Post-Quantum Cryptography", Department of Commerce/National Institute of Standards and Technology/Computer Security Resource Center, 2022-03-10, https://csrc.nist.gov/Projects/post-quantum-cryptography

DoC/NIST, "Post-Quantum Cryptography Standardization", Department of Commerce/National Institute of Standards and Technology, 2022-03-10, https://csrc.nist.gov/projects/post-quantum-cryptography/post-quantum-cryptography-standardization

Doc/NIST, "FY 2023: Presidential Budget Request Summary", Department of Commerce/National Institute of Standards and Technology, 2022-03-31, https://www.nist.gov/director/congressional-and-legislative-affairs/nist-appropriations-summary-1/fy-2023-presidential

DoC/NIST, "Fiscal Year 2023 Budget Submission to Congress", National Technical Information Service, 2022-03, https://www.commerce.gov/sites/default/files/2022-03/FY2023-NIST-NTIS-Congressional-Budget-Submission.pdf

NCCoE, "Migration to Post-Quantum Cryptography", Department of Commerce/National Institute of Standards and Technology/National Cybersecurity Center of Excellence, https://www.nccoe.nist.gov/crypto-agility-considerations-migrating-post-quantum-cryptographic-algorithms

Wikipedia, "Shor's algorithm", 2022-04-09, https://en.wikipedia.org/wiki/Shor's_algorithm

Wikipedia, "Grover's algorithm", 2022-04-01, https://en.wikipedia.org/wiki/Grover's_algorithm

GPS Resiliency

115th Congress, "National Timing Resilience and Security Act of 2017", S.2220, https://www.congress.gov/bill/115th-congress/senate-bill/2220

Office of Senator Ted Cruz, "President Signs Sens. Cruz, Markey's Bipartisan National Timing Resilience and Security Act Into Law", PR, 2018-12-04, https://www.cruz.senate.gov/newsroom/press-releases/president-signs-sens-cruz-markey-and-rsquos-bipartisan-national-timing-resilience-and-security-act-into-law

Alan C. O'Conner et al., "Economic Benefits of the Global Positioning System (GPS)", RTI International, 0215471, 2019-06, https://www.nist.gov/system/files/documents/2020/02/06/gps_finalreport618.pdf

Michael P. Gallaher, "Economic Benefits of the Global Positioning System (GPS), RTI International, 2019-11-20, https://www.gps.gov/governance/advisory/meetings/2019-11/gallaher.pdf

The President, "Strengthening National Resilience Through Responsible Use of Positioning, Navigation, and Timing Services", EO 13905, 2020-02-12, Federal Register, 85.32, 2020-02-18, https://www.govinfo.gov/content/pkg/FR-2020-02-18/pdf/2020-03337.pdf

Dana A. Goward, "How America is losing the GPS war - and risking everything", Association of Old Crows webinar, Resilient Navigation and Timing Foundation, 2022-03-26, https://rntfnd.org/wp-content/uploads/AOC-Losing-GPS-War.pdf

Dana A. Goward, "How America is losing the GPS war - and risking everything", transcript, Resilient Navigation and Timing Foundation, 2022-03-26, https://rntfnd.org/wp-content/uploads/Goward-AOC-Text-March-2020.pdf

Editor, "Great Questions! Q&A from 'How America is losing the GPS war' (Part 1)", Resilient Navigation and Timing Foundation, 2022-03-29, https://rntfnd.org/2020/03/29/great-questions-q-a-from-how-america-is-losing-the-gps-war-part-1/

Editor, "Great Questions! Q&A from 'How America is losing the GPS war' (Part 2)", Resilient Navigation and Timing Foundation, 2022-03-31, https://rntfnd.org/2020/03/31/great-questions-q-a-from-how-america-is-losing-the-gps-war-part-2/

DHS, "Report on Positioning, Navigation, and Timing (PNT) Backup and Complementary Capabilities to the Global Positioning System (GPS)", Department of Homeland Security, 2020-04-08, https://www.cisa.gov/sites/default/files/publications/report-on-pnt-backup-complementary-capabilities-to-gps_508.pdf

DOT, "National Timing Resilience and Security Act: Roadmap to Implementation", Report to Congress, Department of Transportation, 2021-01, https://www.transportation.gov/sites/dot.gov/files/2021-01/NTRSA%20Report%20to%20Congress_Final_January%202021.pdf

Stefano Ruffini et al., "5G synchronization requirements and solutions", Ericsson Technology Review, #01-2021, pp. 2-13, 2021-01-13, https://www.ericsson.com/48e592/assets/local/reports-papers/ericsson-technology-review/docs/2021/5g-synchronization-requirements-and-solutions.pdf

Matteo Luccio, "Opposite and Complementary - eLORAN is Part of the Solution to GPS Vulnerability", GPS World, 32.11, pp. 24-27, 2021-11, https://cdn.coverstand.com/59713/726592/fb31a974139579735778a7f202a3dbfe67d57f63.1.pdf 

Richard Mason et al., "Analyzing a More Resilient National Positioning, Navigation, and Timing Capability", Research Summary, Homeland Security Operational Analysis Center, RAND Corporation, RR2970, 2021, https://www.rand.org/content/dam/rand/pubs/research_reports/RR2900/RR2970/RAND_RR2970.summary.pdf

Richard Mason et al., "Analyzing a More Resilient National Positioning, Navigation, and Timing Capability", National Defense Authorization Act Fiscal Year 2017 Report to Congress: PNT Requirements, and Analysis of Alternatives, Homeland Security Operational Analysis Center, RAND Corporation, RR2970, 2021, https://www.rand.org/content/dam/rand/pubs/research_reports/RR2900/RR2970/RAND_RR2970.pdf

Richard Mason et al., Analyzing a More Resilient National Positioning, Navigation, and Timing Capability, RAND Corporation, 2021, https://amazon.com/dp/197740362X

Matteo Luccio, "10 Questions on eLoran", GPS World, 33.1, pp. 6-8, 2022-01, https://cdn.coverstand.com/59713/734537/8a8ce04baadba3d98c80aceae2e0c5011c4dc55c.2.pdf

Wikipedia, "Anti-satellite weapon", 2022-03-13, https://en.wikipedia.org/wiki/Anti-satellite_weapon

DoT, "U.S. Transportation Secretary Pete Buttigieg Announces the President’s Fiscal Year 2023 Budget for the U.S. Department of Transportation", Department of Transportation, 2022-03-28, https://www.transportation.gov/briefing-room/us-transportation-secretary-pete-buttigieg-announces-presidents-fiscal-year-2023

DoT, "Budget Highlights 2023", Department of Transportation, 2022, https://www.transportation.gov/sites/dot.gov/files/2022-03/Budget_Highlights_FY2023.pdf

Dana A. Goward, Rep. John Garamendi, "Putin is holding GPS hostage - Here's how to get it back", opinion, C4ISRNET, 2022-04-12, https://www.c4isrnet.com/opinion/2022/04/12/putin-is-holding-gps-hostage-heres-how-to-get-it-back/

Matteo Luccio, "Russia's Attack Raises Vulnerability Concerns", GPS World, 33.4, p. 6, 2022-04, https://cdn.coverstand.com/59713/744206/617d13bd681cf9f34129871033fa60662b9121e5.2.pdf

Alan Grant, Dana Goward, "Ten Answers About eLoran", GPS World, 33.4, pp. 28-33, 2022-04, https://cdn.coverstand.com/59713/744206/617d13bd681cf9f34129871033fa60662b9121e5.2.pdf

Thursday, March 31, 2022

Solar Power

I spent part of the late morning - U.S. Mountain time zone plus Daylight Saving Time or MDT (this will become important shortly) - yesterday diagnosing a major failure in my Differential GNSS test bed.

Differential GNSS (or Differential GPS if it just uses the U.S. satellite constellation) is a technique that uses a fixed GNSS base station at a known location to broadcast corrections to mobile, or rover, GNSS receivers. Since the base station is fixed, it knows that any jitter in its position calculation must be due to environmental factors, like weather in the ionosphere, that produce variations in the travel time of the signals from the satellites. Rovers in the same geographic vicinity that are computing their positions using signals from the same satellites as the base station (and so are likely to be subject to the same environmental conditions), can apply the corrections transmitted by the base station to improve their own calculations, even though they are moving and each of their position calculations are constantly changing. Centimeter position precision is possible, versus the precision of many meters typical of uncorrected GNSS. This is why autonomous vehicles cannot just use un-augmented GNSS for navigation - they can't reliably tell what highway lane they are in. Such precision is however perfectly adequate for cruise missiles.

My test rover had completely lost the ability to get a GNSS fix; it could not see any of the satellites in the GPS (U.S.), GLONASS (Russian), Galileo (E.U.), or BeiDou (Chinese) constellations. Meanwhile, the base station was working just fine. Both units run 24x7 at the Palatial Overclock Estate. The rover antenna sits in a south-side (i.e. sun-facing) window of my home office, while the base antenna sits in a skylight above my kitchen, with an excellent view of the sky above but partially shielded by the peak of the roof. 

My initial thought was that either the amplified antenna or the RF section of the GNSS receiver on the rover had failed. I stopped working on it to go out to lunch with the Spousal Unit. I checked on the rover later when we got back, and it was working fine.

I had just about decided that maybe this was an intermittent failure, when I checked my laptop and saw this email from the Space Weather mailing list of the U.S. National Oceanic and Atmospheric Administration (NOAA) that had arrived while I was at lunch:

Space Weather Message Code: SUMX01

Serial Number: 120

Issue Time: 2022 Mar 30 1824 UTC

SUMMARY: X-ray Event exceeded X1

Begin Time: 2022 Mar 30 1721 UTC

Maximum Time: 2022 Mar 30 1737 UTC

End Time: 2022 Mar 30 1746 UTC

X-ray Class: X1.3

Location: N16W41

NOAA Scale: R3 - Strong

NOAA Space Weather Scale descriptions can be found at

www.swpc.noaa.gov/noaa-scales-explanation

Potential Impacts: Area of impact consists of large portions of the sunlit side of Earth, strongest at the sub-solar point.

Radio - Wide area blackout of HF (high frequency) radio communication for about an hour.

17:37 UTC would have been 11:37 MDT. My tax dollars at work, and money well spent, if I may say.

This is not the first time I've detected interesting stuff with my GNSS experiments in Denver. Once, I'm pretty sure I detected pre-announced GPS jamming tests at White Sands test range in New Mexico. Another time, I believe I picked up the testing of a next-generation GPS satellite on a then-unused channel formerly assigned to a decommissioned GPS satellite. 

The U.S. Global Positioning System uses code-division multiplexing. CDM makes extremely efficient use of the radio frequency spectrum, but it is highly susceptible to being trivially jammed. With GPS, this can be done, either deliberately or accidentally, just by RF white noise of the correct gigahertz frequencies. A colleague of mine observed that the effects of this naturally occurring solar weather could easily be misconstrued as GPS jamming. Given the current state of international tensions, such a mistake could lead to unwarranted escalation.

Everyone talks about the space weather, but at least NOAA does something about it.

Tuesday, January 25, 2022

Informed Delivery

 The U.S. Postal Service (USPS) has a feature they offer called Informed Delivery (ID). It's free to residential customers. I signed up for it. Most every day in which mail is delivered - around 7AM local time for me - you receive an email containing black & white scanned images of the paper mail you can expect to receive at the specified street address in the next few days. The USPS has to scan all paper mail. That's the only scalable way to sort and route it. They have to scan it whether I sign up for ID or not. Considering the volume of mail, the variations in address formats, and the support for even hand written envelopes, it's a remarkable technological achievement.

But now I wonder: who else can get this ID email for my address? Can law enforcement request it? Does it require a subpoena or a search warrant? Or is it considered public information, like the stuff in your trash bin waiting for pick up at your curb? Do the laws restricting domestic surveillance prevent the CIA or NSA from receiving it? What about the FBI or the DHS? Who else might have access to it? Can it be used to construct a vast network of implied communication, much as intelligence organizations do today with social media accounts?

Maybe this is how conspiracy theories get started.


Tuesday, March 23, 2021

Where the RF Meets the Road

My Hazer project (com-diag-hazer) - the basis for all my GPS/GNSS work that I've written about - depends mightily on my Diminuto project (com-diag-diminuto) - my C systems programming library and framework - for its infrastructure. Testing some of the Hazer features finally got complicated enough that I built a dedicated test fixture for that project, just as I had to build a little test fixture for  Diminuto that I described in Where the Silicon Means the Road.

Diminuto GPIO/Hazer 1PPS Test Fixture

While Hazer's gpstool utility supports a wide variety of GPS/GNSS receivers, the one I chose for the test fixture is a SparkFun board equipped with a u-blox NEO M9N device. Here is some gpstool output generated while exercising the M9N.

Hazer gpstool using a u-blox M8N

I chose the M9N because it can receive and process transmissions from the satellite constellations of the U.S. GPS (a.k.a. NAVSTAR) system, the Russian GLONASS system, the European Galileo system, and the Chinese BeiDou 2 (a.k.a. COMPASS) system simultaneously. This tests more code paths in the underlying Hazer library and in gpstool.

Diminuto GPIO/Hazer 1PPS Test Fixture

The M9N is powered by a USB C connection to a dedicated Raspberry Pi 4B running Raspberry Pi OS, the Debian-based version of GNU/Linux formerly known as Raspbian. The USB connection is also the serial communications channel between the Pi and the M9N. The Pi runs headless; when necessary, I ssh into it from my desktop Mac and use the command line interface (although in a pinch, I have connected up a display, keyboard, and mouse to the Pi, or even attached a USB-to-serial adapter to its console port pins).

Diminuto GPIO/Hazer 1PPS Test Fixture

You can see the SMA Radio Frequency (RF) connector emerging from the container, where it connects to the coaxial cable of the GNSS antenna used by the M9N. The small multi-band active patch antenna sits on the top shelf of my workbench within view of the window.

u-blox Multi-band Active GNSS Antenna

You can also see a green wire and a blue wire that run from the M9N container to the Raspberry Pi.

The green wire connects the 1PPS ("one pulse per second") signal from the M9N to a General Purpose Input/Output (GPIO) pin on the Raspberry Pi. 1PPS is a standard precision timing signal derived from the GNSS solution by the receiver (although not all of them export it, and when they do, the mechanism varies). I make use of 1PPS in all of my GNSS-disciplined Network Time Protocol (NTP) micro servers that I've written about previously, including the one that incorporates a chip-scale cesium atomic clock. When gpstool is configured to monitor the 1PPS signal, it uses Diminuto's GPIO feature to interrogate the input GPIO pin using the select(2) system call inside a dedicated POSIX thread (which is also a Diminuto feature).

The blue wire connects an second, output, GPIO pin on the Raspberry Pi to an LED in the little container where the M9N is mounted. When gpstool monitors 1PPS, it can be configured for the thread to strobe the second GPIO pin to follow the 1PPS signal. This is not just a test of Hazer and gpstool, but a test of Diminuto's GPIO feature as well.

Diminuto GPIO/Hazer 1PPS Test Fixture

My hardware engineer colleagues will confirm that I'm not a hardware guy by any stretch of the imagination. But hacking together these little hardware test fixtures gives me peace of mind. As long as I see that LED blinking at 1Hz, I know that, while my code is not perfect, it is at least sane.

Tuesday, March 09, 2021

A Static Route Map Display Using OpenStreetMap

Sometimes I need a moving map display in real-time to track my projects at they move around in the field. Sometimes I want to playback a stored dataset of geolocation coordinates. And sometimes I want to see a static route map that shows the path a project took in the field. This latest addition to my Tesoro project does that. As before, it uses the Leaflet client-side JavaScript library and an OpenStreetMap tile server.

Here are a couple of static route maps generated from geolocation datasets collected from field testing. (You can click on either one to see a larger version.)

Screen Shot 2021-03-08 at 6.03.25 PM

Screen Shot 2021-03-09 at 9.56.20 AM

This new feature adds another web page, choosedataset.html, and another client-side JavaScript program, routemap.js, to the project. As with the moving map display, occasionally useful information is displayed in the browser's JavaScript log, as shown in the second image.

(Blogger kind of sucks for rendering code. Each example below in the monospace font is intended to be a single line.)

My Hazer C-based GNSS software stores geolocation data in a Comma Separated Value (CSV) format that makes it simple to import into spreadsheets and to post process for other uses. Each line of the CSV dataset looks like this.

"neon", 1299, 4, 0, 10, 1600356403.090779879, 1600356402.000000000, 39.7328371, -105.1543085, 0., 1766.500, 1745.000, 0., 4.948000, 127.340000000, -1.10049, 0.40705, 127.34082, 0.52130, 0.46396, 1.12472, 0, 0\n

My moving map display described in A Moving Map Display Using OpenStreetMap and subsequent articles steers the moving map, in real-time or in playback, using JSON datagrams, each datagram containing the coordinates for the next point. Each individual datagram looks like this.

{ "NAM": "neon", "NUM": 1300, "TIM": 1600356403, "LAT": 39.7328281, "LON": -105.1542851, "MSL": 1766.500, "LBL": "2020-09-17T15:26:43Z" }\n

The dataset used by the static route map is a JSON object containing an array of latitude and longitude coordinates. All of the points on the route are contained in a single array that is imported by the new software and stored in memory for processing. The dataset looks like this (although is typically much larger).

{ "PATH": [ [ 39.7762445, -105.1621035 ], [ 39.7762428, -105.1622863 ], [ 39.7762416, -105.1624700 ], [ 39.7762408, -105.1626533 ], [ 39.7762401, -105.1628366 ], [ 39.7762396, -105.1630200 ] ] }

Hazer contains scripts to convert its CSV format into JSON datagrams for playback

csvplayback 192.168.1.253:tesoro  dat/yodel/20200917/vehicle.csv

 or in real-time 

csvfollow 192.168.1.253:tesoro dat/yodel/20200915/vehicle.csv

or into a JSON dataset

csvdataset < dat/yodel/20200915/vehicle.csv > vehicle.json

which can be used directly by the Tesoro map software.

Because the JSON object for the static route map has to all be stored in memory for processing by the Leaflet library, there is a limit to how many points you can render at a time. I ran into the same issue using the XML-based Keyhole Markup Language (KML) when rendering routes with Google Earth. But the second image above rendered a dataset of more than 8500 data points, collected from a field test almost two and a half hours long, with no discernible delay.

But for those really large datasets, the Hazer csvdataset script takes an optional modulo argument to sample the incoming CSV data. The Hazer gpstool utility stores CSV records at approximately 1Hz. So an argument of 10 would sample every tenth data point, capturing the target location about every ten seconds. But no matter the argument value, the first and last data points are included so that the start and end of the route is always rendered.

csvdataset 10 < dat/yodel/20200915/vehicle.csv > vehicle.json