Add Option to Configure used GNSS Systems

[jbeyerstedt]

Describe problem solved by the proposed feature
Now, that the Galileo GNSS system is is a working condition, it would be nice to be able to select, which GNSS systems are used by the connected GNSS receiver. For example the pixhawk 4 GPS is using the uBlox NEO-M8N chipset, which is capable of receiving three of the four (GPS, Galileo, Beidou, GLONASS) available GNSS systems at once. But by default only GPS and GLONASS are enabled.

Describe your preferred solution
I think, that a configuration parameter is the most user-friendly solution for this configuration option. It should be a separate setting for each connected GPS receiver (like port and baud rate settings for GPS_1 and GPS_2). The capability to use two or three systems at once would lead to these options:

• GPS + GLONASS
• GPS + Galileo
• GPS + BeiDou
• Galileo + GLONASS
• Galileo + BeiDou
• BeiDou + GLONASS
• GPS + GLONASS + Galileo
• GPS + GLONASS + BeiDou
• Galileo + GLONASS + BeiDou
• All
• leave default settings

The supplementary services (SBAS and QZSS) would be enabled according to the receivers recommendations for the selected configuration.
And I think, that just using one system might not have an advantage. But it can also be added, when it's needed for some GNSS receivers.

These are a lot of options, so a bit field would also be possible, where each of the systems can be enabled individually. Then SBAS, QZSS (and IMES) might also be added to the options. But at least the ublox receivers recommend some restrictions, in which configurations to enable these.

Please comment, when I have left out a system. These are just the options my uBlox receiver for now.

Currently our plan is to provide a pull request in early January of next year.

[ryanjAA]

This would be good depending on the level of work to implement but the M9N which is the same cost and starting to be more readily available can do 4 concurrent GNSS systems and in the not too distant future we'll see start to see more people and systems utilize those. If you happen to have already done it though then that would be a great addition!

On the performance side of things there really isn't much of a comparison since the M9 is vastly superior so the ability would be great as long as it's not too burdensome to do and doesn't take up too much flash, etc. Just my 2¢.

[dk7xe]

Indeed other receivers would need different options.
I'm in favor of having a bit per satelite System.
At the moment 8bit would be more than enough.
The complementary services should be set based on region since this is how they are currently organized if i'm not mistaken.
EGNOS for Europe.
WAAS for NorthAmerica
QZSS for Asia-Pacific
This could be done automatically by checking if current setting is valid for current position.

[dk7xe]

BTW we would not have an issue if all GPS receivers available would have an USB port for programming the internal flash memory. In such a case there would not be any need for the PX4 driver to change any settings. Settings could be done via the manufacturers tools.
But thats not the case on a wide varity of GPS receivers as well are this tools not very user friendly.

Several options for configuration coming to my mind

1. do parameter settings in QGC and GPS driver acts accordingly at boot up.
2. have a pass through functionality for configuration to GPS port with setting done from QGC. GPS driver does no config at Boot up.
3. having a config file on SD card with config commands that are sent at boot to GPS port (experience needed).
4. other
   Independent from solution it must be incorporated that different GNSS receivers (version/manufacturer) might be connected simultanuosly.

[jbeyerstedt]

I don't think, that it's a good idea to auto-configure depending on the current position. Currently the configuration is done once at the driver's startup and the position is not known at that time. And I don't know how well the receivers behave when being re-configured during operation. Not mentioning, how the thresholds for the geographic regions would be defined in the first place.

The ublox receivers will bundle all GPS augmentation systems (WAAS, MSAS, EGNOS, GAGAN, SDCM) into one option (SBAS) anyways. Also GPS and QZSS should always be enabled and disabled together. So for ublox, the effective settings are limited to a combination of 2/3/4 GNSS variants + SBAS enabled or disabled.

And yes, doing such advanced settings on the receiver with the manufacturer's tools is a valid option, but somehow it doesn't always work. A config parameter will be the most user-friendly option. With a dropdown, I can add a "leave default" as well.

[dk7xe]

Ok, thanx for clarification. After config change a warm start of the GNNS receiver should be performed i think.

[bkueng]

I'd also go for a bitfield. Just be aware that Gen 9 in rolling out, and as it is quite a step up I think it will replace existing devices soonish.

[jbeyerstedt]

A bitfield is also fine, but then I'll need more information, which fields are needed. For uBlox it would need 6-7 enable bits:

• GPS
• SBAS
• Galileo
• BeiDou
• IMES
• QZSS
• GLONASS

What else is needed for other receivers? The uBlox Gen9 has not added any more GNSS compared to the M8N.

And should QZSS always be enabled/ disabled together with GPS, as uBlox recommends?

[bkueng]

I'd keep IMES and QZSS out for now and follow the u-blox recommendations.

[jbeyerstedt]

I started implementing this and hope, that I can provide a PR draft until the end of the week.
See PX4/PX4-GPSDrivers#68 for the implementation status in the driver. We're planning to provide an implementation for uBlox, but the architecture will be generic.

[jbeyerstedt]

According to GPS_STATUS, I just received Galileo satellites with our outstanding pull requests and the Pixhawk 4 GPS when setting the new GPS_1_GNSS parameter to GPS+SBAS+Galileo.

[jbeyerstedt]

Thanks @bkueng for the discussion and review. I'm closing this, because the PR got merged.

[lukegluke]

Hi all,

Not quite relating to the issue's subject, but a thought about gps drivers architecture.
For now in gps drivers there are two output modes - GPS and RTCM - px4 uses only the first one mode and QGC the second one to support base stations. But in fact it seems useful especially in aerial photography to log RTCM raw GNSS data during flight for further post processing (PPK). So this feature will need GPS+RTCM mode and posting to uorb something like gps_rtcm_data (= the current gps_inject_data with additional flag to/from device) in gotRTCMMessage callback.