You know that GPS thingy? You know, the one that tells you your location anywhere on earth? Yes, that’s the one.

So, your smartphone has GPS. But your laptop most likely doesn’t. And there is a reason for that.

GPS in a laptop isn’t very useful. For one thing, GPS works poorly without a clear line-of-sight to satellites, which means it isn’t super useful indoors. And most people don’t use laptops outdoors. Second, how often are you using a laptop and don’t know where you are, or would otherwise benefit from GPS? Never, right? But there are many situations where that might be beneficial when you are out-and-about, and if you are like most people, you always have your phone with you.

So, for these reasons, phones have GPS built-in, and laptops do not.

At least, most laptops don’t – certainly no consumer-grade laptop would. But there are special-purpose laptops that do have GPS built-in, and often also other functionality like a cellular modem. These are known as rugged laptops. They are tough as nails, just like me. These laptops are used in situations where that kind of additional functionality is required, such as technicians working out in the field.

For a long time I had never come across this particular use case, so I never got my hands on one of these laptops. But recently I was asked to set one up, and one of the things that needed to be setup was configuring a specific program to read and report GPS data.

You would think that would be pretty easy, but this one took me a while to figure out.

It was a rainy Tuesday…

Well…………………….. teeeeeechnically, it was a snowy Thursday. But I digress.

I followed the guide to configure GPS reporting in this particular application and everything seemed right, but it just wouldn’t pull in GPS data. I spent a while double checking everything and, to be honest, blaming this particular program for having a convoluted way to set this up. This program is “enterprise software,” which is a fancy term that means “ugly and not user-friendly,” as far as I can tell.

Eventually I got fed up with it and just wanted to verify the GPS worked in other programs, so I could regain some sense of sanity. This particular laptop came with OEM software out of the box to check the GPS, so I tried that. And… it didn’t work. No data.

While I was troubleshooting this, I was also learning about how GPS devices actually work in software. What I had assumed at the start is that the device would show up in device manager somewhere, and that applications would automatically detect it using some Windows API.

That is kind of how it works, as it turns out. It actually shows up in device manager in two different places. The first place is under the Sensors category, and the second is under the Ports category with the other COM ports. So the driver presents a virtual COM port to the system for other applications to use.

COM ports are basically the windows device name for serial ports. COM ports are basically byte streams, which means they can also be used for plain text – just like a command-line program.

Apparently many GPS devices comply with the NMEA standard. This means that information from the GPS looks like this:

$GPGGA,092750.000,5321.6802,N,00630.3372,W,1,8,1.03,61.7,M,55.2,M,,*76
$GPGSA,A,3,10,07,05,02,29,04,08,13,,,,,1.72,1.03,1.38*0A
$GPGSV,3,1,11,10,63,137,17,07,61,098,15,05,59,290,20,08,54,157,30*70
$GPGSV,3,2,11,02,39,223,19,13,28,070,17,26,23,252,,04,14,186,14*79
$GPGSV,3,3,11,29,09,301,24,16,09,020,,36,,,*76
$GPRMC,092750.000,A,5321.6802,N,00630.3372,W,0.02,31.66,280511,,,A*43
$GPGGA,092751.000,5321.6802,N,00630.3371,W,1,8,1.03,61.7,M,55.3,M,,*75
$GPGSA,A,3,10,07,05,02,29,04,08,13,,,,,1.72,1.03,1.38*0A
$GPGSV,3,1,11,10,63,137,17,07,61,098,15,05,59,290,20,08,54,157,30*70
$GPGSV,3,2,11,02,39,223,16,13,28,070,17,26,23,252,,04,14,186,15*77
$GPGSV,3,3,11,29,09,301,24,16,09,020,,36,,,*76
$GPRMC,092751.000,A,5321.6802,N,00630.3371,W,0.06,31.66,280511,,,A*45

This is just plain text. In fact, you can open up something like Putty, connect it to the COM port listed for the GPS in device manager, and you will see text just like this being output rapidly.

So that is how programs read GPS data. They will allow you to select a COM port and baud rate somewhere.

Problem solved, EZ everytime

Just kidding. Things are never that easy.

In theory, in the magical world where things work the way they should, I could do something like connect Putty to that COM port and see output out of the box.

In practice, that is not what happened. I opened Putty on that COM port and got nothing. So, naturally, like a good little troubleshooter, I tried finding other applications that can read GPS data to see if any of them worked.

All but one of the applications I tried also indicated there was no data on that port. One application, the OEM application, had a scan feature that is intended to find GPS devices on any of the existing COM ports. It seemed to find activity on the GPS COM port, but it also didn’t recognize it as a GPS device – as if there was some device active on that port that wasn’t a GPS.

So the GPS didn’t work out of the box, bummer.

I tried updating drivers through Windows Update, I tried updating the drivers from the manufacturers website, I tried disabling drivers, I tried deleting drivers, and nothing made data show up.

Keep in mind, I was the first person to touch the computer. It was fresh from factory with OEM installed drivers. How is it possible that the OEM application cannot talk to the GPS? This threw me off for quite a while.

Worse yet, I had another laptop of the same model (but several years older) on hand to compare against. It had the same GPS hardware, the same OEM application, and a driver that was a few years older. It had a COM port set up the same way. But on that laptop the OEM application connected to the port correctly and showed the NMEA data. What gives?

The Solution

I eventually stumbled on the solution while I was searching for the correct drivers on the manufacturers website. Here is the driver selection guide on the manufacturer’s website:

So basically, there are two different kinds of drivers. And they wrote this idiot-proof guide (I tested it myself) about how to decide which driver to install.

One driver type – the legacy driver type – is the one that uses the COM ports for “legacy applications,” which apparently included every application I tried. The other driver type – the location API type – is for newer applications using the Windows Location API. I guess the idea was to make a modern interface matching the likes of Android or iOS rather than make applications write interface code for the text NMEA interface.

The thing I still don’t understand is why the driver cannot do both of these things at once. Why can’t it both function as a Location API device and a COM port device? Both of these were listed in device manager, as well, so it would make sense. But apparently that isn’t how it works, and I still don’t know why.

The solution? I followed the flowchart, and it told me to rollback the sensor driver. And whaddya know, it worked, just like that.

I had tried either deleting the COM port device, or deleting both the COM port and sensor device and then updating both via Windows Update. And neither of those actions make it work. You must explicitly roll back the sensor driver, and only the sensor driver.

And you know what happens when you do that? The GPS no longer shows up as a sensor device. Instead, it creates a new COM port, alongside its existing virtual COM port. So I was left with the old COM port which still didn’t function, and the new COM port which did function. Why? Because, that’s why.

Also another fun fact – this enterprise application used another application from Garmin, for some reason, to actually access the GPS data. So it looked like this:

GPS device(COM5) -> Garmin application(COM12) -> enterprise application.

So the Garmin application reads GPS data from a COM port, and then it outputs this information to the enterprise application over another COM port. So two pieces of software on the same machine communicated over a virtual COM port. I have never seen that before – usually it is TCP/IP, or some other sort of RPC/IPC.

In any case, I learned a bit about GPS devices in the process of working on this, so that’s a plus.