Emlid Studio 1 Beta 7 - PPK vs Stop and Go Solutions

I tried the Emlid Studio today. I have been surveying the same site, multiple days in a row. The survey site is in a wide open field. I wanted to try processing the data to produce GCPs for input into Pix4D. I used the ReachView 3 app to record my surveys of the GCPs. I previously previously calculated the position of my base station using the CSRS-PPP online tool.

I followed the guide for PPK processing here: Working with Emlid Studio: PPK

Using the default settings, I processed my July 23rd survey date. Does it matter what *.nav file I use? I used the Base Station’s *.nav file. The output *.pos file had 99.8% FIX solution. The green track looks accurate to what I walked while surveying the GCPs! Great!

I don’t need the whole track log (i.e. *.pos file). I really just need the points surveyed. So I tried using the Stop & Go with ReachView 3 tool with the same data to extract just these points of interest. I used the default settings, except that I outputed the *.pos file to a new folder. I got no solution at first, and then selected all data quality outputs and processed again (Fix, Float, Single). The output was 100% Single solution! Several of the surveyed points were 100’s of meters out of whack!

Any suggestions?

I then thought - perhaps my survey was messed up that day. Let’s try another survey date. I conducted two surveys on July 28th of the same site, same GCPs. I tried processing these surveys.

  1. July 28th Survey 1 (1507 UTC): PPK = 78% Fix Solution. This is pretty good. I think we had the rover inside a garage turned on recording the RINEX file, so poor data quality was being collected for a while. The green tracks still match the important part of the survey.
  2. July 28th Survey 1 (1507 UTC ): Stop & Go = 100% Single solution!
  3. July 28th Survey 2 (1614 UTC): PPK = 100% float. We definitely had the rover inside the garage still recording the RINEX file for a while after finishing the second survey. It seems that this period of poor reception may have influenced the rest of the survey when the satellite reception was superb? I’m not sure why this would be the case. I then re-processed this data, selecting the time frame just before and after the time stamps recorded in my survey CSV file. This produced a PPK output with 51.5% Fix solution, and 48.5% Float solution. Better but not great.
  4. July 28th Survey 2 (1614 UTC): Stop & Go = 100% Single solution.

So my results using the PPK output have been reasonable. I can probably improve these results by adjusting the SNR and Elevation masks, etc. However, the Stop and Go tool has been useless. I can manually extract the GCP corrected coordinates from the PPK output *.pos files and average these positions, but isn’t that what the Stop & Go tool is supposed to do for me???

I am just learning/figuring this whole PPK process out, but it seems like maybe I should focus my efforts on learning to use RTKExplorer instead of Emlid Studio? I was also wondering if Emlid Studios uses precise ephemeris and clock files from the IGS?

Thanks for your feedback…

Can you upload your raw material? Then it is easier to help.
There can be a lot of factors that affect your ability get a fix, so having your raw data to refer to makes it much easier.

I posted the July 23rd and July 28th data to google drive: The screen grabs above have the location of the base station and the antenna heights used.

https://drive.google.com/drive/folders/1xnHSkGF_Q_JcuJnR0xZGCMs9TQRRCFY6?usp=sharing

Thanks.

Hi Peter,

I processed your files from the 23 of July and got all the points fixed. I used the base position from the RINEX header for PPK, though.

Trying to compare what can be different in our settings, I noticed from your screenshot that you manually enter the base coordinates. That is why I believe it is worth double-checking the coordinates are correct.

Rover solution has a lot to do with the base’s position. If the base position is noticeably off from its real coordinates, the rover will provide the single solution only. So let’s see if this is the case.

2 Likes

Thanks Tatiana,

I processed three days of raw data logging from my RS2 device using the NRCan’s CSRS-PPP online tool for my base station location. I uploaded each of the three days of acquisition, and below is an example of one day’s output in ITRF14 coordinates. I then converted each output to decimal degrees, and averaged each day’s results to get the numbers I used in my screenshots. They are all within mm of each other, so I could use any one of the days.

