FIX Takes Too Long to Acquire

Background: Reach RS2; ReachView version v.2.20.8; iPhone 6S, iOS 13.3; AT&T Netgear mobile hotspot; NTRIP source = California Spatial Resource Center; Full System Report attached (I hope).

Issue: Wait 5 to 30 minutes or more to achieve FIX.

Steps: Turn on GNSS & connect to ReachView via Wifi from mobile hotspot; Select NTRIP URL, port number, and caster closest to me (preferred) (21 - 44 km away). Takes 5 to 30+ minutes to get FIX, if at all. Sometimes changing to another caster helps reduce wait to 5 - 10 minutes.

Remedy sought:

  1. Why does acquiring a FIX take so long? 2) How does one attain a FIX quicker?SystemReport.zip (2.1 MB)

Can you also post the rctm file and .ubx file from the Logging tab?

Hi John,

Does this NTRIP support VRS?

Yes, according to the statement on this webpage. https://emlid.com/reachrs2/

Yes, thank you for asking. Here are 4 files: RINEX-3_00, RTCM3, ubx, & XYZ.

raw_202001101926_RINEX-3_00.zip (6.0 MB) base_202001101926_RTCM3.zip (909.8 KB) raw_202001101926_ubx.zip (7.5 MB) solution_202001101926_XYZ.zip (73.7 KB)

John, I mean your NTRIP provider

Ah. I do not think so. I performed a search for “VRS” on their site, and no results were found. http://sopac-csrc.ucsd.edu/index.php/csrc/

Thanks!
Have processed it, seems you have made a measurement of static point, right ?
When on the static point, I have no problem getting a fix. The NTRIP correction start at 19:38, I get a fix at 19:41.

Thank you for running the data! I am new to this so your patience and understanding is appreciated. When I tried to capture the location of a target (CP4 in my notes), after waiting 30 minutes, I tried rebooting the GNSS & tried a different caster. Some how I was able to get a FIX solution. Maybe the data for this point is not in the set I sent you. May try to re-run this test in a few days, depending on weather. Do you have recommendations how how to achieve FIX status of a target on the ground within a couple of minutes using an NTRIP 21-43 km away?

If you are using it for static work, remember to set it to static. Also be sure to look into your SNR- and Elevation Mask.

If you find that somehow your are not getting a fix, eventhough you are in a good location, switch to kinematic, wait 30 seconds, and then back to static. this is to force a reset of the RTK engine.

Interesting. I am doing PPK processing, therefore RTK settings = Kinematic. Therefore you’d suggest switching to Static, then Kinematic? Please excuse my ignorance…what is static compared to kinematic?

Ah ok, then it’s a completely different story.

I assume you are using RTKpost.

Keep to static, but remember to limit your processing to exact start/stop time you were on the actual point.

Of of course remember to use both L1/L2 when processing. If only using L1, it will indeed take very long, and the fix will be unstable.

Use static? Interesting. Honestly, I do not understand how to interpret the SNR graph on status. What should I look for? As for elevation mask, if I have a hill or tall trees, say on the south side and not on the other 3, should I still set elevation mask to be above the hill or trees in the south?

Regarding the SNR, if you choose a specific band (I would recommend L1 for this) and then you can see the SNR Legend buttom right in the window.

Hills, hmm always a difficult size. However, in RTKpost you can set the elevation mask based on SNR. This I find most useful!
In good condition this can also be used to get more sats used for the solution.

Hmmm. Been getting 31 / 13-15 satellites with default mask & SNR levels.