I’m currently using the Mettatec X5 for Phantom 4 Pro v2 and have been having issues with post processing in EMLID Studio. I’ve mapped the same area a few times and got a 96% fix on the first attempt but haven’t been able to even get a percentage of FIX on the following two maps.
I’m using publicly available CORS data (while I wait for the funding to buy my own GCP) within a ~15mile range of the site.
For some reason, the data on the X5 seems to be recording 4 hours ahead of my current timezone. When I got good results on the first map, I downloaded CORS data to match my current timezone (I’m in NYC, so GMT-4) and sampled at 15s. I’m not sure why, but that’s what worked!
I attempted to match this process for the rest of the maps but its coming back as 100% FLOAT with only ~10 data points. I also tried getting different datasets from CORS in different timezones and sampling rate but with roughly the same results.
Because I’m pretty new to PPK, I’m not sure how to interpret the data properly. It looks like the X5 was actively collecting data by the file size and from looking at the dataset in notepad, but I can’t definitively say if it is correct!
Could someone take a peek and give me some direction? It’d be much appreciated!
I’ve attached screenshots of EMLID and the rover/base data for post processing
Your correction data is in 30 sec interval. Download the 1 sec interval files, and you should be able to process.
I would though say that 15 miles (24 km) is on the long side for getting tight precision between the images in the mission. Would advice to be under 10 km (6-7 miles).
Thank you Christian. I was thinking the time step and the distance was an issue too but it worked out pretty good for the first job I did (I got 96% fix). Buying the equipment makes the most sense right now to be honest!
I do have one other question, would the base time step/distance have an effect on the points showing up in EMLID studio? I took roughly 300 pics in the second map but EMLID is only picking up ~10. It seems that the file is large enough to suggest that the GNSS module was recording data as expected but I’m not sure by looking at it, I’ll need to spend more time understanding the raw data.
I can confirm Christian’s suggestions. The baseline and update rate has a significant impact on the result. I assume the quality of your raw data was good enough to achieve FIX despite the low update rate.
To make sure you get the most out of every survey, we recommend that you work with an update rate of 1 Hz for the base and 5 Hz for the rover. The update rate of a GPS module is how often it calculates and reports its position in a second. 1 Hz means the receiver logs their data every second, so if the CORS station’s data has only a 30-second interval, then it is not dense enough to achieve the best results. If you use data with proper density and quality, Emlid Studio should find all of your photos’ locations.
Thanks for the help Zoltan. It seems the NYBR CORS station only outputs 30s time intervals even though the dropdown has options for better time steps. I managed to find a station closer with a 1Hz timestep with a little bit of improvement. Its still only picking up 10 data points which is concerning to me. I’m wondering if the issue is with the GNSS module, would you know how I could diagnose this? Maybe there is a resource online to help with getting a better idea of this through the raw data? Time to put my Sherlock Holmes hat on!
We’ve double-checked your screenshots with the team and noticed that you are using the navigation file with the 23n format. It only contains the GPS satellites’ ephemeris. Please try to use another file. 23p would be the best since it contains mixed GNSS data.
Thank you, I didn’t know the know the difference so that’s good to know! I was wondering about this too. I tried both file types previously and for whatever reason, 23n gave me better results. It seems to be doing the same thing for this survey.
I see. So let’s go further. I’d like to try to reproduce your processing, but I can’t find your drone’s observation file (X5_logs_230807_140744.23O). Could you please upload it to Google Drive?
Hi Zoltan. I just added the file to the google drive folder. This is in ‘model airfield 2’ > 'Survey Files > ‘Rover’ > ‘rinex_x5_logs…’ from the same link in the previous post.
I just added a few different folders with data. The folder titled ‘nybp 1s GMT0 1400 to 1500’ probably makes the most sense since the rover data is recorded in a different time zone.
Thank you for providing data from the CORS station as well. I attempted to achieve FIX from your data but was unsuccessful. The reason, in my opinion, is the poor quality of the drone’s data. The drone barely saw any satellites during the first part of the mission. After that, the quality is still inadequate, with numerous cycle slips. I believe we can only achieve some FIX at the end of the mission, but it is not enough for a good result.
Is it possible that some obstacles covered the clear sky view, or that there was radio interference on the site?
Thank you for looking into this! I think you might be correct, LGA international airport is a few miles away (it is OK to fly here up to 100ft through LAANC in case you’re wondering). Do you think this may have been a blockage?
It was also overcast that day, would this have also been an issue do you think?
Similar outcomes are possible in such circumstances. I believe that the best way to ensure it is to conduct a test in an area where all conditions are proper.
