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.

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.



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.



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).



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.



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

Here is a snapshot of serialtool used with dump.



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.)



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.



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.

Practical Geolocation

Geolocation, via the Global Positioning System (GPS) or other satellite constellations, keeps cropping up in my line of work, whether I'm working on software for a cellular base station or an in-flight entertainment system for business aircraft. This won't come as a surprise to anyone. Nowadays we are all depending on smartphone apps like Google Maps or the navigation system in our vehicle dashboard to get us from place to place. And even if we somehow know where we're going without a vast infrastructure of global navigation satellite systems, mobile radio telecommunications, and Earth mapping from space, to help us, we're still relying on GPS for other services like precision timing, whether we realize it or not.

The good news is that it's never been easier to make use of what was once an exotic space-based technology available only to the military. As I have enumerated in the past, there is a slew of inexpensive, easily available, and perfectly serviceable GPS receivers, that can be straightforwardly integrated into your embedded application, via USB, serial port, or even wirelessly via Bluetooth. In this article, I'll reiterate the units I've found the most useful, and why, and the tools I've installed or developed to make use of them.

Hardware

GlobalSat BU-353S4



The best thing about the BU-353S4 is that it's easily available: US$30 and change from Amazon.com, a few bucks more for two day shipping if you're really desperate. It uses the well regarded SiRF Star IV GPS chipset, has the ubiquitous Prolific chip as its serial-to-USB converter, runs at a modest 4800 baud (useable with the finicky real-time GPS feature of Google Earth Pro), and provides a position update once every second. It has forty-eight radio channels, but only one RF stage, so it only receives GPS (versus receiving both the U.S. GPS and the Russian GLONASS constellations).

If it weren't for the special features of the other receivers I'll describe below, the BU-353S4 might be the only GPS receiver I'd ever need. There is a similar model that reports five times a second, but you're going to pay significantly more for something you probably don't need unless, maybe, you are using it in an aircraft.

