Here is my GNSS configuration (this is with the antenna and GPS indoors, connected to my laptop). Firmware version is 1.13. Maybe someone can figure out if there’s any clues as to what’s going wrong here (I am no GNSS expert).
Both GPS modules updated to 1.32 firmware (from 1.13). Will go fly tomorrow and see if the problem has been resolved 
Since you’re already in uCenter, revert both F9Ps to default and save. I don’t think this will have much effect, but I do know that ArduPilot’s auto-configure routine works best when starting from a default config. It does not exhaustively set every possible parameter.
I have already Reset to defaults and flashed the 1.32 firmware!
1 Like
Would you prefer I stop trying to help?
Why would you say that?
You’re helping a lot 
Perhaps I misread the tone of your last comment. Easy to miscommunicate online. Onward!
That’s one of the biggest shortcomings of online / forum discussions haha. Hard to tell the tone / facial expressions of someone typing away on their laptop on the other side of the world 
. All good, and like you said, “Onward!” to resolving this issue
1 Like
I’ve downloaded all unique logs that I can find in the thread so far (filenames ending in 17, 19, and 48). It appears that some log files have been linked more than once.
I plotted satellite count against current, despite your assertion that they are not likely related, which does seem reasonable, but we shouldn’t rule anything out.
In the log where no reception issue occurred, current remains quite stable at ~80A.
In the two logs where the issue did occur, the reception loss appears quite correlated to spikes in current (choosing words carefully here - I did not say “caused by”).
This would also account for the perception that reception loss is correlated to maneuvering, since current should spike commensurate with changing attitude.
Additionally, while reception is affected similarly, the two modules are not affected equally. This plot of GPA[0].Delta and GPA[1].Delta shows that GPS2 is much worse off when the problem begins to occur:
I also did a brief review of the GPS library source(s), and the last substantive changes for uBlox GPS modules and moving baseline occurred a year or more ago, which should likely rule out recent firmware incompatibilities.
Thank you for this Yuri.
We did some tests on the ground just now (firmware is 1.32 already). We armed the drone and switched to AUTO, then moved the drone around by hand (pitch, roll, yaw and just walking around with it, even some jogging haha).
The problem did not occur again, but maybe the logs will give us some more information. Do you still think that your hypothesis of roll / pitch / yaw action triggering this GPS problem could be true @Yuri_Rage ?
@tridge also suggested taking a look at the GPS modules themselves to see if there was any visible damage or signs of smoke / soot. Both @tridge and myself are not able to notice anything out of the norm on the modules themselves, but maybe someone here will be able to spot something.
Images are attached here:
https://drive.google.com/drive/folders/19-Do6bX3YLL1sP7mWFAMlesa58Mkz_ip?usp=drive_link
Here’s the same graph with some scaling applied, along with GPA deltas. You can see a very large GPA2 delta at the end of the session.
I do still see a correlation in reception quality and attitude, though I think there may be a stronger correlation between current and reception quality.
My best hypothesis is that attitudes other than level contribute slightly to reception quality, which is actually somewhat expected behavior. Couple that with potential EM interference, and you experience significant degradations in GPS signal quality.
To rule out EM interference, you should try raising the antennas off the fuselage, even if it’s just some temporary wooden or 3D printed standoffs. Even 3-5 cm of standoff height could help narrow the root cause.
Another possible test for EM interference caused by current spikes might be to fly in QHOVER with no pitch/roll inputs and simply stab the throttle from a low/descending setting to a very high/climbing setting a few times.
I see no obvious damage in the pictures.
Did Tridge review the logs with you?
Thanks for the in depth analysis @Yuri_Rage . I will reply to that shortly. @tridge has looked at one of these logs.
For now, unfortunately the GPS problem is still here despite the firmware update. The problem even happened on the ground before we had the chance to fly (and while the drone was disarmed).
However we observed something highly intriguing. When the GPS problem started today (NSATS —> 0 and HDOP —-> 99.99 on both GPS) we left the drone for 5 minutes and the problem continued. Then I powered off the drone and left it for 15 min before powering on. Problem was still there (NSATS —> 0 and HDOP —-> 99.99 on both GPS).
But here’s what caused the GPS fix to come back: ~10 seconds of tapping the rear GPS antenna with my finger (?). Once I did this, both GPS started picking up satellites almost immediately and after 1-2 minutes they were back at 23 and 27 satellites. Notably, tapping the front GPS antenna did nothing.
This “tapping” thing seems to be quite significant. Any ideas what this could mean @Yuri_Rage or @tridge ?
That seems to indicate a loose antenna connection or faulty cable, which would certainly account for confusing problems!
If the “tapped” module was GPS2, it could also account for the worse performance and may simply be a contributor rather than root cause.
Of course, we may all be making the dreaded correlation/causation error(s), but it’s worth looking into!
Let me walk that last comment back just a little.
Because BOTH GPSs started picking up satellites at similar times, it’s very likely that they lost almanac data during the multiple configuration resets and/or disassembly.
Almanac data often takes several minutes to refresh on a cold start, so it’s more likely that your tapping simply coincided with completion of the almanac update.
Still, let’s not rule out a possible cabling/connection issue.
Thanks (as always!)
Can you elaborate on what a loss of almanac data means @Yuri_Rage ?
I also noticed another interesting thing on a brand new drone (same drone model, same GPS models). Initially when I set it up, GPS 1 was not getting a fix (much like when the problem occured) and no RTK.
Then, when I swapped around the antennas (antenna from GPS 1 switched with antenna from GPS 2), both GPS got fix almost immediately, and rtk-fixed.
The antennas appear to be identical, with the only difference being serial number (presumably that is what S/N stands for?).
Any ideas on what this could mean? Are these F9P GPS modules calibrated to work with one specific antenna or something like that? @cuav_le , @CUAV-Ricky , @cuavRC ?
Scratch my hypothesis on almanac data. The F9Ps should cold start within 1 minute, regardless of previous state, and even faster under warm start conditions.
Almanac data is indeed still useful, but the F9P is a newer generation GPS that does not require a full almanac download prior to acquiring a fix (something I didn’t fully understand yesterday). This datasheet excerpt provides the basics, and there are some uBlox discussion posts that provide a few more details on exactly how this works (beyond the scope here). The short version is that almanac data is available on a 12.5 minute cycle, but ephemeris data can be gathered within a minute. Older GPS variants required the full almanac, while newer ones with more processing power can derive the necessary information with ephemeris data alone.
Your latest observation when swapping antennas again might point to some sort of connector/cabling damage or issue. (EDIT: or maybe not, since you did this on a different vehicle - I missed that at first).
The modules and antennas should almost certainly not be matched pairs. I would guess the handwritten numbers are just quality control marks.
Do you happen to have some compatible patch antennas that you can try? Might be interesting to use a different antenna style for comparison’s sake.
Thanks for the detailed explanation, I appreciate it.
Yes, the fact that this problem occurs across both dornes (used, and new) and 3 GPS pairs (6 modules) makes it seem unlikely that this is some issue with a loose fitting SMA connector or poorly shielded antenna cable.
Unfortunately we do not have any different GPS antenna models or non-helical antennas 
Any ideas here?
Let’s be careful calling the perceived problems identical. You have a singular data point from the new vehicle that doesn’t exactly match observed behavior over time on the previous one.
However, if you can show a log where the second vehicle performs identically, that may be illuminating.
You are right, true. Perceived similarity != same root cause.
Unfortunately that occured when disarmed, so I have no log. We however did conduct some hover tests for the new drone (with the same GPS module models in it) today, and everything behaved great in QLOITER / QHOVER (and QLAND). The logs for that are here. GPS behaviour looks good.