Huntervp609

Driver Description Download drivers for IOI u-blox Universal GNSS other devices (Windows 10 x64), or install DriverPack Solution software for automatic driver download and update Are you tired of looking for the drivers for your devices? To use this site to find and download updates, you need to change your security settings to allow ActiveX controls and active scripting. To get updates but allow your security settings to continue blocking potentially harmful ActiveX controls and scripting from other sites, make this site a trusted website.

1 Sep 2020

Article updated 1 Sep 2020:

The integrated u-Blox NEO M8N or M8T GNSS (GPS) receiver in the Mesa 3 Windows and Mesa 2 have several options for drivers to work with different software applications. Options are as follows.

• Latest u-Blox drivers (Default) - A GNSS Location Sensor driver version 2.40 provides access to the receiver without needing to open a COM port. This is used by app store and web apps such as Microsoft Bing Maps and Google Maps. A Virtual COM Port (VCP) driver version 3.10 provides a COM port for access to the receiver, though this version may not be compatible with some apps (that technically use the .NET Serial API).
• Previous u-Blox drivers (recommended) - See older article section below. A GNSS Location Sensor driver version 2.30 provides access to the receiver without needing to open a COM port. This is used by web apps such as Microsoft Bing Maps and Google Maps. A Virtual COM Port (VCP) driver version 2.30 provides a COM port for access to the receiver, even by apps that do not work with the latest drivers. Though each major Windows Update may require RollBack or re-installation of this previous driver.
• Alternative Microsoft VCP driver - If you Uninstall and fully delete the u-Blox drivers then Restart, a generic Virtual COM Port (VCP) driver will load instead. This provides a COM port for access to the receiver, and does not change after any Windows Update. Though this does not provide a GNSS Location Sensor driver for web and store apps.

8 Nov 2019

The GNSS Driver Options utility for the Mesa 3 and Mesa 2 with Windows can help with making the integrating u-Blox NEO M8 series GNSS receiver work with specific software applications, or resolve other potential issues.

Drivers for the internal GNSS (GPS) receiver in the Mesa 3 and Mesa 2 install automatically through Windows Update. Though not all apps are compatible with the latest drivers for the u-Blox NEO M8 series GNSS receiver. Some previous Mesa 2 units may even encounter an issue where drivers may disappear and be prevented from installing after a major Windows Update. If needing assistance with getting these drivers to work properly with your apps, download and extract the following file, then review the extracted 'GNSS Drivers Readme.pdf' document.

Separate links to the previously recommended drivers are as follows.

Jan 2018

With our Mesa 2 OS Build Version 17178 and 17255 pre-installed on new units in production between August 2017 and January 2018, we also pre-installed the previous version 2.30 drivers and set a group policy to prevent them from updating. If needed, instructions for removing this group policy are provided in the release notes documents for those OS Builds or in the following article.

If the 'Mesa 2 GNSS Driver Options' utility above does not work for you, installing the version 2.30 drivers may require performing a Roll Back from a later version more than once to be more permanent. This is done as follows.

1. Tap and hold on the bottom-left Start (Windows logo) button then select Device Manager.
2. In Device Manager under Sensors, tap and hold on 'u-blox GNSS Location Sensor' then select Properties.
3. Under the Driver tab, view the Driver Version to be 2.30 and if not then Roll Back or Uninstall (with 'Delete the driver software for this device' if necessary).
4. If needed, use the installer above to restore the version 2.30 driver.
5. In Device Manager you may need to tap on the Action menu > 'Scan for hardware changes' to recover the device.
6. If the Driver Version is again not 2.30, perform a Roll Back as explained in step 3.
7. Repeat as needed.
8. Follow the same steps for the 'u-blox Virtual COM Port' in Device Manager under Ports (COM & LPT).

Or you can manually setup a group policy to prevent these drivers from updating. This is done as follows.

WARNING: Setting a group policy to prevent driver updates may stop drivers from working after Windows Update.

Add group policy for u-blox drivers

1. Win+R, gpedit.msc
2. Computer Configuration > Administrative Templates > System > Device Installation > Device Installation Restrictions
3. Double click 'Prevent installation of devices that match any of these Device IDs'.
4. Click the 'Enabled' radio button
5. Click the 'Show' Button
6. Enter two items (copy and paste from Device Manager): UBLOXVCPPNP0501 USBVID_1546&PID_01A8

After getting the drivers to work as needed, we also recommend performing a 'Reset Receiver' using Geode Connect'.

Version 2.32 and higher of the u-Blox Location Sensor driver enables binary UBX strings which, even if disabled, will automatic re-enable after disconnecting and re-connecting receiver. These UBX strings may cause issues with apps such as Geode Connect 1.2.0 or older and Farmworks Mobile (formerly SiteMate). An alternative technical method to disable these in the later drivers is available in u-Center, but it is recommended to instead update apps to use the newer Location Sensor programming functions.

Version 3.x of the u-Blox VCP driver may not be compatible with apps which were written using a .NET programming language and which call the standard .NET Framework serial communication programming functions, such as Geode Connect 1.2.0 or older. Other previous apps which use the virtual COM port number to access the receiver may also encounter issues. Again it is recommended to update apps to use the newer Location Sensor programming functions instead of legacy serial communications.

U-blox 7 Gps Driver

Some related articles are as follows.

U-blox U Center Download

• GPS does not immediately track current position

One of my never-ending projects is building a packet radio “Go Kit”, largely based around Ed, W6ELA’s “APRS Box” concept. After some extensions to add Packet BBS, Winlink, and AREDN support, I’ve started calling the thing a “PiComm” unit. One day I’ll write up more on it.

One of the more critical components of the setup is a GPS receiver: this provides location info for APRS, and allows the Raspberry Pi (which has no Real-Time Clock) to know what time it is without accessing the internet. I grabbed this unit, which had great reviews and 1-day shipping.

I am an impatient ham, after all.

Once it arrived, I installed GPSD on Raspbian Jesse and plugged it in. In theory, the system should have seen the GPS device appear on USB and automatically started GPSd. Except…it didn’t. Worried I got a dead unit, I did some digging and found the device was present by running lsusb -v and dmesg | grep -i usb, and which showed the device mounting at /dev/ttyACM0. Running cat /dev/ttyACM0 got me lots of raw GPS data, too - the receiver was fine. So why wasn’t GPSd starting automatically?

On Linux the job of starting services or auto-running commands when devices are plugged in are handled by a service called uDev, which uses a somewhat cryptic language to define rules that trigger actions - like auto-mounting a USB hard drive when it’s plugged in. When installed on Raspbian, GPSd automatically defines rules for many receivers in /lib/udev/rules.d/60-gpsd.rules - but doesn’t include rules for u-Blox 7 receivers:

Admittedly, that looks pretty close to what I saw earlier from running lsusb -v - but not close enough:

Everything is the same with the uBlox 7 chipset, except the idProduct is different: 01a7, vs. 01a6 or 01a5. So, to get uDev to launch GPSd automatically when I plug it in (or when the system boots), I just copy one of the existing lines and edit the idProduct to match mine:

U-blox Gps Software

Reload the uDev rules and et voilà! Even better, GPSd re-maps the devices entry in /dev to /dev/gps0, which makes it easy to configure other apps like Polaric to grab position data - regardless of what receiver you use.