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?
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:
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.
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_TYPE: 2 (UBLOX)
GPS_NAVFILTER: 8 (Airbourne 4G)
GPS_MIN_DGPS: 0 (Any)
GPS_SBAS_MODE: 1 (Enabled)
GPS_GNSS_MODE: No idea what to set to be best for UK locatoion
GPS_SAVE_CFG:1 (Save)
GPS_AUTO_CONFIG: 1 (Enable)
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
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.
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.
@WickedShell,
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.
@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.
