PPK Issues with L2 Data Using a State CORS Network

Hello everyone. I am running Emlid Studio 1.9 and am trying to post process DJI L2 data. My RS2+ indicated that I had an RTK fix throughout the flights (there were 3 separate flights for this mission), but the first flight shows that 57.2% of the positions were in FLOAT. Here’s the satellite data for the first flight:

In Emlid studio, I carefully followed the directions posted here:
https://docs.emlid.com/emlid-studio/drone-data-processing/rtk-drone-data-processing-workflow/?_gl=11n5nkt5_gcl_auNTExOTU2MzcwLjE3MzcwODg4NDkuMTI3MTE5MTE5Ny4xNzM3MDg4OTU1LjE3MzcwODg5NTU._gaNjU4ODIxNzM0LjE3MzcwODg4NTA._ga_2L30ZMM7Q4*MTczNzIyMzQyNy41LjEuMTczNzIyMzQzNy4wLjAuMA…

I changed the name of my rover (drone) .RTK file to .rtcm3 and converted it to produce two files, a .250 observation file and a .25P navigation file.

I recently upgraded to an RS2+ and tragically forgot to check all constellations for my base GNSS raw logging and only had GPS satellites for my rinex base file.

So I downloaded correction data from the nearest state CORS network. I input those files into Emlid Studio to obtain a fix for these positions, but still have the same issues with 57.2% float. It also says that my base is 0.0 km away. The CORS data that I’m using as my base was actually 20 km away.

I made sure that I downloaded CORS data from times that overlapped with my rover files (.250 and .MRK). Per the link above, I used the state network observation and navigation files (.25O and .25P) in the conversion process. Am I missing something in this process? My files are here

https://drive.google.com/drive/folders/1tdgwcFwK64WltNuSzFxZfubnRDzZONhU?usp=drive_link

Any help would be greatly appreciated.

Don’t really know why Emlid Studio would report 0.0 km baseline on this. I see the same.

I tried using another postprocessor, EzSurv. Here I get a 66% fix solution, and a 23 km baseline.

Do you have the Emlid Base gps-only data still ? Could be interesting to try with. If I just do GPS only in EzSurv, I get a 74% fix solution.

1 Like

The files have been uploaded in my shared folder. They’re in a folder titled “Emlid_base_GPS_only”

I can only see that, unfortunately?

I’ve updated the permissions

I think the link point directly to the folder/archive, so maybe an new/additional link is needed ?

1 Like

https://drive.google.com/drive/folders/1E8ZdDfNiRdl86SUNcFw-C_t_VHoYlBEd

So, that yields a 100% fix rate.


However, it is just 30 sec interval data, which leads to a lot of interpolation being done as compared to the 5 Hz data from the Drone.
Do you have the UBX file? Then you also might have the higher rate data? 1 Hz is fine for the base.

1 Like

I uploaded the UBX file to the “Emlid_base_gps_only” folder

That yields an even better fix ratio (getting first fix earlier). I’d go with the Emlid as base for the drone data. Then you can likely use the CORS as base for the Emlid, for calculating the position of the Emlid receiver.

1 Like

Wow. Great. Can you elaborate on what you mean by “then you can likely use the CORS as base for the Emlid, for calculating the positon of the emlid receiver?” Would I do that in Emlid Studio, in Kinematic processing?

You first make a static processing between the CORS base and your Emlid base. This will establish the absolute position of the Emlid base.

Then you do a Drone Data Processing with the Emlid Base data and the Drone data, and use the newly processed Emlid Base position as the base position.

1 Like

Got it. Thanks. I actually had 15sec intervals from the CORS station in the folder that I shared with you. I updated it with the 1 sec data from the same station:
https://drive.google.com/drive/folders/1ss3fu1Sbc23LuKPijnUAVFT04YdzyE_c?usp=drive_link

I wonder if that will give me a better fix than my GPS only base on site?
I will try the PPK software that you’re using.

1 Like

For the CORS to Emlid Rcv, 30 sec interval is fine, but given the relatively short observation, then 1 second might be better.

I don’t think it will give you a better fix rate. For kinematic processing, 20 km baseline is generally a bit too long. For static, no problem at all.

2 Likes

Hi Jason,

I’ve checked your data, both with the CORS and the Reach base. As Christian mentioned, the Reach base indeed provides an “easier” FIX, but I could obtain 100% FIX also with the CORS base using the following post-processing settings:

Regarding Static processing, I’d like to share our guide. It describes step-by-step how to use the logs to obtain the accurate position of your Reach base. After you have the coordinates, you can add them for the Drone data processing under the base log.

3 Likes

Using NGS guide for post processing in their OPUS machine is a good tutorial for percentage of “fixes”
when post processing yourself or using OPUS

https://geodesy.noaa.gov/OPUS/about.jsp

1 Like

Thanks Kornel. That’s helpful.

1 Like