Why only Float Solution

Hi all,

I would appreciate help in the following issue:

I surveyed some points and have problems to get a FIX solution, although there are two base stations nearby. The distance to BASE_01 is 13 km, to BASE 02 it is 5 km. BASE_01 has free sky in all directions, BASE_02 has a mountain nearby (which is not ideal and might be the problem?). Both base station are close to sea level, while the rover is at an elevation of ~1000m.

I used an

  • RS3 as BASE 01 (raw log in 5 Hz)
  • RS2 as BASE 02 and ROVER (also raw logs in 5 Hz)
  • Emlid Flow to Survey indiviual points for 2 minutes.
  • Emlid Studio 1 for Post processing.

I followed these processing steps:

  • I calculated the coordinates of each base station using the Canadian CSRS-PPP Service over more than 8 hours of raw log.
  • I calculated to POS File for the Rover with Kinematic Processing. Here I observed, that I get only a FLOAT solution, when using Forward processing and an elevation mask of 15°.
  • So I used Combined Processing and varied the elevation mask in steps until 40°. I got the most FIX percentage using an elevation mask of 29°, here I get 41% of Fix in the POS File.
  • Then I executed the STOP and GO with Reach View 3 procedure to correct the individual points. I did this with all the POS Files (generated by different elevation mask values). However from 12 surveyed points only 3 got a FIX solution, although they were surveyed 1.5 - 2 minutes.

Do I have to accept this large uncertainty of probably several tens of cm? What could be the reason for that? Large vertical distance of rover and base?

Or can I enhance the processing even further to achieve more accurate point results? If yes, how shall I proceed?

I provide the relevant data here: exp_data_for_Emlid_Forum.zip - Google Drive

Thanks for any help or advice!
Kind regards,
Bernhard

This is a very interesting case and your extreme location and environment is likely causing you more problems up there than the many problems you are already dealing with.

In summary I think the additional GNSS issues impacting your results are:

  1. Arctic separation from GNSS orbits resulting in satellites lower on the horizon and overall more impacted by ionospheric effects.
  2. Mountainous terrain of your specific location impacting visibility of those low orbiting satellites.
  3. More significant ionospheric disturbances in the Arctic impacting the ability of the modelling to resolve ambiguities (“fix”).

Here is a plot that shows your location relative to the GNSS ground tracks. The GLONASS constellation extends the furthest to 64 degrees North around Iceland, but well short of your site at 74 degrees. This puts satellites generally further away and lower on the horizon.
Image courtesy of Trimbles Planning site https://www.gnssplanning.com/

Raising the elevation mask to 29 degrees and getting better results would normally indicate local obstructions impacting signals at least up to that angle. And indeed, viewing your survey site in Google Earth shows it surrounded by high mountains.

However, the net effect of both of the points above means that of the already limited visibility of satellites above the horizon, you have just had to tear away a large band of what was otherwise available. This plot of your rover file shows how most of the satellites are lower down toward the horizon, and the red area shows how much of that data below 29 degrees was removed from your processing. You can see that a large number of satellites didn’t have a chance to contribute to the solution.

In regard to the additional ionospheric issues there is some detailed information here:
Coordinates: A resource on positioning, navigation and beyond » Blog Archive » Challenges for Positioning and Navigation in the Arctic (mycoordinates.org)

And a relevant extract from that:
"This is often the case in the Arctic and the consequences for GNSS users with navigation grade receivers is a poor positioning performance with very large errors in the position solution.

For high accuracy positioning and navigation the use of ionospheric models is combined with the ionosphere free linear combinations of observations from the GNSS frequencies in order to minimize the ionospheric effect to a level where carrier phase ambiguity resolution is possible. Higher order ionospheric effects are, however, not handled by the linear combinations.

Second and third order residual errors of 10 cm or more will thus be present in the observations (Morton et al, 2009). In case of large TEC gradients it is difficult, sometimes impossible, to successfully resolve the ambiguities because of the large residual ionospheric effects."

What to do? Good question, maybe seek expert advice possibly from the authors above. The simple answer is that your best bet is probably less about processing, and as is normally the case, more about longer collection time. And in this case much more time and extending observations as long as humanly possible under the circumstances.

If I had those problem here it would be easier, I would be giving each point at least 30 minutes to an hour, maybe more. You want to give as many of those satellites as possible a chance to drift up into and through that clear space and be counted, and for as long as possible to give the processing algorithms a chance to resolve the ambiguities under those difficult ionospheric conditions.

However, you clearly don’t want either yourself or your equipment to freeze to death in those extreme conditions. And I can see the logistics of time, terrain and distance including the boat trip back to your base at GNSS base site 1.

Gutsy effort, all the best with your work. And I’ll stay here where it’s warmer.

3 Likes

Hi, Bernie

I processed your files by TOPAZ PPK. 97% of FIX using default settings.


Files I used:

Base coordinates were taken from RINEX file. One could set up required coords (manually entered) before TOPAZ processing via Settings.
TPZ_02




PPK will take long time, be patient since RINEX files are really huge (5Hz measurements, few days of data on base, > 1 GB in size)!
In result, I got CSV file w/ baseline components and NMEA,GGA w/ positions computed by TOPAZ:

NMEA,GGA: TOPAZ_GGA.log (3.0 MB)

CSV: TOPAZ_CSV.log (6.3 MB)

1 Like

Hi Wombo,

thank you very much for your reply and the link you provided! This helps me a lot to better understand, why the accuracy is not higher at the points I surveyed and that I should do a longer survey on important points. Yes sometimes it is not feasible to stay for hours on a point up there, but some minutes more should be possible and hopefully will raise the chance of getting more fixed ambiguities.

Kind regards,
Bernhard

Whoa, looking closely at these results it can be seen they are not very good.

In this case should, not could. The RINEX header coordinates are averaged, and for Base 02 resulted in an offset of 30.59m South-east of an Opus and AUSPOS position that both agreed within 9mm, and this resulted in your positions being pushed out.

So not being there to do any detailed testing I did a block shift of the TOPAZ positions from your CSV log back over Bernhards Emlid float result for a detailed visual comparison.

And it doesn’t look like there was a lot of rigor in the TOPAZ processing before all these “fixes” were dished out.

Unless Bernhard was staggering & looping around drunk up there, much of the Emlid Float result looks more like it represents the reality of his traverse.

1 Like

Hi sat, thanks for letting me know about this TOPAZ processing software! I just did the same processing, however I did not compare the results yet, but I will do so. First thing is that I did not find a indication in the results file a point is FLOAT or FIXED. Your last plot is not very encouraging that it might perform better than RTK lib.

Hi Bernie,

I checked the data and obtained results similar to yours.

Given the location, the receiver might have less time to see the satellites. As @Wombo suggested, planning the observation time would be a good idea. Additionally, it would be worth to monitor the ionospheric disturbances.