Problem with Ublox Neo M8N GPS Module connected to Matek F405 STD running ArduPlane

We are working on a project on Nano Talon, fully assembled without VTX and with Matek F405 Std FC running Arduplane firmware (v4.0.9 a632c813). It flies really well and stable on Stabilize, Manual modes. Now we want to move towards autonomous flight modes. However the GPS module (Ublox Neo M8N) started showing some issues with 3D Fix as satellite count was at 0. Then again it was tested at the rooftop of another location, where the sat count increased but was only able to get 6 satellites connected on average and a maximum reading of 8 satellites, which is not at all useful for autonomous flight (we need a minimum of 8 satellites at all times). Furthermore, on some instances the sat count would drop to 0, further increasing the chances of crash on autonomous flight mode. Therefore, various steps have been taken to find a possible solution to fix this problem and to get a better understanding of what is the root cause of this issue.
Test Condition: It was tested on the rooftop, with Nano Talon placed under clear sky.

  1. Installing a brand new Ublox M8N GPS module. Same problem exists. (6 sats on avg).
  2. Changing a few parameters on ArduPilot firmware. Same issue existed.
  • GNSS_GPS_TYPE: Ublox Neo M8N supports 4 GNSS; GPS, GLONASS, BEIDOU, Galileo. Changed this param on various combinations, giving us the best output at 8 sats on GPS + GLONASS. and on 0 which is the board default. So, no need to change this.

  • Serial3_baud: The baud-rate was set to 38k by the ArduPilot firmware on GPS_AUTO_CONFIG, tried manually changing to 115k. Same error persists.

  1. Another Flight controller: Pixhawk 1 was tested in the same conditions with the same GPS module. The problem existed on it as well, pointing that the issue was with the Ublox M8N GPS Module.
  2. The GPS module of previous Quadcopters (having the same Ublox Neo M8N GPS Module) were also tested under the same conditions, giving us same unreliable data.

So next day.
We attached the plastic casing that comes with the GPS modules, which somehow improved the results, but high fluctuation still existed. The sat count would jump from 6,7 to 0. Next, we tried to power off the crossfire nano rx to verify if the receiver was interfering with the GPS, and yes it appeared to be interfering as powering the Rx off gave us higher satellite count (up to 13) and it was stable as well (average at 11).
Therefore, we concluded that the problem must be due to RC interference. So, our possible solutions were; Try different Antennae placement, shielding of GPS. We tried shielding with Aluminum foil (Wrapped it at the bottom, outside the plastic casing of GPS module). And this worked! With the Crossfire Nano powered on and the GPS signal showing 12 satellites without any high fluctuation. The results seemed promising and problem appeared to have been resolved, so let’s call it a day and now we can work towards autonomous flights? Unfortunately no, that wasn’t the case, same day after a couple of hours, we went to test the GPS again and there it was, yet again fluctuating between 5,6 sats to 0. Tried to get it stable again for the next 3 to 4 hours but nothing seems to get these GPS module to work or be reliable enough. Is there anything that we are missing or could there be an issue with the firmware? Any help or suggestion will be appreciated.

By the way, may I ask why are you not using latest 4.1.3 version ?

Are you using TBS ? 800/90” mhz does interfere a lot with GPS and 433mhz is the worst one.
Try this: assuming you didn’t modify any gps parameters, default settings works with ARDU.
—remove your flight controller and gps from aircraft and connect to mission planner in open air + don’t power on TBS receiver and check how many satellite connected. If, there is 13+ SAT, check/change the location of TBS receiver on aircraft + GPS must be far as possible from electrical instruments.

Thank you for your insight in this @Sunnyfx79 and yes I am using TBS crossfire Nano. I tried what you had suggested but still got the same results. The problem wasn’t the Rx but the 433Mhz telemetry (the cheap ones). I’ll elaborate my findings in the next thread.