Reach bouncing RTK float to Fix on tractor

Using a reach w/2.2.7 firmware.

Today was my first chance to use the system mounted on my tractor for field work.
I’m receiving corrections from a VRS NTRIP system over the internet with a wifi hotspot.

When running the system would move between RTK float and Fix, with it being in float ~60% of the time.

This is in a wide open field. GPS antenna mounted on top of the cab with a 6" steel plate at the ground plane. Reach was seeing 22 satellites most of the time, 15 were being used with the correction signal.

A couple questions:

  1. Is this the performance I should expect with regards to fix vs float? I was hoping for a more solid lock, especially since it was ideal conditions.
  2. When bouncing from fix to float, te position would shift 20-30cm. why does it shift when it hits RTK fix?

I probably missed some details to help answer all the questions and will gladly fill in as we discuss.

@feepyj

This is not the performance that you should expect. Please share your log files and we will have a look at what might be wrong.

What’s the best way to share the log files (and which ones are needed). I have them all downloaded,

The one called .UBX is raw, but send them all might be an idea to see how data is processed on reach.
Put them in dropbox, google disk or something and share link is ok

OK, I’ve uploaded all the log files.

Here’s the link: Log files for GPS w/VRS correction

@igor.vereninov

Appreciate if you could have a look at the files and see if there’s something I can do to improve the stability to stay in RTK Fix.

after running RTKCONV and viewing with RTKPLOT and turning on Cycle-Slip LLI Flags under Options, we see this:

RTKLIB can handle a few cycle slips now, but if they happen on several satellites at once, then you have a problem (the short red lines in the pictures). Be it RF interference, antenna blockage, obscured sky, etc.

This is just showing the GPS satellites with a normal elevation mask. This is what is normally used to regain a fix:

This is showing all satellites with no elevation mask. This is what could be used to hold on to or keep a fix:


In the elevation map above with only GPS sats showing, you have 6 sats green, which is good, but if you look closely, some of those SNR levels are actually repeating yellow green yellow green, which is not ideal.

Tried the .ERB file and it looks pretty good to me, float with singel the last 50 sek, but before that almost only green fix.
Was this not your experience?

1 Like

@TB_RTK I agree that does look pretty good. Did you shorten up the time shown in the ERB file? It looks like 5 hours of data up above, but surely that is not 5 hours of driving shown on the ERB plot. Unless it was going reeeeealy slooooow.

:joy:
The entire erb file yes, its about 30min of data. From 2126 to 2200 UTC time.
I didnt try to process the raw file. Did you use raw 201704231658 file?

Yes I converted that one to RINEX, the 70Meg UBX file.

Also, I haven’t tried to look at the RTCM3 for potential problems or tried to post-process either.

One more thing. The recorded data spans from 1659 to 2202 UTC. Is that right? I mean, did you drive all this time?

Thanks for being willing to look into this. Are there any adjustments or changes you would recommend I make to the settings or other diagnostics to try?

As for the time period, I was doing field work for about 3 hours. @TB_RTK there should be quite a few more back and forth passes prior to what’s shown on the plot.After I was done in the field, I let the system sit static for a couple hours.

I’m a newbie to this. what utilities are you using to look at the .erb file?
Is it normal for the position to jump when switching from RTK float to RTK fix?

The .erb file seems to be started up just about 30 min before finishing of?
You can use RTKplot to open this file.
Also files ended with the nr 56, doesnt contain any data. Other then that @bide seems to have covered most of it for the main file.
If you would do a second try, start logging from all (raw, output, correction data)
Is there a official site you get vrs data from?
And setting, not sure what you used but a screenshot would tell alot.

@TB_RTK I made some headway with this. I’m not sure why your ERB solution was only partial, but here is what I saw with the full .ERB solution file as displayed by the unmodified rtkplot.exe:


I have also secretly been doing some post-processing. Here are the results:

*disclaimer: I am not at all familiar with VRS behaviour.

Here is the base RTCM3 file processed in single mode:


You can see that the base moves around from time to time. Such large movements too! ~200m! I speculate that you lost connection to the VRS, and when it reconnected, you got a new virtual base coordinate each time. I don’t think Kinematic RTK mode can compensate for such large base movements.

As you can see in this smaller overlay (red base single position overlaid over green rover fixed solutions) there are some correlations between changes in the base position and the fix status.

But this is not the only source of problems in these logs…

This attempt didn’t work out for me, but I did a post-process run in moving-base mode, but honestly, the original RTK solution was better!

The next step would be to post-process each segment of time where the VRS base was stationary. Then one could analyze for problems within those segments. But I will leave that as an exercise for the reader (as they say sometimes).

1 Like

@bide did you get more then 30min out of the erb file?
Wow, I must have done something seriously wrong :scream:

Oh well, no big deal. Maybe your ERB file was truncated or you had Time Span / Interval settings ticked in RTKPLOT?

Could not find any wrong in settings but with no further due, i just deleted the config file and that made it work. :flushed:

1 Like