What autopilot are you using? And which serial ports are you using? Perhaps it’s a DMA issue.
Hi Mihai,
First, check the SERIALx_PROTOCOL¶ and find which serial is your GPS is connected. Then configure both rover and base GPS SRx_EXT_STAT to 50Hz.
Before changing serial data rates, let’s first narrow down some other things.
Thank you for the help guys. The serial ports are 3 and 4 (for base and rover respectively). As far as I can tell, the setup is identical to the one in the documentation. The only thing I’m I’m sure about is the baud rates on the serial links: they are setup at 38, which correspond to 38kbps. I’m not sure if that’s the problem though: last time I looked at RTCM updates they were around 1kbps (give or take), so 38kbps should be plenty.
I’m attaching a dataflash log file from last Friday. What we did was we kept the drone on the pad for quite a bit (maybe an hour or so), then flew it in manual mode (LOITER to be exact) for a couple of minutes (it felt good - no issues), we landed it, moved it manually for about 10-20cm and then it started to throw GPS2 health errors. Looking at the logs both GPS1 and GPS2 lost (and for GPS1 also recovered) the RTCM updates: for GPS1 we have a good explanation: our RTCM updates come through the cellular network, and when the drone is down, that link sucks. What messes us up is the RTCM connections for GPS2 (the rover). Something that may be telling is that the logs are missing in a couple of parts (I think that for a few minutes). I can confirm that throughout the period when the logs are missing the GPS2 health was reported bad on QGroundControl (we had a skydroid controller with QGC on it). This may be a “brain freeze” on the part of the autopilot, or possibly an overly busy autopilot (so busy that it doesn’t have time to log and/or forward RTCMs between the two GPSs).
Any ideas are welcome,
Thanks,
Mihai
You are confusing external corrections and onboard ones. GPS2 gets its corrections from GPS1 in a moving baseline config.
I agree. What I meant to say is that GPS1 is getting its status between 4 and 6 due to interruptions in the external RTCM corrections, while GPS2 is getting its status between 4 and 6 due to interruptions in the “internal” (via ArduCopter) RTCM connections. I can explain the former by a flaky cellular link, but I can’t easily explain the latter. Prime suspect is a busy autopilot, but I’m not sure of that either: CPU load seems steady at about 37%.
M.
I think the root cause is the fluctuation in fix type on the moving base GPS. Without a stable fix, its ability to provide corrections will be compromised.
A busy autopilot is almost certainly not causal or even contributing.
Don’t go messing with SR params to fix this. It probably won’t help.
Nah… we got the same error (and the corresponding missing chunks of logs) when we didn’t have the external RTCM stream at all (and then GPS1 was 100% of the time in status 3 or 4 - I don’t recall which). You may be right about the SR parameters though. What we’ll try first is to bypass the autopilot completely (connect the serials on the ublox chips).
Thanks,
Mihai
You have a high HDOP and extremely variable satellite count. This is most likely either a power supply issue to the GPS modules or poor antenna type/placement.
The parameters are fine. The autopilot CPU load is fine. You need to address the reception issue.
Maybe first try leaving things powered on for a good 15-20 minutes with a good, clear view of the sky. It’s possible that a full almanac download will help, but I’m skeptical that this will fix anything.
You might also try altering the GPS_GNSS_MODE and GPS_GNSS_MODE2 parameters to limit the satellite constellations to just GPS and one or two other selections (like Galileo or Beidou). I don’t think this is your root cause, but it can sometimes tighten an RTK solution to limit the constellations in use.
Have you updated the F9P firmware? Old firmware versions can be problematic, as well. I’m using 1.32 without issue.