I ran into an issue with the u-blox USB drivers on Windows yesterday that ended up costing me a fair bit of time. I thought I’d share it here in the hope it may help others that may be running into similar problems.
U-blox has recently switched from using a COM port driver to using a “sensor device driver” on Windows. This seems to have caused some problems and does not appear to be fully functional yet. They have published a flowchart on their website to help users decide whether to use the new drivers or not and how to rollback to the standard windows drivers if necessary. It is not so easy to find it by going directly to their website, at least it wasn’t for me. I only found this document through a Google search while looking for other people who had also run into this problem.
Here is a copy of the document but it may be too small to read here and may be out of date by the time you read this so I suggest you click on this link to take you to the original document.
I don’t understand all the implications of this change but I can explain what happened to me and what I had to do to fix it.
I first ran into the problem when working with two CSG M8T receivers, both with USB interfaces. I had previously connected one of them to my computer but not the other one. I wanted to be able to communicate with both receivers using the u-center eval software and RTKNAVI. After plugging in USB cables from both receivers into the computer, the receiver that had been previously connected appeared as it usually does as a COM port but I was unable to see the new receiver with either program.
I am using Windows 10, and it appears that it had automatically downloaded the new sensor device driver for the new receiver but continued to use the old COM port driver for the receiver that had been previously connected. Neither RTKNAVI or u-center seemed to be able to see the new receiver since it had not been assigned a COM port.
To access the new receiver I had to follow a process similar to what is described in the blue circle above. First disconnect from the internet so Windows can’t find the new driver. Then plug in the GPS receiver to the USB port. If it hasn’t been plugged in before Windows will probably assign the standard COM port driver to it. If it has been plugged in before but only recently, the new driver has probably already been downloaded and it will use the new driver. If so, open Windows Device Manager. The receiver will appear under “Sensors” instead of under “Ports” as it used to do. Uninstall the driver using Device Manager, being sure to click the box that deletes the driver files. Windows will then revert to the standard COM port driver and the receiver will appear in the Device Manager list under “Ports”.
This is what we want but if we leave it like it is, Windows will download the new driver as soon as you connect back to the internet again. To prevent this from happening we need to tell Window not to do this. Do this by connecting to the internet, waiting for the new driver to download and the receiver to appear back under “Sensors”. Then use Device Manager to “Rollback” the driver to the previous version. This option is in the “Driver” tab in the Device Manager.
After doing this, both receivers appeared as COM ports and I was able to communicate with them with RTKNAVI but I still had trouble with u-center. Unfortunately I am a little less clear about what I had to do to get this working again. I suspect rebooting may have been enough but I ended up also downloading the u-blox Virtual COM Port driver and installing that (as describe in a different step in the flowchart), so it’s possible that is also necessary.
If anybody else has a more complete understanding of what’s going on, maybe they can add some insight in the comments section.