Emlid Reach reports false "fix" datapoints

Hi. I have had some problems with my thesis. It seems like the Emlid reports incorrect fix datapoints that is not coherent with the rest of the dataset. Have anyone experienced the same? I imagine this might be a software issue and not harware oriented, so might not be a problem some time from now. Green is fixed data points and black is reported float. It is visiable that some datapoints are green and way of the true position of the robot.

1 Like

Its a bit hard to read out of that image. Do you have log you can share?

I suppose in answer to the statement about false fixes, I could say that is no surprise. Certainly, we would all like every fix to be a good one, and there never to be a false one, but I don’t think it is reasonable to expect that.

As you may know, solving the ambiguities as to the number of wavelengths between the rover and each of several satellites is no easy task, especially when input errors (like multipath) are present. These bad signals are not an easy to distinguish and eliminate. It can be easier with a dual frequency receiver, but the drawbacks to that can be more cost, complication, and processing overhead.

Also, when the software decides it has a “fix,” the decision is based on several user-configurable parameters. Many of these parameters may be hidden in the most recent releases of ReachView, but they are there in the background and you could go in and change them if you want. If you want to experiment with the parameters, it would be easier to do it by post-processing the raw log files where you have easy access to all the parameters in the RTKLIB software (RTKCONV, RTKPOST, RTKPLOT).

I am not an expert with RTKLIB settings myself, but certainly you could ‘tighten up’ the settings so that you get less false fixes. The trade-off being that you would probably get less fixes and more float. You would have to decide if that would be beneficial for your use case or not.

I will also put it out there for someone to disagree with me that:

No GNSS solution (from any company’s hardware/software) is without error 100% of the time, and that the way to increase confidence and eliminate error is to take multiple readings over a specific point or path and make them at different times with different satellite geometry and see that you get the exact same results (within your acceptable margin of error).

2 Likes

First question, how low is your mask set?
If your mask is below 25 degrees then there is a real possibility of ‘stable’ multipath impacting your fix in anything but a perfectly flat paddock.

Second question, what does your ‘sky’ environment look like? Are you in a big flat paddock or are there trees/buildings above the mask cut off angle? The more built up the environment the more chance of multipath or a skewed fix.

Third question, What have you got the acceleration filters set to? If you know the dynamics of your vehicle set the filters just above them, then (once you have a good fix) the solution should ‘think twice’ before jumping to a new location.

My solution for working in a heavily wooded environment is to strap a Xoblu inertial unit to my shoe. This allows me to reject fixes that move more than the Xoblu says I have. Also allows me to splice in sections of Xoblu data when the Reach just doesn’t work. The RTKlib SD values are normally optimisitic so I use 10X SD as my error estimate for reach when using a single fix in a dynamic environment. Xoblu is accurate to 1% of distance travelled. So from loosing a ‘good’ Reach fix I can fill in a 10m gap with only 10cm error or a 100m gap with 1m error. In deeply wooded terrain this is good believe me!

Note: My use case is that of walking around mapping objects to about the 1-2m absolute accuracy and 10-20cm relative positioning. Think trail mapping with specific objects of interest.

2 Likes

I second bide’s assessment. The strategy should be to attempt a settings adjustment to force the system to be more picky about what it calls a fix. Yes, this will likely produce more floats but could also simply prevent any point from being produced. Also, I add the following.

RTKEXPLORER has a nice discussion about RTKLIB’s various settings. Most of these are not accessible via ReachView. Also, the blue text represent setting only available with RTKEXPLORER’s version as I understand it.

I have listed some of my own settings that have worked in the past for the original RTKLIB. Again some of these are not availble for adjustment in ReachView.

Filip, my reaction to your image having worked with RTK systems of all types is that it looks very good!. RTK systems allow for centimeter level precision, for example some units report 0.02 meters 2DRMS. This means 95% - 98% of points produced, assuming a FIX, will land within a 0.02 meter radius circle. Conversely 2%-5% may fall outside that circle, but hopefully not TOO FAR outside. A FLOAT FIX will be less precise, but can be surprisingly accurate at times. For example, I see that some of the black points look to be very much inline with the green points.

Filip, I also agree with your assessment, these are false fixes in the sense that the system thresholds failed to filter sources of possible errors. All units are capable of these but in my experience the higher cost units tend to do a better job tuning these out. In my opinion the false fixes are not a software or hardware issue, but simply an artifact of the difficulties associated with RTK solutions.

2 Likes

Thank you so much for the help guys! You have given some great insight for discussion, I will unfortunatly not be able to test any of the solution. We were mainly afraid that we had made some rookie mistake, but this seems to require a non default setting or change in some kind. Regardless, thanks a bunch! :slight_smile:

The setup are roughly outlined in the picture below. Two large trees on a fairly small area. There was also a large building aprox 200 meters away, this was probably easily filtered away though since it was a large distance to the building. The acceleration and velocity filters was very restricted. 1 m/s an 1m/s^2 I recall.