Modify ublox gps driver for auto config

ArduCopter Copter 4.4
1

I am using RTK Moving Baseline configuration but I want to enable two gps modules to pass RTCM data internally rather then going through the FCU to increase relaibility. I also want to keep the GPS Auto-config. Both GPS’s are connected to FCU via UART1 on F9 Module.

I have modified AP_GPS_UBLOX.cpp to enable Rover UART2 to accept RTCM from Base UART1 (whic is also connected to FCU). Also disabled Rover UART1 to accept RTCM.

These are the only config keys I have updated:

const AP_GPS_UBLOX::config_list AP_GPS_UBLOX::config_MB_Rover_uart1 {
{ ConfigKey::CFG_UART2_ENABLED, 1},

{ ConfigKey::CFG_UART1INPROT_RTCM3X, 0},
{ ConfigKey::CFG_UART2INPROT_RTCM3X, 1},

When I tested on the aircraft the GPS modules pass the RTCM internally and can get RTK fixed. The problem is the critical prearm message GPS 1 failing configuration checks. Following an Info message GPS1: u-blox RTK MB configuration 0x2000.

I am trying to understand what else I should modify on the ublox GPS driver to do the checks with accepting the modifications.

2

Pretty sure what you’re attempting is already covered by simply setting GPS_DRV_OPTIONS=1. No custom firmware build required.

3

Thanks for quick reply Yuri.

I have to keep using UART1 out RTCM on the base module.
I assume this parameter will put RTCM on UART 2 on base.

Base Uart1 is connected both Rover UART2 and FCU.

4

Seems it’d be extremely easy to just connect UART2 instead and avoid all this madness. If that’s impossible for reasons I don’t understand, you should look at the source for the option I mentioned to see how it’s implemented.

5

They are embedded on a motherboard, I need to design new PCB to expose the uart 2 pins on base.

I am only changing three lines of code to reconfigure rover module and trying to understand how the configuration check logic in prearm.

6

Pretty sure you’ll need both RTCM3 and UBX enabled on UART1 out, but I’m not sure the bandwidth is available to do that successfully. Using UART2 to communicate with a second device is the right answer, though I understand your board architecture is not set up for that.