M8n config file in wiki corrupt

TheMarco M8N config file linked on this wiki page (http://ardupilot.org/copter/docs/common-ublox-gps.html) causes u-center to crash right at the end of applying the config. I wrote the raw text to a fresh txt file and saved as UTF-8 in notepad++. U-Center reads the file just fine, then towards the end it struggles with a few commands (timeouts etc), then right at the end u-center crashes. I am using the latest U-center as of today v8.23 - and connecting to the ublox-m8n using an official FTDI cable.

Can oine of the devs please update github with a working replacement for this file?

Thanks, Paul

Better connect the GPS to a PixHawk and let Ardupilot write a correct config


Found the solution - thought I’d post here to hopefully help others in the future. When the ublox GNSS configuration file is applied, it changes the baud rate to 38400 - now if like me you were connected to the GPS at a different baud rate, when the config changes the baud rate the connection is broken - hence the timeouts I was seeing. So the solution:

  1. download the contents of the file https://github.com/ArduPilot/ardupilot/blob/master/libraries/AP_GPS/config/Marco-Ublox_M8N.txt - click the RAW button and copy/paste this into a new text file and make sure it is saved with UTF-8 encoding (not UTF-8-BOM as is the case when youbseklect UTF-98 in windows notepad). I used Notepad++ to do this.
  2. connect to the GPS from within U-Center (using the correct port and baud rate).
    If your baud rate is not 38400, then you need to change it. To do this Select View, Configuration View (Ctrl-F9). scroll down to the PRT item, and select this. Then with UART1 selected change baud rate to 38400. Click ‘Send’ at the bottom. At this point the baud rate is changed and your comms will be lost, so on the toolbar, change the connection baud rate to 38400 - the connection should be regained. Next we need to save the configuration, so on the left of the configuration view choose the CFG iten, click on the Save configuration item and click send at the bottom. The baud rate changes are now saved.
  3. Finally apply the config file by selecting Tools, GNSS Configuration, select the config file and click File -> GNSS. It should now apply without a hitch.

Hi Luis, Thanks for the info - I did realise that Pixhawk sends the settings - as long as you have these parameters configured (mine were not by default). It would be great if there were a lookup table somewhere suggesting the best settings for different combinations of world location vs GPS model, so that we can configure the parameters to get the most out of the GPS. As I am in the UK, should I set these like this:

GPS_NAVFILTER: 8 (Airbourne 4G)
GPS_SBAS_MODE: 1 (Enabled)
GPS_GNSS_MODE: No idea what to set to be best for UK locatoion

Cheers, Paul

Hi Paul,

I’m nearby in Portugal. My usual config is very similar to yours and I set


the rest is the same as you’ve posted.

I’ve used this on several units, from 3DR units to chinese BN880 and Drotek’s sucessfully

That’s awesome info. Thanks Luis. It appears that not al BN-880 GPS units are made equal!! I tried to upgrade one of mine today and it reported that its actually got a NEO-7N GPS processor in it, whilst the other 3 I have are all M8n. I think sometimes these Chinese factories just throw in what comes to hand :slight_smile:

If you connect early enough in the boot process (or connect the GPS after the GCS is connected) the u-blox HW/FW versions will be sent to the GCS as a statustext which will allow you to see what ublox chipset is in there.

GPS_SAVE_CFG 2 is a better option then SAVE_CFG 1. It will only tell the GPS to save the settings to flash if the driver had to make any changes. Otherwise it won’t write to the flash. This has the advantage of not pointlessly writing to the same flash memory repeatedly, which only has a finite wear cycle.

GPS_GNSS_MODE on a ublox 7 I’d only set this to 3 (GPS + SBAS only). Setting it to 67 means to enable GPS, GLONASS and SBAS.

It’s also worth noting that the target baudrate for a u-blox GPS has been raised across the board from 38400 to 115200 (we used to only raise it if you wanted to log raw data).

@WickedShell Should we just remove the config files from the Wiki and GitHub? We now configure the GPS and also have pre-arm checks if the configuration is incorrect, I see no need to have those configuration files available.

@OXINARF I’m in favor of it. I know that the wiki files (which I think just link into the repo) aren’t maintained, and that they are targeting the wrong baud rate now, and at least one of them is targeting a different time source, causing the timestamps between GPS unit’s to be different. Since we now audit the settings that are set in that file I think its time to just remove them.

1 Like

What is the best baud rate to set the GPS to as default (through u-center)? I realize that AP configures this but does it have to try lots of baud rates initially in order to get the right rate? If so, does it help the initialization process if we set the default baud rate manually to something specific? I know the config file for the m8n sets it to 38400.

@pauljatherton 115200. We are looking for that baud rate in the driver, when we raised the baud rate its possible to detect the GPS at 38400 before the baud rate has been changed to 115200. If you set and save it to 115200 this can’t happen. Its a small patch I realized last night hadn’t been pushed yet, I thought I had already but I apparently missed it It’s not a risk to flight at all, but will make it more consistent to just set it, as well as address any problems that might arise if you play with the EKF GPS delay tuning.

There was another report in this AC3.4 testing category in which someone resolved their position hold issues by applying Marco’s M8 Ublox config. I’d prefer if we didn’t remove this config file from the wiki and github until we’ve confirmed that ardupilot is writing all the config that these config files write.

@rmackay9 I would say the issue is that these people have disabled auto configuration, otherwise their Marco’s configuration would be overwritten by our auto configuration if I’m not mistaken.

It should be better to compare the differences between the config set by that file and what we do automagically before we “retire” the config file, if that is deemed necessary

@rmackay9 Marco’s config file isn’t considered valid. Doesn’t turn on NAV-VELNED, turns off NAV-DOP, doesn’t turn MON-HW2. It doesn’t provide what we are looking for at all. The biggest reason why this might help is if they had a wiring problem (or possibly if the baud rate thing hit them, that one is fairly unlikely).

It also turns on all the NMEA outputs, which we don’t want…

Overall it needs to be noted that these config files are very stale and don’t provide the full configuration we are looking for, and if you only applied them and don’t connect the Tx pin to APM, and didn’t get lucky with what VELNED was for example, or allow ardupilot to reconfigure it you were never going to get a 3D velocity out of the GPS. I have not once gotten into a situation where APM can’t recover a wildly misprogramed u-blox safely with the arming checks. The most probable reason for this to have “fixed” their problem is they simply had a wiring problem, or took off without providing the EKF with data it was looking for.

@OXINARF yeah, people who don’t connect the Tx wire have problems or turn off GPS_AUTO_CONFIG, however the configurations provided for these are stale, and it isn’t emphasized to users when we want an extra/different message as that is expected to be automatically handled.

@WickedShell If someone has the Tx wire disconnected and GPS_AUTO_CONFIG turned on it should still give a GPS config error if the GPS doesn’t have the configuration we are looking for right?

I expect anyone that disables auto-configuration to know what they are doing, so I see no need to provide (bad) config files.


Ok, you sound like you know what you’re talking about here so I bow to your better judgement. If we remove the file, let’s remember to update the wiki as well and heck, someone should even reach out to Marco to explain this. I’m pretty sure you were going to do that but I’ll mention it just in case.

@OXINARF Yeah, as long as GPS_AUTO_CONFIG is turned on, until we get a positive read back of a setting we are failing the configuration arming checks. With a disconnected Tx wire we won’t ever get the GPS sending us configurations.

Marco’s file definitely provided a good starting point back before we validated all the settings, it was a good way to ensure that you always had some of the minimum requirements turned on, and there wasn’t saving config support in when it first showed up. However we’ve advanced the driver since then to deprecate the need for that.

@WickedShell How about gps_sbas_mode and gps_gnss_mode? It seems that they overlap each other reg. SBAS usage. Which one has preference ? thanks

@tabascoz Once you get to the 7th and 8th gen u-blox controlling how many channels search for SBAS is managed via the GPS_GNSS_MASK. So they need to be set in coordination with each other. There has been some discussion that GPS_SBAS should imply the config for the GNSS_MASK, but that hasn’t been done yet. (It is on the to do list). For now simple set them to agree with each other if you are looking for SBAS.