I know how that goes…I think the neighbors truly think I’m a madman…my lawn mowing itself with a flashing warning light and relay controlled headlights at hours that most people wouldn’t attempt yardwork…
I use a 35" lane width with a 48" deck. I bet once you get tuned up, you’ll be able to increase the width to 40" to 50" without issue.
A decreased NAVL1_PERIOD (at least lower than about 15) is probably the last thing to pursue - it will exacerbate all of your other tuning issues otherwise.
AP_GPS_UBLOX.cpp, lines 132 and 185 
After all that code research yesterday, that was an easy one.
so ap_gps_ublox.cpp is the file with the auto configuration Mission Planner uploads to the receivers when gps_auto_config is 1?
if you guys don’t mind me asking, what are the messages you have enabled on uart1/2 of moving base and moving rover?
I know on moving base you should send rtcm3 to rover and relposned, and nav-pvt to flight controller so you can see the fix type on mission planner, and on rover you enable relponed and nav-pvt, but are other messages also necessary?
I will be glad to look up those messages for you, but with beta3, if you simply enable GPS_AUTO_CONFIG for a few seconds, it will configure everything correctly. In fact, if you are using MAVlink injection for your RTCM3 from the fixed base, you should be able to leave it enabled. (That is the way Yuri is operating).
In my case, after a few seconds, I turn off GPS_AUTO_CONFIG and go into Ucenter and change the baud rate on UART2 for both GPSes to 115200 (and commit to RAM and FLASH) so that my uplink of RTCM3 from the fixed base can get into GPS1 (moving base).
You, then leave the GPS_AUTO_CONFIG off. The GPSes have committed the settings to flash, so it comes back up perfectly from then on.
Hope that helps, but here are the messages set up by Ardurover in my configuration.
From Moving Base to Rover (on UART2):
RTCM3_3X_TYPE4072_0
RTCM3_3X_TYPE4072_1 1
RTCM3_3X_TYPE1077 1
RTCM3_3X_TYPE1087 1
RTCM3_3X_TYPE1097 1
RTCM3_3X_TYPE1127 1
RTCM3_3X_TYPE1230 1
From Moving Base to Flight Controller (on UART 1):
UBX_MON_HW2 5
UBX_MON_HW 5
UBX_NAV_DOP 1
UBX_NAV_PVT 1
UBX_NAV_TIMEGPS 5
From Rover to Flight Controller (on UART1):
UBX_MON_HW2 5
UBX_MON_HW 5
UBX_NAV_DOP 1
UBX_NAV_PVT 1
UBX_NAV_RELPOSNED 1
UBX_NAV_TIMEGPS 5
@rmackay9 Happy Camper Here! I changed the UART2 baud rate to 115200 in AP_GPS_UBLOX.cpp, lines 132 and 185, and am happy to report that ArduRover configures my GPSes perfectly now for my configuration. I think if that baud rate was configurable via a parameter, we would be golden.
This is my exact configuration using Ublox C099-F9P evaluation boards:
It is also equivalent to this configuration with Ardusimple SimpleRTK2B boards:
I wanted to use the beta version, but when I connect both of the gps to my cube, the mission planner crashes, also with the dev version, only the stable one this does not happen.
Also I using the piggyback connection with the smaller board, so it wouldnt work the auto config because the it has to be the uart 1 from the small one connected to the big one, and the autoconfig uses the uart2 from both of them
If you update to the latest beta of mission planner (on the help screen), the crashing should stop. I had the same trouble you are having until I did that.
If you have room on your rover to mount the piggyback board beside the other gps board, you can probably wire them the way you want. The piggyback feature is nice, though.
@jolivart from ArduSimple posted a good tutorial on using the piggyback boards. I think he reverses the moving base and rover as GPS2 and GPS1, respectively. I’ll try and find the link later when I’m not tied to my phone.
I think this is the link you are talking about: Rover 4.0 + Ardusimple = GPS Yaw debugging
But I believe there may have been another thread about it as well.
That’s the one! He also mentioned this link. However, you’ll need to use EK3_SRC1_YAW= 2 instead of EK3_MAG_CAL=5 with the newer 4.1-series firmware updates.
Hi @GRS26,
There are some mixed reports about whether the latest MP resolves the “evaporation” problem or not. For me (using the version printed below) it seems fine but there is at least one user who says that it is still happening.
Great that it’s working! It’s taking time but I hope we will add to the GPS_OPTION a bit that allows using the SERIALx_BAUD to achieve what you’ve done with a code change.
@rmackay9 That would be awesome. The name will need to be something different from SERIALx_BAUD since that currently refers to a serial port ON the flight controller. The new parameter will be for setting baud for the port ON the GPS end, but I know you know that! 
I am very pleased with the GPS Yaw, so far. I have run my mower most of the day, some mowing, but mostly just tuning. The docs like Tuning Speed and Throttle — Rover documentation (ardupilot.org) and those following it are really excellent now. I may just not be remembering, but I don’t think the parameters were explained so clearly a year or two ago when I was just starting. It was very useful to go back through these. Thanks to all who have contributed to them. I know you have been key in that.
by evaporation , you mean the mp crashing it?
I want to highlight it only crashes when both receivers are connected, like I can connect the telemetry, but when both receivers are on, MP crashes
But I didn’t try this beta version of mp yet, monday I will try and report if still has errors
Yeah, I tried, but didn’t work.
I read the pdfs’ from ublox, I configured both my rover(standard board) and moving base( lite board) to send the right messages. When I set gps_type 1 and 2 to AUTO, the cube recognizes both board, and I get rtk fixed from both,but as soon as I set the gps type to 17 and 18 and reboot the cube, I get no GPS.
I don’t use auto config because it assumes the connection between boards is through the uart 2, but in my case that I am using a lite and a standard board, its between uart1 from lite and uart2 from standard.
Hello,
I managed to get heading using fixed base, moving base and moving rover in piggy back configuration. The only problem I am having now is that the rover is sending me back the position of my fixed base, like if I move the rover, it’s position on mission planner stays still on the fixed base coordinates.
If I disable either message 1005 coming from fixed base, or message 4072.0 coming from moving base, it’s stops, but I lose fixed rtk status in moving base or moving rover respectively.
It seems like the fixed base’s coordinates are being carried over all the way back to mission planner. Does somebody has any experience with this?
Why did you delete all your previous posts? It was an excellent discussion and helps put your current struggle into context.
I’ve not seen that problem at all. You still have something significantly misconfigured. Suggest you revert the F9Ps to default and follow @jolivart’s instructions to a tee.
the expiration problem was solved when used the beta version of mission planner.
@Yuri_Rage you are also using a fixed base right? if possible, could you tell what are the messages in your setup, maybe that gives a light to what I misconfigured