(Update 2018-10-18: I've switched to the GlobalSat BU-353W10, and I suggest you do too; see below.)

NaviSys Technology GR-701W



The key feature of the GR-701W that is rare amongst inexpensive GPS receivers is that it exports a one pulse per second (1PPS) timing signal via the Data Carrier Detect (DCD) line that is visible to software even over the USB interface. The 1PPS signal is syntonized to the GPS timing signal that is in turn syntonized to the network of atomic clocks in the Global Positioning System. While the USB interface jitters the 1PPS a bit, you can still build a completely serviceable GPS-disiplined stratum-1 Network Time Protocol (NTP) micro-server using not much more than the GR-701W, a Raspberry Pi, and some open source software.

For just geolocation applications, you can ignore the 1PPS, and you have a GPS receiver that is based on the excellent Swiss-made U-blox 7 chipset, also uses the Prolific serial-to-USB converter, runs at 9600 baud, and delivers an update once per second. The receiver has fifty-six radio channels but still just one RF stage.

I have ordered my GR-701W units for US$50 from a seller on Etsy who, as it turns out, is the project manager for the open source NTPsec project; I've used the NTPsec NTP daemon in a number of projects, including my own Cesium atomic clock.

TOPGNSS GN-803G



I keep a GN-803G in my geolocation kit because it is the first relatively inexpensive USB GPS receiver I found that has multiple RF stages, so it receives and processes signals from both the U.S. GPS constellation and the Russian GLONASS constellation simultaneously. In fact, it computes an ensemble fix, using a mixture of satellites from both constellations, which should allow it to exploit the dynamic orbital geometry of both systems to maximize accuracy by minimizing the Dilution Of Precision (DOP), a measure of accuracy based on the spatial separation of the satellites: broader separation, resulting in lower DOP values, is better.

The GN-803G uses the advanced U-Blox 8 chipset, which natively provides a USB interface, runs at 9600 baud, and updates by default once per second. Like the U-blox 7 chipset used by the GR-701W above, the U-Blox 8 chipset supports the proprietary binary UBX protocol in addition to the standard ASCII NMEA protocol that is ubiquitous among GPS receivers. I have used my own tools to send UBX packets to the GR-701W to enable it to generate periodic UBX packets containing much more detailed information than is available via NMEA. This alone makes the GN-803G of interest to geolocation and precision timing experimenters.

The downside is that I have only found the GN-803G on eBay, shipping from China, albeit for a paltry US$25; it can take a while to get one. I've recently discovered the GlobalSat BU-353W10 - US$45 from Amazon.com - that, like the GN-803G, uses the U-Blox 8 chipset; I'll find out shortly whether it's a usable alternative to the GN-803G.

(Update 2018-10-18: I did, and it is; see below.)

N.B. I do have a twinge of concern from time to time about ordering a USB device from who-knows-where and plugging it into one of my computers. I tend to first plug them into a Raspberry Pi and then carefully watch the system log.

Garmin GLO



I include the Garmin GLO - a battery-operated GPS receiver that connects via Bluetooth - because it solves a problem that the USB-based receivers do not: I can easily use it with my Pixel C tablet. Most smart mobile devices come by GPS because of their cellular chipsets; WiFi-only devices like my Pixel C need a little help. Connecting the GLO, or any Bluetooth GPS receiver, to the Pixel C requires not just Bluetooth, but a Bluetooth GPS Android application that receives the NMEA sentences from the receiver wirelessly and forwards them via an internal "mock GPS" interface.

Garmin is pretty close mouthed about the chipset the GLO uses. But the device updates ten times per second, making it useful for speed daemons (and, I gather, private pilots). The GLO can be had from Amazon.com for about US$100.

Update 2022-11-02: The Garmin website suggests the newer GLO 2 - which is rumored to differ from the GLO only by its longer battery life - uses a MediaTek or MTK chipset. Also, both the GLO and GLO 2 are documented to receive both signals from the GPS (U.S.) and GLONASS (Russian) constellations, but my GLO and both of my GLO 2 units only emit NMEA sentences with the talker field set to "GP", indicating just GPS.

GlobalSat BU-353W10 (added 2018-12-18)



This is the USB-connected GPS device I'm using for all of my own geolocation software development now. It's easily found on Amazon.com for a mere US$40. Which is a paltry sum considering all you can do with its U-Blox 8 receiver. The box implies that it's specific to Windows 10, but it worked trivially with my own software on Ubuntu and Raspbian Linux. I've extended my own software to handle not just the usual NMEA sentences but also the proprietary binary UBX messages supposed by U-Blox devices. The amount of capability in this device, specifically in the U-Blox 8 chipset, is truly impressive.

Software

GPSd

The GPS daemon, a standard package available in all the usual Linux distributions like those based on Debian, includes not just software that reads and interprets NMEA sentences from multiple GPS devices concurrently, but a bunch of useful tools including both command-line and window-based clients. A snapshot of the xgps client is shown below.



I've used GPSd in all of my GPS-disciplined timepieces, in conjunction with the NTPsec NTP daemon. It would be my go-to tool in any Linux-based production system needing geolocation or precision timing. I've never had to write my own client to the daemon (the NTPsec NTPd has a built-in interface), but I don't expect it would be hard to do so.

Lady Heather

Lady Heather is an open source software package used to monitor and evaluate GPS-disciplined frequency standards - that is, precision clocks that are disciplined to GPS time by a GPS receiver. It includes a flexible interface with a real-time display that provides a wealth of information - more than I currently understand - about the GPS receiver under test (but it sure is awesome to watch).



Of particular interest above is the map in the lower right that shows the positions over time of satellites used in the position fix. The large dark area at the top of the map is in the direction of the inside of my office. The rest of the map indicates satellites received through my office window. The other small dark spots suggest the position of obstructions like trees and buildings outside my office that block reception of satellites low on the horizon. I have found this map useful for GPS antenna placement.

I first used Lady Heather to test my NTP server based on a Chip-Scale Atomic Clock (CSAC). I've since stood up a Raspberry Pi with an LCD display and a GR-701W that sits on my desk, which uses Lady Heather to monitor the Global Positioning System, plus a script that uses tools in NTPsec to keep track of all six NTP servers running on my local network and compare them to the UTC(NIST) time that an ensemble of NTP servers at the U.S. National Institute of Standards and Technology are emitting.

("Lady Heather" is apparently a dominatrix that is a recurring character on the television series CSI: Crime Scene Investigation that takes place in Las Vegas. I've never watched CSI. I've been to Las Vegas many times, but have never checked out the CSI "ride" I've noticed at the MGM Grand resort. Maybe I'm missing something. Maybe next trip.)

Hazer

Hazer, and an underlying library Diminuto, are my own C-based software tools that I've used to test and evaluate GPS receivers. I am fond of saying that I can only learn by doing. So when I wanted to really understand the stuff being emitted by GPS receivers and how to make use of it, I ended up writing my own code to deal with it. The result has turned out to be a useful toolkit.

Hazer is a library of functions that parse NMEA sentences and UBX packets. Because it was intended for embedded systems, it only uses library functions that are typically part of the standard C library (although I have only used it on Linux systems, so exactly how portable Hazer might actually be is open to debate). The Hazer distribution includes a suite of unit and functional tests, some of which make use of less typical Linux capabilities; these depend on my Diminuto library of Linux systems programming functions. Most of the functional tests make use of Hazer's gpstool, a sort of Swiss Army Knife for the Hazer library.

Here is a screen snapshot of gpstool running against a GN-803G.



The tool emits the latest NMEA sentence or UBX packet received from the device, the most recent sentence or packet transmitted to the device, the time and position information received from the device, and information about what satellites in which constellation were used to generate the solution, the quality of the solution, and information about each individual satellite currently being received (whether it contributed to the fix or not).

Each line has associated with it a timer that indicates when the information will expire and that is reset whenever the data associated with that line is updated; in this example I used a command line option to set the lifetime to ten seconds. This is done because although NMEA does a good job telling you what it is receiving, it isn't always good about telling you when it is no longer receiving something - for example, if the satellite lock is lost - which would place the current solution in doubt.

Each line also indicates from which satellite constellation that data was derived: GPS for the U.S. system, GLONASS for the Russian system, and GNSS (for Global Navigation Satellite System, the generic term for this capability) for an ensemble solution that includes data from more than one system.

gpstool can output data in a sequential log format, but the example above uses ANSI escape sequences to display data that is updated dynamically in a full screen format. It's a lot simpler than it sounds; the tool mostly uses some simple sequences to position the curser, erase the entire screen from there to the end, and then rewrite that entire part of the screen all at once. Thanks to a fast screen display, a persistence of vision effect, and some careful output formatting on my part, individual fields appears to update dynamically. Here is a video of about a minute of gpstool running in full screen mode.



I have found Hazer and gpstool useful for testing and evaluating GPS devices. I have also used it to integrate GPS devices in real-time with tools like Google Earth. For an example much simpler than the one I just cited, the second pair of numbers in the position line of gpstool

POS 39*47'39.07"N, 105*09'12.27"W   39.794186, -105.153411

has latitude and longitude in a decimal degree format that can be cut and pasted directly into either Google Earth or Google Maps.

Hazer has also been instrumental in my understanding how devices like the GR-803G compute and report ensemble fixes. For example, when the GR-803G reports active satellites for an ensemble fix, it emits two GSA sentences, both with the "talker" specified not as GPS or GLONASS but as the generic GNSS. This is ambiguous as to whether the satellites in both messages were used together to compute a position solution, or whether the second GSA message is an update/replacement to the first GSA message. It turns out it's the former. The satellites in each GSA message are all either GPS and WAAS satellites, or all GLONASS and WAAS satellites. Later versions of NMEA include an additional GSA field resolve this ambiguity. But on the GR-803G, Hazer infers this just from the satellite identifiers.

WAAS, for Wide Area Augmentation System, is a system devised by the U. S. Federal Aviation Administration to transmit additional corrective geolocation information from geosynchronous satellites like Inmarsat, based on measurements performed at fixed terrestrial GPS receivers at precisely known locations. Its purpose is to improve the accuracy of position fixes for commercial aircraft. This allowed the FAA to narrow the separation of "air lanes" used in commercial aviation in the United States, increasing the density of air traffic, and to provide accurate enough position fixes to be useful in take-off and landing.

WAAS is an example of a Satellite Based Augmentation System (SBAS). Many of the latest GPS chipsets are capable of receiving SBAS corrections from one or more systems. (Not too long ago on one flight, I happened to see a jet airliner zip by in the opposite direction so close I could almost see inside the cabin windows. I suddenly had a visceral appreciation for precision satellite navigation.)

I have tested Hazer with all the GPS devices I cited above, and many more.

Excuses

You haz none. GPS receivers are available in a broad range of prices, capabilities, and hardware interfaces. There are all sorts of open source software packages available to make using them easy. Get your geolocation groove on.