Time to fix and operation near obstructions

As you have used Reach RS in the field so I hope that you can answer my question
1- how long did it take to get fix solution?
2- what is the behavior of the receiver beside buildings, trees? does it lose fix solution fast?

I’m about to buy a receiver but I want to make sure of these things.

Hope to hear from you soon.


1 Like

The questions you ask are highly dependent on the environmental conditions. I can say this:

  1. My fastest fix was acquired in about 2 minutes.

  2. It works beside building and trees.

but also:

  1. I have sat on a point for an hour and not got any fix (sky obstructions / bad satellite geometry)
  2. A fix that comes from a very obstructed sky could be very imprecise.

So, it is really hard to say how well it works until you just try it. And try it in different situations. And get to know its limitations. And be prepared to go back and try again if you have to.

Another thing is that we just got access to the Galileo satellite constellation, which should be an improvement in holding a fix, but it is too soon to say what the real benefits are.

Might I add… I test often in front of my office. Sky view is poor, and fixes are tricky to get at times. The worst is a row of tall pine trees blocking a significant part of the sky, Even worse is when those tress are swaying in 30-60 mph winds. Can track maybe sub meter in float mode, but rare fixes. Confuses the math… Not a Reach problem, but the nature of GPS systems in general. Clear sky, good fixes. Generally, usable results at 5m from two story buildings.

1 Like

I understand it depends on the environmental conditions, I’m familiar with Trimble GPS equipment (survey/GIS).
I’m getting fix solution with GPS/Glonass - L1/L2 receivers within 10 to 20 sec in normal conditions, and this period is fixed for my daily work, it never went to 5 min unless there is a big issue in the configuration.
actually what I want is to compare it with L1 receivers like Reach RS, and I’m expecting lower performance, but I want to know how it will behave.

Also we might ask Emlid to produce another receiver with dual frequencies that meet different demands like mine, and to be inexpensive one like Reach RS


Sorry, I was assuming that you were unfamiliar.

If the time difference between L1/L2 and L1-only is an issue. By that I mean the time from power on to fix, or the time between static point fixes, (10-20sec L1/L2 as opposed to 2min-5min+ L1 only), then what about doing the survey in Kinematic mode with the intention of keeping the fix status the whole time (and as you move between points).

Then, back at the office, one still has the option of post processing those points in Static mode.

Sorry, I also assumed you were a beginner.

I have been following the inexpensive GPS receivers being offered on the internet. There appear to be several available in the $2500 range and one at $750 range but being offered in a development board at $1000 range.

I think that may be the next push in gps receiver development. It’s probably a price/volume decision. Right now, the fast lock feature is probably not a key factor for low price units.

That being said, I think Ublox has various modes that allow the receiver to be placed in quick access mode, but I don’t know if it can be applied in ReachView.

In regard to initial lock time, rtkexplorer presents some results Ublox in his blog “new firmware, new satellites, new code” in a less than perfect environment. I do not know if Emlid has integrated this into their system.
At least, it appears that the code with the increased satellites and using the Kinematic mode will give fairly fast response. bide and TB_RTK have more experience in this area.

I did a test few days ago. Sky almost without obstructions, using two M8T eval boards with integrated antannas, one as base and one as rover. Used GPS only - got a fix in 18 seconds. Addind GLO+GAL did not make it faster, still 18 s.

Well a year has passed and progress makes these things get better :wink:

I used the latest Windows binaries from Rtklibexplorer (Demo5 b29b). I was surprised by the results myself. The result I write about had surprisingly same value for both static(-start) and kinematic modes. This first test was on the roof of a house. Using forward post-processing only.

I did another test this week with more obscured sky - this time on the street with the receiver put down on the ground. Sky was partially obscured by close family houses, but I guess the obstructions were only about 20-25% of the sky. Using forward post-processing, static-start and GPS+GLO+GAL - first fix after exactly 20 seconds. Did not try any other settings or kinematic mode yet.

I also did a walking test in “sub-urban” environment (quite narrow -i mean European- streets with family houses on both sides) - I was walking on the sidewalk of this street with 2 storey houses on each side (you can check Street View) and I got fix 100% time even when walking directly beside the houses. I was surprised. The logs showed about 10 sats being used in the worst case of my walk (which I think was this street). I may be posting my solution file later.

@bide - Do you have more experience with times to fix with various settings (various GNSS enabled, static/kenematic mode etc.)? I am interested in using RTK on the ground (autonomous vehicle). I am slowly getting my own experience.

1 Like

Yes, but unfortunately it is not recent experience, so I need to get out and do some testing myself to see how much better the latest ReachView is working.

Your experience sounds very promising though!:+1:

This is not about ReachView but rather RTKLIB.

Yes I understand, but we are all using ReachView which uses RTKLIB as a back end so we get the benefits as well. There is just some time lag for integration. Everybody wins :slight_smile: