Unable to get PPK fix on rover data

  1. Emlid Studio 1.5
  2. Raw data you use for post-processing is here:

I’m unable to get a fix on my rover data, every point is labeled as single. Our base station was set up in a forest service parking lot and then we skied in with the receiver. I’ve compared our data to LiDAR in the area, the XY data seems to be generally correct but the elevations are pretty far off.

I used OPUS to get the base station location and it matches well with the auto population from the base file.

I’ve tried trimming the base file to only the survey duration, we had about a 2.5 hour ski to the field location before we began surveying.

Thanks for any insight! I’m relatively new to surveying and the Emlid equipment.

I did take a quick look at your data and basically I got a 60%+ fix rate mostly in the western half of the area. Now that doesn’t mean the data is good, but it’s a positive sign.

I’m using the latest version of RTKlibexplorer’s software which has been diverging from Emlid’s, but it shouldn’t be that different yet.

Why have you got no fixes? Could be as simple as entering the wrong base coordinates. What did OPUS say the base coordinates were? Maybe we can go from there and figure things out.

Hi Andrea,

Welcome to our forum!

The thing is that you missed the minus sign for the Y coordinate in the manually inputted base coordinates. This base position refers to the east hemisphere, while your base was located in the west hemisphere according to the coordinates in the RINEX header.

Once I’ve inputted the correct base coordinates and used the following settings in Emlid Studio,

I got the following result:

Overall, the data isn’t of the best quality, so such a result is expected. The base and rover logs are shown in the screenshots below:

You can see that there are a lot of red bars, which means cycle slips. They occur when the satellite signal is interrupted or there’s strong interference nearby.

Curiously, the base log’s quality suddenly dropped at a specific time:

From that moment on, the SNR (signal-to-noise) values got lower, and multiple cycle slips occurred. It looks like some interference source put its impact on the base receiver.

Just in case, I’ve attached the resulting pos file in the zip archive.
Andrea Creighton 35262.pos.zip (218.3 KB)

Hello, I tried a little magic trick called “use a virtual base made in the Rinexlab

This got about the same fixed percentage than what Kirill did. The skied path seems a bit better determined though.

The settings are just different on the SNR L1 value.

You can download the base RINEX and the pos file here.