However, the AutoRoute team has completely forgotten to use the new interfaces for GPS sensors that may be present in Windows 8 devices. What I find truly ironic about this is that Microsoft trumpets the fact that AutoRoute 2013 now has support for the Touch features of Windows 8: As you can see, AutoRoute 2013 expects to find GPS data arriving via a COM port, and complains that it can’t find the GPS receiver: I downloaded a trial version and installed it on my Lenovo ThinkPad Tablet 2, which has a Broadcom GNSS Gelocation Sensor in it. Here for example is the very latest version of Microsoft’s AutoRoute 2013. So, as you might expect, traditional Windows navigation software, which has been written expecting to find GPS data coming in via traditional COM port interfaces, won’t see the new generation of GPS receivers being built directly into PC hardware running Windows 8.Īnd so it is. The point being that this means that there is a new set of interfaces for developers to use, and they are different from the traditional COM port interfaces. In the development of Windows 8, support for a variety of sensors, including GPS, was built into the operating system, and exposed by a new set of APIs. These days, they are “virtual” ports set up over a Bluetooth or USB connection. In the old days, these were physical RS232 ports. Instead, external devices such as GPS Data Loggers were used to provide GPS data, and interfaced to Windows software applications via Windows COM (communications) ports.

Now the thing is that until very recently, PCs did not have GPS hardware built into them. I had noticed some reports that people weren’t able to get their navigation software to interface with the GPS sensor built in to some Windows 8 tablets. I see that I’ve used the phrase “open mouth, change feet” a number of times in the life of this blog to describe the continuing ability of Microsoft to snatch defeat from the jaws of victory.

Streets and trips 2013 serial