Hello - I was involved in a project where we setup two Emlid RS2 antenna’s on tripods and powered them with external deep cycle batteries for over two weeks this April in the Arctic. One unit was setup on land, while the other unit was setup out on the sea ice, approximately 8km away. Our plan was to measure the change in elevation height of the sea ice during its daily tidal fluctuations. I was impressed with the performance of these antennas, continuing to operate in Arctic temperatures between -30C to -35C for extended periods!
I have continuous 24 hour RINEX logs from these two stations. I have used NRCan’s CSRS online PPP tool to estimate the position/elevation of the land base station in static mode, and I used the same online tool to estimate the position of the sea ice base station in kinematic mode because the sea ice does have some movement. In this area the sea ice is largely landlocked, but it can have small lateral movements, along with the daily vertical tidal movements. For the land base base station I have taken the average of the daily PPP outputs to estimate the ‘true position’ with sub-centimeter results in XY and 3-4cm results in Z. For the sea ice base station I plotted up the *.pos output file’s elevations to estimate the change in sea ice elevation over time. This area doesn’t have very high tidal fluctuations (10s of centimeters), and we are able to see some of this change in the time series looking at the PPP time series.
My original plan though, was to use the land base station and Emlid Studio to PPK the sea ice base station to more accurately estimate the changes in elevation of the sea ice base station (PPK being more accurate than PPP typically). However, my first few attempts at processing the first couple days of 24 hour logs in Emlid Studio ended with pretty poor results. I could only get fix solutions of less than 20%. One of the limiting factors might be the terrain. The terrain behind the land base station was pretty steep which may be an issue for PPK of the two stations?
I will attach several 24 hour RINEX files from both the land and the sea ice base station. Maybe somebody might take a look at this data and help me determine if PPK is an option. Or if I will have to just continue working with the PPP data.
I have a related question on whether there is a tool available or an Emlid Studio release capable of merging the 24 hour RINEX files into one large file for processing? We did not save the UBX files because they took so much more storage on the RS2, so I only have the RINEX files for this.
It seems you have some Signal-to-Noise Ratio issue. You generally have quite a few cycle-clips, and your L2 band suffers like crazy. Normal SNR for L2 on the RS2 is 40-50 dbhz. Here, you hardly get over 30 dbhz, which is unusable for RTK use.
I might have missed something here but I get close to 100% FIX both days with PPK static.
Yes, there is some noise but the data is solid as far as I can see.
30 second sample rate is not good for kinematic, so I cant tell how that outcome would be.
Did you untick Integer Ambiguity Resolution for Glonass and BDS and use Continous for GPS?
Roger… On the files starting from the 14th?
In Emlid Studio I get Float more or less all way through.
Can’t get anything on both RTKpost demo b34e of b34f1.
Right, so the 30 seconds obs-interval has ruined the potential for a kinematic solution. So your data-resolution from these data will be limited.
I guess you could split the Rinex files into 6 or 12 hour chunk, and then process in static and then plot each resulting location. Wouldn’t go below 6 hours, when dealing with 30 sec interval data with the questionable data-quality.
The sea ice moves quite slowly, so I didn’t think a higher sample rate was necessary. I didn’t realize that it would prevent me from running the PPK in Kinematic mode.
I just tried using TB_RTK’s settings in static mode and got +90% fix. But the *.pos file output doesn’t show the expected tidal fluctuations in sea ice elevations. It is basically flat. I guess a 30 second sample interval, even on a virtually non-moving platform is not high enough to calculate good PPK corrections? I thought the higher sample rate was necessary for tracking a fast moving platform (drone), not really thinking it would be necessary for calculating an accurate PPK position on a very slow moving platform.
Here is a quick (unsmoothed) plot of the daily elevation variations at the sea ice base station at the raw 30 second intervals extracted from the PPP *.pos files for my time series. These elevations are fairly realistic values for this region. I was going to take 30 min averages here to estimate elevation at 30 min intervals to remove some noise. But perhaps this 30 minute interval is too short for using PPP processed data?
I’m not that sure on the recommended best practice to use with the Kinematic PPP processed data from the sea ice base station. My understanding is that the PPP processed data typically has decimeter accuracy, but I was hoping the accuracy would be higher on an almost stationary platform like sea ice. If I’m going to have to rely solely on the PPP results (since PPK doens’t seem to work), to best estimate the elevations at the sea ice base station and I want to get the most accurate estimate of elevation, should I be breaking up the raw RINEX files into larger hourly, 3 or 6 hourly intervals and submitting that for processing to NRCan’s online tool, or can I work with the 24 hour PPP *.pos output file that I processed at 30 second intervals and just average the data into larger hourly intervals to reduce errors and improve the elevation accuracies?
Regarding Emlid studio i would think the static mode assume a non moving rover and skips the prediction update step entirely and just assumes the rover is where it was last sample. This is probably why you see a flat position. Emlid might elaborate the recommended setting in this case for the studio.
The native RtkLib has options to handle such scenarios, its also used to measure tectonic movement over time in static mode.
How you configure e.g the kalman filter is one way. So you can alter the way how it interprets a moving static position with a low rate.
I see a big discussion that moved further than your initial question. I’ll take a closer look at your data, but I want to clarify one question as I’m a bit confused:
Did you compare these results with the PPP solution? Or do you just expect more significant fluctuations based on your experience? Both answers are totally fine. I’m just trying to understand if you expect some exact values or not because it defines the direction of troubleshooting.
Speaking about the update rate, 30 seconds indeed may not be enough for kinematic mode. But I believe if you output All Solutions from Static calculations, it should be ok. But as I said, I’ll check your data and share more thoughts.
The GNSS data doesn’t look that bad. Ultimately though I think the problem is you are trying to pick up a signal which is basically at the noise level of GNSS processing.
Can you see a ~2 decimeter height variation with PPK with high quality data and a relatively short baseline (a few km or less)? Generally yes. As the baseline gets longer and/or the data quality becomes less that 2 decimeter-level signal disappears into the noise.
In the Arctic you are going to have more problems with height determination just because of geometry issues. Note that where you are GPS/GALILEO sats never get more than 60 degrees above the horizon. This makes for a poorer VDOP versus the mid-latitudes. Also those lower in the sky sats tend to suffer more from multipath. It’s been a while since I’ve done any work in the Arctic, but vertical accuracy tended to be about 3 times worse there compared to the mid-latitudes.
Both data sets you provided look about the same. With kinematic L1-only processing (RTKLIBExplorer demo5 34bf.1) essentially 100% fix rates can be obtained. Bring in L2 and it drops a bit though the solutions are almost the same. There might be a ~2 decimeter height signal there, but is it real or just noise? Since the data can be processed in static mode without blowing up you are near the noise level. The image shows the scatter (green dots) from a L1-only fixed kinematic solution and overlain (blue) is a 2 hour time period static processing of the data.
For what it’s worth, the trend is similar to CSRS-PPP kinematic processing. Maybe the PPK data ends up being slightly better than CSRS-PPP, maybe not. I’d certainly compare the two.
