Monday, October 15, 2018

Tick

I've decided that I might as well accept the Buddhist view of time: that time itself is an illusion and our conception of it is merely a measure. The only way we have to perceive time is in the relative order of events that take place, regardless whether time somehow exists independently of these events or not. All timekeeping ultimately depends on a frequency source - an oscillator - which is nothing but a generator of evenly spaced events.


(clock with a 4Hz oscillator using a pendulum resonator and a deadbeat escapement)

Every oscillator makes use of a resonator, some source of periodicity that we take from nature: the motion of the sun, the fall of a drop of water, the swing of a pendulum, the rotation of a balance wheel, the vibration of a quartz crystal, the hyperfine transition of a cesium atom. If something happens faster than the interval between the beats of that oscillator, the only way to measure that interval is to use an oscillator with a higher frequency resonator: the transition of an aluminum atom or a ytterbium atom. How do we use these oscillators? By treating each beat of the oscillator as an event, and counting the number of events that occur during the time interval we want to measure.


(watch with a 6Hz oscillator using a balance wheel resonator and a lever escapement)

Is there a maximum possible frequency? We think so: the reciprocal of one Planck time, which is about 5.39 x 10-44 seconds. It's the amount of time it takes a photon to cross a Planck length. It is the shortest time interval physicists believe can meaningfully occur, the duration it takes for the fastest possible object to cover the shortest possible distance found in nature. My calculator tells me that such a hypothetical Planck-frequency oscillator beats at a frequency of about 1.85 x 1043 Hertz. That's a lot of Hertz.


(slow motion deadbeat escapement creating the tick tock)

What happens between the beats of this hypothetical Planck-frequency oscillator? The question has no meaning; we believe one Planck time is the smallest possible interval that can occur. Time might as well not exist between the beats of a Planck-frequency oscillator. If we want to talk about the time between any two events, we have to find a frequency source that generates events faster than the interval we want to measure. Any other notion of time is purely an abstract concept.  (I'm told there may actually be even shorter time intervals in the field of quantum gravity, but they are apparently impossible to measure; what this might mean is left as an exercise to the reader.)

Capture
(snapshot of an oscilloscope on a 10MHz oscillator with a cesium atomic resonator)

I didn't come to this notion by reading about the more esoteric aspects of physics (as much as I enjoy doing that). I did it by developing and debugging real-time firmware that shaped the emission rate of ATM cells on a SONET channel carried over an OC-3 optical fiber. By building a stratum-0 NTP server with a cesium reference oscillator. By assembling an educational model of a mechanical clock.

Untitled
(ytterbium lattice optical atomic clock at NIST Boulder Labs)

Tuesday, September 18, 2018

We have met the enemy, and he is us.

One of the side effects of having five GPS-disciplined NTP servers in your home - three home-brew, two commercial - is that you become sensitized to issues with the Global Positioning System.

The other day I was sitting at my desk in my home office looking at cat memes doing some bleeding edge research and development, when out of the corner of my eye I noticed that the GPS lock LED on the home-built clock on the right side of my desk wasn't blinking. I ssh-ed into it, poked around, and verified that all the software was running; the problem was with its GPS receiver. Then I noticed that the home-built clock on the left side of my desk has just lost GPS sync too.

I whipped my Herman Miller Aeron chair around to look at the two small commercial units on my lab bench. The 1PPS LED on the Time Machines TM 1000A had stopped blinking. While I was trying to wrap my poor old head around that, the tiny color LCD display on the Leo Bodnar Electronics LeoNTP right next to it lit up with a red warning message about GPS lock being lost.

My first inclination was to go down to the basement to prepare for the coming apocalypse. Instead, I exercised some rare (for me) restraint and sent a query to Time Nuts - a mailing list for folks even more obsessed with precision timing than I am (they do exist).

In short order, Graham in Austin Texas kindly pointed me to the FAA web site where one can look up NOTAMs, notices of issues possibly affecting aviation and pilots, one of the categories of which is outages in the Global Positioning System. Here's the specific NOTAM he pointed me to.
ZDV   DENVER (ARTCC),CO. [Back to Top] !GPS 08/260 (KZDV A0287/18) ZDV NAV GPS (WSMR GPS 18-20) (INCLUDING WAAS, GBAS, AND ADS-B) MAY NOT BE AVBL WI A 359NM RADIUS CENTERED AT 333345N1063840W (TCS054036) FL400-UNL, 311NM RADIUS AT FL250, 215NM RADIUS AT 10000FT, 223NM RADIUS AT 4000FT AGL, 169NM RADIUS AT 50FT AGL DLY 1830-2230 1809031830-1809082230
It took some fu on my part to decode it, but it wasn't that hard.

ZDV ARTCC is the Denver Air Route Traffic Control Center.

333345N1063840W is 33°33'45.0"N 106°38'40.0"W, the location at which the source of the GPS interference is centered, which is smack dab in the White Sands Missile Range in New Mexico. (For a good time, click on the Google Maps link I provided, drop into the satellite view, and drill down until you can see the parking lot where they parked their equipment.)

359NM is 359 nautical miles, an area which includes my home near Denver Colorado.

1809031830-1809082230 is 2018-09-03 18:30 UTC to 2018-09-08 22:30 UTC, which is the time window in which I noticed my clocks losing GPS.

GPS disruption has become enough of an problem that there is now a U.S. Coast Guard web site where you can report issues. Most of them appear to be either user error or product failures. But some of them are probably related to testing of deliberate GPS interference - either as a field tactic or to evaluate their ability to deal with it - by our own military. Or others.

Don't say I didn't warn you.

Monday, August 27, 2018

Practical Geolocation II

In Practical Geolocation I mentioned that I had ordered a GlobalSat BU-353W10 GPS receiver. Like most of the receivers I've tested, this device is a puck at the end of a USB cable. The puck contains all the active electronics including an amplified patch antenna.
N.B. If any of the images in this article appear funky, or if you just want to see a larger view, click on the image to be taken to another version. Or try the web version of the article which is accessible from the mobile version via a link at the bottom of my blog. I've noticed that the images in the mobile rendering of this article seem to tickle a bug in both Safari and Firefox on my iPhone, causing wackiness to ensue. This doesn't seem to be an issue on my iPad, or on my Mac. Your mileage may vary.
Untitled

Like the Navlocate GR-803G I described in that previous article, the BU-353W10 is based on the Swiss-made U-Blox 8 chipset. U-Blox 8 has a number of advanced features I crave, like enhanced signal sensitivity, multiple RF stages, seventy-two channels, ensemble fixes based on both the U.S. GPS and the Russian GLONASS satellite constellations, and support for the proprietary UBX binary protocol. I've also had good experiences integrating and using earlier U-Blox chipsets board-mounted in prior embedded projects.

The BU-353W10 is a few dollars more expensive than the GR-803G, but is available from Amazon.com for US$45 with two-day shipping, where as I ordered the GR-803G from eBay and it was shipped from China.

The BU-353W10 is the third in a series of GlobalSat (formerly USGlobalSat) devices, and those models, the BU-353S4 and BU-353S4-5Hz, both based on the SiRF Star IV chipset, have worked flawlessly. (SiRF is now owned by Qualcomm.)

All of this made me kindly disposed towards this new GlobalSat device. What gave me pause regarding the BU-353W10 is all the warnings on both Amazon.com and on the GlobalSat web site about how the devices was specific to Windows 10 and not supported on MacOS or Linux. Even its model designation had a "W10" in its name. So I anticipated having a bit of a mystery to solve.

Since I'm not writing a detective novel, I'll just jump to the conclusion: the BU-353W10 worked just fine with my Hazer software. I haven't tested it with anything else, but I would expect it to work fine with the GPSd and Lady Heather open source tools I mentioned in that prior article, at least on a Linux host. I wondered what exactly Windows 10 required of its GPS receivers, but some web searching hasn't enlightened me in that respect. But I took a conservative approach to reverse engineering the BU-353W10, which I thought someone might find useful for the next under-documented GPS receiver that comes along.

I'm typically wary of new USB devices. So the first thing I did was plug the BU-353W10 into a USB port on a Raspberry Pi - a system whose entire microSD card I could easily reformat and reload with a new OS should the worse case scenario occur - and carefully watched the system log.

GlobalSat BU-353W10 syslog

The device enumerated on the USB bus, and its vendor and product identifiers, 1546 and 01a8 respectively, were exactly what I expected from the U-Blox 8 chip, and were the same as those reported by the enumeration of the GR-803G.

Like that earlier device, the BU-353W10 instantiates a /dev/ttyACM device. Many of the USB GPS devices I've tested instead instantiate as a /dev/ttyUSB device.

BU-353W10 dev

The latter is intended to represent a UART-over-USB device, while the Abstract Control Module (ACM) is more typically intended to be a modem-over-USB. I'm told that the reason many devices appear as ACM devices is that it's a simpler interface, and may place less requirements on the host computer. Other than the device name, I haven't had to make any changes to using either type of device in my Hazer software.

You will notice that the standard behavior is for the /dev/ttyACM0 device to only be usable by user root or members of group dialout. There are several ways to address this. The worst choice would be to run all your applications as root (but lots of embedded Linux projects do exactly that). The best would probably be to alter the rules in /etc/udev/rules.d to change the owner, group, and permissions of the /dev/ttyACM device to something more appropriate when the BU-353W10 enumerates as v1546p01a8 on the USB bus. But I chose instead to add my user, pi in this case, to the dialout group (something I had already done long ago).

BU-353W10 dialout

I could have next just fired up Hazer's gpstool. In retrospect, that would have worked. But while gpstool can log a lot of stuff, it ignores anything its NMEA and UBX state machines do not recognize. Since I was still suspicious of the device, I chose instead to fire up some tools from my Diminuto library that I find useful for reverse engineering serial-port-like devices: serialtool, phex, and dump.

serialtool is a Swiss Army-knife for serial devices. It supports several different kind of loopback tests, but in its most basic use it simply allows you to set the serial port parameters (including modem control) however you see fit, read from the device and write to standard output, and read from standard input and write to the device. serialtool would tell me anything and everything that the BU-353W10 was emitting.

phex (pronounced "fex") reads from standard input and emits whatever it finds to standard output, expanding any non-printable characters to ANSI C-style escape sequences, and handling the wrapping of the screen to whatever width you specify (defaulting, as usual, to eighty, in a continuing tribute to our punch card days).

For devices that produce mostly non-printable output, phex output is a little busy. dump produces a hexadecimal dump along with printable characters that will seem familiar to a lot of old timers.

Here is a snapshot of serialtool used with phex.

BU-353W10 phex

I didn't see anything untoward: typical NMEA sentences.

Here is a snapshot of serialtool used with dump.

BU-353W10 dump 1

Again, nothing unexpected: printable NMEA sentences terminated by a carriage return and a line feed.

Which you find more readable, phex or dump, will depend on the output of the device you are examining, and maybe what you're used to seeing in your own development efforts.
You will have already realized that these tools aren't specific to GPS. I developed them as part of Diminuto long ago for my embedded Linux reverse engineering, integration, and troubleshooting toolkit. The base functionality of these tools are C functions in the Diminuto library, so they can be called from other applications as well, as we'll see with gpstool below. Putting most of the heavy-lifting in a library, and building a relatively simple command line tool around it, facilitates testing by placing the business logic in the library - where it can be exercised by standalone unit test programs - and the user interface in the command line tool - where it can be used from scripts as a functional test. This has been my preferred development pattern in this domain for a long time.
Next step was to use the Hazer ublox8 functional test script. Since the BU-353W10 uses the U-Blox 8 chipset, we would expect this script, which talks to any U-Blox 8 device, to work. The script not only logs all of the output of the device, it sends binary UBX commands to the device to enable it to periodically emit binary UBX packets with additional and more detailed information than can be had just using the ubiquitous NMEA standard output. The script, which is implemented using gpstool, logs all of the input to and output from the device in phex-style format, including the binary UBX packets. (You can ask gpstool to emit UBX packets read from the device in dump-format as well if that's your preference.)

BU-353W10 ublox8

I let this run for a while and didn't see any complaints from gpstool.

The last step was to create and run a new bu353w10 functional test script... which, as it turns out, is actually identical to the gn803g functional test script. I did in fact try the gn803g script first and verified that it worked, before creating a new script specific to the BU-353W10. These scripts use the full screen feature of gpstool which uses ANSI escape sequences, and some output formatting trickery, to create a dynamically updating display.

BU-353W10 bu353w10

Here's the first time we notice something interesting. At the end of every line produced in this format is a timer value that tells you how long the data displayed has until it is considered stale and its output will be suppressed. The GR-803G GPS receiver updates the satellite view, reported by the NMEA GSV sentence, every second, so for that device this lifetime value sticks at the maximum of ten seconds I specified on the gpstool command line in the gr803g script.

But here, the timer decrements in the bu353w10 script's output until the BU-353W10 refreshes it by emitting more GSV sentences, apparently every five seconds. That's completely adequate for my purposes, but it is a difference between the GR-803G and the BU-353W10, two devices that otherwise seem pretty similar. I haven't tried it, but you should be able to use gpstool to send UBX commands to either device to change the frequency at which they emit GSV sentences. (Yeah, you totally can; see below.)

I also noticed that the GR-803G emits the NMEA VTG sentence, providing course over ground (COG) true bearings in decimal degrees, while the BU-353W10 does not. I did this by using gpstool to collect a minute of output, and then post processing the resulting data to find all the unique sentences generated. This is a lot simpler than it sounds.

gpstool -D /dev/ttyACM0 -b 9600 -8 -n -1 -L bu353w10.dat -v
# Wait for a minute and then control-C out of the program.
awk -F, '{print $1;}' < bu353w10.dat | sort | uniq

You can compute COG yourself from the differences in successive position fixes. It is also possible that you can use gpstool to send a UBX command to the BU-353W10 to enable VTG output; I haven't tried it (yet). (No, wait: I did; see below.)

I walked into this little project not knowing whether I'd be spending a morning or a few days getting the BU-353W10 to work. Or maybe it would never work. That's typical of the kind of tasks I am called upon to do. As it turns out, this task was almost a no brainer. Despite all the warnings regarding the support (or lack of it) of the BU-353W10, it was a simple matter to integrate it into Hazer. I wouldn't expect doing something similar with GPSd would be that different. But it was a good example of the kinds of tools I can bring to bear on learning how a new device works just minutes after unboxing it.

Update (2018-08-27)

You can easily alter the frequency of the GSV sentences and enable the emission of the VTG sentence just by adding a couple of -W command line parameters to gpstool to request a configuration change to the U-Blox 8 chip using the proprietary (but printable) $PUBX message.

gpstool -D /dev/ttyACM0 -b 9600 -8 -n -1 -E -t 10 \
    -W '$PUBX,40,GSV,0,0,0,1,0,0' \
    -W '$PUBX,40,VTG,0,0,0,1,0,0'

I've added those parameters to the bu353w10 functional test script and verified it by capturing the output data as described above.

BU-353W10 bu353w10 2