Many missing solutions in PPK/DGPS

Running the latest beta, version 2.2.4. Using the latest Emlid RTKLib.

I am having trouble working out what is wrong here. When I process these logs large sections from the flight do not produce any solution (Q=0). This happens either using SBAS or in Kinematic mode. Processing in single mode however produces a complete set of solutions.

Plotting the satellite visibility shows many dropouts, which I assume may be the cause?

The setup is new, but is using the same ground plane and mounting system I have used before, with good results. There are a few vibration issues and the fact that all sats are dropping out at the same time makes me suspect perhaps the problem is related to this.

I’d be grateful for any insight on what is causing the issue. Here is the setup:

Rover logs, base rinex, etc. (5.4 MB)

Satellite visibility:

Thanks very much…

Looks like there’s a lot of noise near the antenna - it may be coming from some other electronics equipment like SD card interface of the microcontoller in Pixhawk, or camera, or something in another GPS.

Place the antenna higher, keep other electronics as far as possible.

You may try to disable some of it to determine which equipment is causing this.

Also, are there any rapid changes in temperature during the usage?

Thanks very much. I have tried to correlate the gaps in the sat visibility with the copter logs but not found a good match. There are a few potential RF sources, but I thought nothing worse than on previous builds which have worked fine.

I would prefer not to move the antenna further vertically from the camera sensor as the tilt angle of the machine in motion creates a varying offset from the antenna which is hard to account for, but I will give it a try.

Is it possible that vibration could cause this kind of signal dropout in your experience?

1 Like

I experienced similar issues, still attempting to resolve, on a similar configuration, S900 and Pixhawk. One way to raise the antenna, would be to use a large CF rod, and even better, would be CF tube.

Here is a different system altogether, yet notice the size of the antenna support. It’s big, robust and something I am going to need to use to see if I can get better readings with as well with the same antenna.

That really looks like an RF noise issue, and it is quite possible that camera may be the source of it.

@mikhail.avkhimenia, why do you say the camera may be the issue or source of the RF noise?

Because cameras are packed with lots of high frequency busses and other stuff.
Even the simple RPi camera produces quite a lot of noise in GPS frequency range.

Got it. Any testing or evidence of the camera being the issue? Based on that line of thinking, the camera would also affect the GPS being used for nav purposes as well, no? Both GPS receivers are using the M8 from uBlox, so I am really curious as to any actual hard data.

I will test again with the camera off and see if the above thought holds true.

I’m not saying that it is definitely the camera, but it is just one of the possibilities that I have experienced.

Another receiver uses code signal for navigation, not carrier phase measurements. Also it is installed in another place, it has different circuit so it may be affected differently.

@mikhail.avkhimenia, will you elaborate on you comment, "[quote=“mikhailavkhimenia, post:9, topic:5137”]
Another receiver uses code signal for navigation, not carrier phase measurements.

I may be incorrect in my understanding on the GPS receiver on the Reach. Is it not the uBlox M8T? On the UAV’s, we are using the uBlox M8N. If I understand your comment correctly, the M8T and M8N are using different data from the GPS sats? And specifically on Reach in Single mode, the data from the GPS that is being used is different data than what is being used by the M8N?

Back to the RF interference issue, what can be done to shield the Reach/Edison/uBlox unit from RF interference?


My previous machine ended up with this arrangement, with good results:

Even when the Reach antenna was mounted a few cm from the PDB and motor power wires, and with the antenna cable running through the whole lot to the Reach, mounted next to the telemetry radio, I never saw a signal issue like this.

Obviously this is a new build, with unknown RF emission properties, but the antenna is not significantly closer to any sources than my other unit I don’t think, so I was surprised to see an issue of this magnitude.

I’ll do some experimenting and post back here with results.



@timvand M8N uses code tracking for navigation. Reach also tracks code for a single mode, but for RTK modes it uses carrier phase measurements.

Back to the RF interference issue, what can be done to shield the Reach/Edison/uBlox unit from RF interference?

Putting everything as far as possible, using shielded cables, covering open electronics with RF shielding tape.

@mikhail.avkhimenia, my bad for not being clearer in my communication, which led to confusion. In all the cases I have been dealing with RF issues, Reach has been in Single mode, not Kinematic on the multirotor. There was a suggestion to minimize vibration of the Reach unit itself, which was done today(2/22/17-1340PST) and will post process the data tomorrow, 2/23/17. Two short flights were made with the Reach unit cushioned in foam, one flight with the camera on and taking photos, and the second flight with the camera off. Additionally, the antenna used is the Maxtenna Helical.

Regarding RF shielding, that is another subject unto itself. This issue has been plaguing this configuration for a year now, and part of the issue has been taking the time to iterate through the process of removing/moving/taking something off/adding something to the mix, and really, not getting closer to a solution. Will keep poking at it, and maybe move onto another platform.