I expect more significant fluctuations based on tidal predictions for this area. Tide predictions for this general location are forecasted for the Eureka weather station here. But there are no reference tide gauges for this region so were relying on the GNSS data to validate it. Note: These tidal predictions are in a different datum and I haven’t transformed anything yet as I’m just starting to look into this. But I just plotted up the predicted changes in sea level elevation vs the RS2 PPP measured change in ellipsoid height at 30 min averages and it actually matches quite well for magnitude of change in most instances.
Thanks jbonde002 for your insights. From my research before we left I did have some concerns that due to the geometry of the satellite overpasses at such high latitudes that we were pushing the boundaries for collecting high vertical accuracy data. I’m hoping that we can still tease out a signal here.
I should also note that during our surveys of ice height we had two more RS2 antennas running, in-addition to the permanent land base station and the permanent sea ice base stations that were recording at 30 second intervals. I normally setup a ‘local’ base station RS2 on a tripod at the survey site, which recorded at 5 second intervals for 3-5 hours, and then we ran our rover RS2 antenna on a 2 m pole, recording at 1 second intervals. I used the ReachView3 app to record the elevation of the ice at each of our auger holes for 2 minutes with this rover. Our survey sites were on average up to 9km (5-12km) away from the permanent land base station.
I will be using all the different insight and advice here concerning my two ‘permanent’ stations to help guide me in processing the ‘local’ survey data as well.
After seeing a bit more information I think you will be able to get good info from the PPK data. The two days of data you provided seem to have the least height variation and the first day had some extra noise likely from a more than normally disturbed ionosphere.
The K-indice is just a general indicator, but when you start getting up in the 6 or 7 range that can easily translate into a few extra cm of position error. It’s noticeable with larger than normal residuals after post-processing. That is if the local area does happen to be disturbed.
As for merging your multiple 24 hour files into one GFZRNX software can do that.
I learned a lot of new things thanks to your case! I also came to the conclusion that there is no single solution for this. PPK Kinematic, PPK Static for short intervals, or PPP Kinematic – everything should work. I only wanted to add that all these methods provide almost the same level of accuracy. As @jbonde002 showed, the trend is similar, but the data is less or more detailed.
If I had a choice, I would go with PPP Kinematic option just because it seems easier to analyze the results this way.
Thanks to jbond002 for the gfzrnx reference. I used the splice tool to combine my 24 hr RINEX logs for my permanent land base station. The spliced files can be uploaded to NRCan’s online PPP tool for processing or be used by EMlid studio. But I did note that RTKplot cannot display the normal plots when I open the spliced files??? So I guess the formatting is changed somewhat. I did find out that NRCan’s online PPP tool only processes RINEX files that are less than 7 days in duration - so I still can’t PPP process my whole permanent land base station project data all at once. But at least the multi-day spliced base station files allow me to process all my rover data in Emlid Studio in one go!
I wanted to do another comparison of the PPP calculated position of a rover antenna left at a survey site for 24 hours with the estimated position of this same rover using Emlid Studio’s PPK correction. But this time both units were on a non-moving platform (land instead of sea ice). The base line was about 11 km.
In Emlid studio, using static processing, I was able to get ~74% fix solutions (I did note that the fix/float results did not seem to differ very much). The average latitude/longitude outputs were within a couple centimeters of the PPP estimated rover position, but the elevation values were off by ~42 cm! This is really not giving me confidence in using any PPK results for elevations values for my project! I can’t figure out where this discrepancy is coming from. I did the same comparison using both the combined gfzrnx and original RINEX files as the base station and got the same results to make sure it wasn’t the splicing tool causing this issue.
Permanent Land Base Station gfzrnx combined files:
PermBase_gfzrnx.zip
*Note - I also posted the same data in original format not spliced together: PermBase_OriginalRINEX.zip
Rover Station File:
ECCC_reach__raw_202204270639_RINEX_3_03.zip
Here is a screenshot of the Emlid Studio settings I used to PPK - I used a 30 second interval (rover recorded at 5 second intervals).
I get about a 2 cm horizontal and 6 cm vertical difference in coordinates of your 4/27 “rover” file when comparing the CSRS-PPP static value with an RTKLIB static differential (11 km baseline) value. If you got a 42 cm vertical difference I would guess there’s an antenna height error somewhere along the line. Perhaps a mixup with the 2.0 meter and 1.505 meter heights or something not being applied correctly. I’m using the latest RTKLIBExplorer version, not Emlid Studio.
The quality of your rover file on 4/27 looks good. Unfortunately your base files for 4/26 and 4/27 seem to be of poor quality. CSRS-PPP fixes 91% of the observations of your rover file, but only 38% of those of your 4/26 base.
Thanks for sharing the data! I’ll need some time to take a closer look at it. Still, I’d agree with @jbonde002 about the fact that a 42 cm difference looks like improper height settings. Can you please specify what values from NRCAN you compare with the data from Emlid Studio? It looks like there may be some kind of confusion with the vertical datums.
I was using the NRCan PPP calculated position of the rover which was: 79.98707427 N, 85.9465512 W with an ellipsoid height of 7.404 m ECCC_reach__raw_202204270639.pdf (1.6 MB)
Yes - it seems that I had an antenna height error in Emlid Studio that lead to the 42cm discrepancy. You can see in the picture of my previous post that I left the height as 0 cm. I tried again and entered the correct values here (1.505 for base and 2m for rover) and the calculated PPK ellipsoid height was 7.339 m, which is 0.0656 m less than the PPP estimated ellipsoid height. This is much closer, and similar to what jbonde002 found.
I was under the impression that if I had entered the antenna height in the ReachView3 App while setting up the antennae in the field, that I didn’t need to enter the height in Emlid Studio again. That this in fact would be applying a height correction twice? But I guess I was mistaken.
Well, if you set up your antenna height in the Logging tab, it’s automatically recorded to the log. Then, it’s automatically uploaded to the Emlid Studio so you don’t need to insert anything manually.
From your previous screenshot, I can see that in both base and rover cases your antenna heights were detected as zero. However, if I use your files, both of the heights are uploaded correctly. Please take a look at this screenshot:
