EMLID M2 setup and GPS solution

Hi everyone,

I’m facing some issues with my octocopter setup and would appreciate any insights or suggestions from the community. Here are the details of my setup and the problem:

Setup:

Platform: Octocopter
GPS0: Emlid M2
GPS1: Here4
Flight Modes: Manual flight works flawlessly.

Initially, we encountered a crash during an autonomous flight due to a GPS glitch when switching between GPS0 and GPS1. At the time, the parameter GPS_Auto_Switch in Mission Planner was set to “usebest”. To address this, we changed `GPS_Auto_Switch = 4.

Problem:

During flights, we observe the GPS status (reported in Mission Planner) periodically dropping from 6 (RTK Fixed) to 3 (3D Fix). However, we never see the intermediate statuses 4 (RTK Float) or 5 (Single). These dropouts last for a maximum of 5 seconds and seem to occur periodically.

Questions:

  1. Why are the statuses 4 and 5 not displayed during these drops?
  2. How can these periodic GPS dropouts be explained?
  3. Is there a better way to configure the system to handle such GPS glitches to prevent future crashes?

Any guidance or troubleshooting tips would be greatly appreciated!

Hi @ASDRO,

Welcome to the community. Could you please tell me more about your base and M2 setup?

Also, were there any potential sources of interference in the flight area (e.g., urban environments, power lines, or strong RF sources)? Further, does this issue occur across different locations, or is it specific to certain areas?

Have you also enabled raw data logging during the flights? If so, could you share raw logs from the M2 during the flight? If possible, I need the RINEX or UBX files from the rover and the RTCM3 from the base.

Thank you!

Hi @ruth.bongon,

Thank you for your response. The system is working fine for now, but I still don’t fully understand the cause of the crash.

As a base, we are using an RS2+ with NTRIP corrections. The M2 functions as the primary GPS, and so far, we have not observed any signs of interference with our setup.

During the flight, raw data logging was not enabled, but we have now enabled it for future flights.

We believe the crash might have been caused by the base losing its RTK fix position due to a lack of corrections (NTRIP). Consequently, the drone may have switched to the secondary GPS because of the incorrectly set parameter, which led to the issue.

To prevent further crashes, we are planning to survey the base’s position and operate it in manual mode with a fixed position, even without corrections. Would this approach help resolve the issue?

Hi @ASDRO,

Your analysis makes sense—the drone switching to the secondary GPS could be the cause. One thing to note: once the base position is averaged in FIX, you can disconnect from NTRIP. The base will continue using that averaged position, so no further corrections will be needed.

I’m glad to hear your setup is stable now. If the issue happens again, please share the raw data logs so we can investigate further. Best of luck with your upcoming flights!

1 Like

Hi @ruth.bongon,

As I mentioned earlier, the system is currently working. However, we have noticed that the EMLID GPS frequently switches between RTK fix and 3D GPS. These dropouts last anywhere from half a second to five seconds.

The attached screenshot shows the GPS.Status parameter (6 = RTK fix; 3 = 3D fix). This particular file represents the worst-case scenario. We also tried adjusting the baudrate, but the issue persists.

Do you have any thoughts on this?

I will forward you the raw data log as soon as the survey team is back.

Best regards,

Have you checked your setup for electrical interference from the drone itself ? Could you have obstructions blocking the antenna ? How about power requirements ? I use the M2 as just a static receiver and there have been times I’ve gotten some wonky data when the battery drops below the minimum voltage. Is the M2 powered separately ?

Just some suggestions…

Hi @ASDRO,

Are you testing in the same location as before, or is this a different site? Sometimes, environmental factors can affect fix stability. I’d like to take a closer look at your logs. Could you send them via PM or to support@emlid.com when you get them?

Also, which option are you using to connect the RS2+ and M2—Local NTRIP or Emlid Caster? If you haven’t already, it might be helpful to test the other one to see if the issue persists.

Hi,

We have checked our setup, and the antenna is positioned 15 cm away from any potential interference. Additionally, we tried shielding the antenna cable, but the issue remains the same. As far as we can tell, the antenna is far enough from any obstructions.

What’s particularly interesting is that the GPS status behavior and the number of dropouts increase over the course of a flight day (around 6–7 hours). Therefore, we checked the temperature and compass values, but they appear to be stable throughout the flights.

The M2 is also powered via a separate power source, so power fluctuations should not be an issue.

Hi,
Yes, it’s the same location as before. As far as we can tell, it should be an ideal site for testing, as there is almost nothing around that could potentially interfere with the system.

For corrections, we use a local NTRIP service, and after achieving a stable fix, we switch the base to manual mode. The connection between the M2 and RS2+ is established via LoRa, with a distance ranging from 100 to 800 meters, ensuring a clear line of sight with no obstructions (e.g., buildings, forests, etc.).

I will forward the logs as soon as I have them.

It sounds like the location should be great for testing. Sure, I’ll wait for the logs.

The LoRa radio link seems solid, but it could be worth testing the setup from this thread. It explains how to transmit base corrections via the telemetry link. Our Ardupilot integration guide offers additional details. It might help us rule out any potential differences between methods.

If you have stable internet in the survey area, I’d also suggest trying Emlid Caster.