raw_202105111539.pdf (1.6 MB)

I just tried to process the July 23rd data as you described, using the RINEX Header position in the base station, and I got a ‘Something went wrong’ error message. See the attached error report.

emlid_studio_0347c414da6a4df2b97cbb554b101e3a_windows-10_10.08.2021_11-10-00.zip (48.1 KB)

Hi Peter,

Oh, I think I got down to the source of the issue!

I converted CSRS-PPP’s results to decimal degrees and got a bit different values. Looks like you accidentally typed in 43 instead of 44 in the Latitude field. I’ll PM you with my results.

I also took a quick look at your PPP results and noticed that you neither specified the antenna name nor entered the antenna height. It is okay but it means that you got coordinates of the base’s antenna phase center after PPP. Therefore, while post-processing the data, you don’t need to specify the antenna height and receiver type: you enter the coordinates of the phase center, not of the point on the ground.

The thing with antenna height is a messy one, and at the moment, it’s a tricky task for us to make it clear and straightforward. But cases like yours are of great help in this.

I also suppose we may avoid the source of the conversion mistakes if we add a possibility to enter coordinates in degrees-minutes-seconds, so I’ll raise this question as well.

@andrew.belov will take care of it, thanks for sharing!

1 Like

:man_facepalming:

I was so fixated on making sure the decimal places were correct, I completely missed that… Such an obvious error.

I did specify this in the Stop & Go with RV3 tool, as indicated in the screenshots above. Otherwise, I don’t know when/where I am able to enter that information? I established my own base station over an unknown location. There is no opportunity to enter this information on the NRCAN’s CSRS-PPP service. I could not manually enter the coordinates or height of the base station location directly into the RS2 because I had not done the PPP yet. Shouldn’t the NRCAN’s CSRS-PPP online tool be able to at least detect the antenna name and therefore ARP offset from the RINEX header automatically?

I’m not 100% sure of the point you are making. Are you just pointing out that if this information was already used by NRCAN’s CSRS-PPP online tool to calculate the ground elevation at my base station location, then I would not have to specify it in the Stop & GO with RV3 tool? i.e. enter in the measured height and RS2 offset? Or did I miss some opportunity to enter this information?

The NRCAN CSRS-PPP online tool is widely used, so it makes sense to be able to directly enter in the coordinates in the output format that they provide! Removing the need for a user to convert their own results, and potentially introduce errors is a great idea. Even better if we could just link to an output file from the NRCAN’s results (*.sum file?) in Emlid Studio and automatically extract the base station position, completely removing the opportunity for typo errors like mine!

Does Emlid Studio need an internet connection to produce the PPK and Stop & Go outputs? Just wondering about using this software in the field, with poor or non-existant internet connections. Does it automatically download the above files? Or does it not use this information?

Does it matter if I use the *.nav file from the rover or the base?

Will I have to update my Emlid Studio version for me not to receive errors? I keep getting error messages when I try to process Stop & Go with RV3…

Hi Peter,

No one is immune to making mistakes :slightly_smiling_face:

Yes, it is how it is supposed to work. I see the RINEX header of your file doesn’t contain that info, though. It looks like your RS2 runs the outdated firmware version, which doesn’t do it automatically. If you update the device, the app will record the antenna name to each RINEX log and allow specifying the antenna height before data recording.

You still can save the situation with the RINEX header: just use the Convert to RINEX tool of Emlid Studio to put antenna info into the header.

If you specify RS2 antenna information and antenna height before PPP, NRCAN will calculate the coordinates of the point on the ground. Knowing this, you need to add the antenna height back before PPK in Emlid Studio to lift the base position up to the antenna center (the top dotted line on the pic below indicates it). It is helpful to know the coordinates of the point if you want to occupy it in later surveys.

However, if you don’t plan to come back to this point in the future, you can just handle it as I suggested earlier.

You can work with Emlid Studio in fields without Internet access. It uses the Internet for updating only.

Any of them should be fine.

Most likely, yes - if we won’t find out any external reasons for this.

Actually, we’ve just released the 1 beta 8 version, which contains tons of improvements and fixes, and the one you faced may be on the list.

Thank you again for your answers and feedback, especially for the clarification on not needing to enter the antenna height information in Emlid Studio in my situation because my CSRS-PPP online tool output files are already providing the coordinate of the antenna ARP above the ground. I will update my RS2 firmware so that I have the option of adding the height of the base station height prior to logging the raw base-station RINEX file next time.

I updated to Emlid Studio 1 beta 8. However, I am still receiving error messages when I try and process the July 23rd and 28th files. Both in the Stop and Go and PPK Tool.

July 23rd Stop and Go:
emlid_studio_0347c414da6a4df2b97cbb554b101e3a_windows-10_17.08.2021_15-19-19.zip (65.3 KB)

July 23rd PPK:
emlid_studio_0347c414da6a4df2b97cbb554b101e3a_windows-10_17.08.2021_15-11-19.zip (63.1 KB)

1 Like

Hi Peter,

According to the Emlid Studio log files, you set up the time start and time end of the log in the settings manually:

  • startTime:(2021-07-28 16:35:00),
  • endTime:(2021-07-28 17:15:00)

However, you’re trying to process the data from the 23 of July, not from the 28. It looks like this is the reason for PPK crashing. To make it work, go to the Settings and uncheck the log duration boxes.

One more hint for us on how to rework the error report in Emlid Studio: we added it to the list of future improvements, too.

2 posts were split to a new topic: Emlid Studio doesn’t process surveys

I hope this might be useful to future readers. I thought I would just make a comment on my original post where I discuss some problems I had calculating a FIX solution, especially on my July 28th survey date.

Blockquote 1. July 28th Survey 2 (1614 UTC): PPK = 100% float. We definitely had the rover inside the garage still recording the RINEX file for a while after finishing the second survey. It seems that this period of poor reception may have influenced the rest of the survey when the satellite reception was superb? I’m not sure why this would be the case. I then re-processed this data, selecting the time frame just before and after the time stamps recorded in my survey CSV file. This produced a PPK output with 51.5% Fix solution, and 48.5% Float solution. Better but not great.

I recently had time to re-visit this survey data, and have since upgraded my Emlid Studio 1 to Beta 9. It took me about 6 or 7 tries at re-processing this survey data and changing the settings, but I finally got a 99.2% FIX solution.

The settings that finally worked were:

  • Log Duration: Limited it to just before and after the survey times (avoided poor quality data recorded during equipment setup)

  • Filter type: Backward (I think data collected during the end of the survey was of better quality - i.e. better satellite reception)

  • Elevation mask: 15 (tried as low as 5 and as high as 20 - 15 was optimal)

  • SNR mask: L1=35, L2=35 (never tried changing)

  • Satellites: All (never tried changing)

  • Integer Ambiguity Resolution: Fix and Hold (tried continuous which improved % FIX when using the different filter types, but Fix and Hold worked better after I changed the filter type to Backward)

I guess this just highlights that there is no ‘default’ configuration that will always get you the best results. But if you keep tweaking the settings, sometimes you can get something better!

Hi Peter,

Thanks for sharing your results! Indeed PPK allows playing with settings a bit to get the best possible outcome. We’ll be happy to see other tests in the future :slightly_smiling_face:

Hi Peter,

I have some news based on our previous base position format discussion :slightly_smiling_face:

We released a new version of Emlid Studio with DMS format support. I believe it should make the process of entering the base position obtained from NRCAN’s CSRS-PPP much easier.

This topic was automatically closed 100 days after the last reply. New replies are no longer allowed.