Pr base station menu

[Louis-max-H]

This PR aim to develop base station menu and depend on this PR for GPS Driver

Description

UBlox menu	Septentrio menu	Manufacturer list
Ps: Protocols displayed in Septentrio menu will be part of another PR

1. Proposing different settings according to receiver manufacturer
2. Base Station mode change from bool to int. That will allow a future PR that have base station (for example, moving base station on boat)
3. Implement base station menu for Septentrio (base infos, base config)

### Explanation.

1. Manufacturer allow the hide and show of some settings to keep only theses that are implemented.
   We use bit mask defined like this :

    readonly property var    _standard:           0b00001
    readonly property var    _trimble:            0b00010
    readonly property var    _septentrio:         0b00100
    readonly property var    _femtomes:           0b01000
    readonly property var    _ublox:              0b10000

To restrict a parameters' visibility to U-Blox + Septentrio : (You can use either | or +)

visible:    manufacturer & (_ublox | _septentrio)

If implemented by all manufacturer :

visible:    manufacturer & _standard

This parameter is always visible because it is implemented by everyone, but I think that specifying it each time avoids uncertainties such as, how compatible is this parameter with the receiver? Has the developer thought this through?
Don't hesitate to tell me what you think :)

To show parameters available for U-blox, set manufacturer to _standard + _ublox
Manufacturer is set automatically when plugin a receiver.

2. Base station mode is now :
   0 : Survey-in
   1 : Fixed
   This change is compatible with the 4 different drivers that use BaseSettingsType (base_station.h).

a) Base stations info is display by using PosGeodetic information.
b) Some parameters like Ublox min precision don't have an equivalent in Septentrio, here is a quick recap of with parameters is available or not :

Parameters​		Ublox​	Septentrio​	Femtomes​	Trimble​
Survey-in (auto)​	Min duration​	✅	​	✅​	✅​
​	Min precision​	✅​		​	​
Specify location​	Long, Lat, Alt​	✅​	✅​	✅​	✅​
​	Base precision​	✅​	​	​	​
​	Set from position​	✅​	✅​	✅​	✅​

Survey-in options don't have equivalents for Septentrio receivers.

Test Steps

I have followed this procedure and another intern (@duck) have done the same on another computer.

git clone https://github.com/Louis-max-H/qgroundcontrol
cd qgroundcontrol
git checkout pr-base-qgc
git submodule update --init --force --recursive
chmod +x tools/setup/*.sh
docker build --file ./deploy/docker/Dockerfile-build-ubuntu -t qgc-linux-docker .

Edit the file src/GPS/CMakeLists.txt
To have

CPMAddPackage(
    NAME px4-gpsdrivers
    GITHUB_REPOSITORY Louis-max-H/PX4-GPSDrivers
    GIT_TAG pr-base-station-px4
    SOURCE_SUBDIR src
)

Instead of :

CPMAddPackage(
    NAME px4-gpsdrivers
    GITHUB_REPOSITORY PX4/PX4-GPSDrivers
    GIT_TAG main
    SOURCE_SUBDIR src
)

You can now build QGC using :

docker run --privileged --rm -v ${PWD}:/project/source -v ${PWD}/build:/project/build qgc-linux-docker
./build/AppDir/AppRun

• Unplug all
• Plug CubeOrangePlus
• Select a different manufacturer than the board tested
• Select the config you want to test
• Plug base station
• See if :
  • Precision is improved, position is RTK
  • Information are displayed
  • Manufacturer is autautomaticallyt

Do these steps for Survey-In, Set location
Test have been made on Ublox and Septentrio, I don't have the equipment to test other GPS systems but they should work has Ublox does.

Checklist:

• [x ] Review Contribution Guidelines.
• [ x] Review Code of Conduct.
• [ x] I have tested my changes.

Please let me know if I need to make any changes to this RP so that it can be accepted by the community, this would be my first PR 🥳

Ps: The automatic tests could fail because of the need to modify the Makefile, so I'm putting the PR in draft form and I'll come back to you once the PR for the GPS driver has been accepted.

[DonLakeFlyer]

@bkueng Beat can you look through this. I'm not super familiar with RTK,

[bkueng]

Nice, having type-dependent options makes sense.
But ideally the manufacturer is determined automatically, as we already know it when connecting the device.

[Louis-max-H]

I've updated the PR with a rebase including the latest QGC changes.

[DronecodeBot]

This pull request has been mentioned on Discussion Forum for PX4, Pixhawk, QGroundControl, MAVSDK, MAVLink. There might be relevant details there:

https://discuss.px4.io/t/px4-sync-q-a-april-30-2025/45350/2

[DronecodeBot]

This pull request has been mentioned on Discussion Forum for PX4, Pixhawk, QGroundControl, MAVSDK, MAVLink. There might be relevant details there:

https://discuss.px4.io/t/px4-sync-q-a-april-30-2025/45350/1

[DonLakeFlyer]

FYI: I'm going to branch for QGC 5.0 RC next week. So if this wants to go into 5.0 it needs to hurry.

[Louis-max-H]

Thanks for the info!
I think everything's already good, I've added a version with enumeration for the baseMode and I tested this morning that the menu works well.

Here's a quick recap of the latest changes:

• baseMode use enum as suggested by bkueng
• Bitmask calculation moved in c++ file to avoid magic constant

[DonLakeFlyer]

But ideally the manufacturer is determined automatically, as we already know it when connecting the device.

Is this supposed to be working? I have a Ublox RTK which I plugged in. When I went to the page the manufacturer was set to all.

[Louis-max-H]

That's very strange ...

I have test again with an Ublox ZED F9P an the menu was detected.
Detection is made in src/GPS/GPSRtk.cc, but the if/else tests should only set manufacturer to Ublox/Septentrio/Fentom/Trimble or Standard, but not All.

I've also checked that there's no inconsistency with regard to enumerations (0 = Standart, 1 = All).

I have made a little improvement to the print pattern, with the latest changes can you :

• Check the message send by qCDebug(GPSRtkLog)

  1. Connecting U-blox device -> Manufacturer to Ublox
  2. Connecting device has U-blox by default" -> Manufacturer to default

• Close menu and open again

  1. Settings are correctly updated even with the menu open, only the manufacturer is not changed when menu open. Cf gif.
     

• We are actully checking for "blox" in the name of the receiver, maybe we can change it to something else ?

  1. Can you check for the name of your receiver has detected by QGC ?
  2. qCDebug(GPSRtkLog) << gps_type; to add in GPSrtk.cc

I hope it will help to understand what is happening !

[Louis-max-H]

After discussion with another QGC user, the "manufacturer" reference may be misleading.

He thought that this choice had an impact on the protocol used, whereas it's just a graphics option to hide some settings, so I changed it to "Settings displayed".

I have tested this change.

[Louis-max-H]

Do you have any news @DonLakeFlyer ?
Feel free to tel me if I can help you somehow !

[DonLakeFlyer]

I'll get back to this once we get 5.0 out the door

[Louis-max-H]

FYI, the pull request on PX4 have been merged 😃

My internship will end in 3 weeks, feel free to ask me questions, I could respond even after, but I will be easier for me to finish it before,

[DonLakeFlyer]

What is the "Standard" selection?

[Louis-max-H]

Standard is for settings implemented by all receivers.

[DonLakeFlyer]

Ok, so what is the difference between Standard and All then? Why are both needed?

[Louis-max-H]

If this seems to create confusion, I have removed "standard" manufacturer.

"All" was to display all parameters (implemented or not for the current receiver), whereas "Standard" was used to display parameters that are implemented for all receivers.

This will guarantee the user that his settings will be taking into account whatever the receiver, for example, when the receiver manufacturer is not detected (but by default, it will use UBlox driver, so let's directly remove standard and use Ublox for this case)

[DonLakeFlyer]

Yeah, I think that makes more sense.

[Louis-max-H]

@DonLakeFlyer Do you know if you can merge this PR ?

Tory9 will be taking over these changes since it will be the end of my internship !
I'll continue to follow progress, but I'll have limited access to the hardware,

[Tory9]

@DonLakeFlyer hi, can you pls let me know if we can merge this request

[DonLakeFlyer]

I don't get why this changed? It's still basically a boolean value with only 0 or 1 as valid. What was wrong with the way it was before. The problem with changing settings like this is that all user who have set this value will lose their specific setting when they upgrade without really knowing it.

[Tory9]

The idea was to change from book to enum to update in future code to add moving base

[DonLakeFlyer]

OK, that's fine. But it should be done in a way that doesn't affect existing settings which may have been saved:

• Leave the baseMode name the same so you don't trash peoples existing settings
• Change the baseMode json to use enumStrings/Values and encode the values such that 0 and 1 mean the same thing as they did when the setting was a bool.

This way for existing users they are not affected.

[Tory9]

okay, thank you. i will implement the changes and tag you when its done (next week most probably)