Stop & Go vs Static for a single problem point

A survey of some Ground Control Points was performed for some drone missions. No NTRIP or RTK source was available for the RS3 acting as a Rover. The RS3 readings were taken by Averaging the reading for 1m at each point to give a Single solution.

Once back at the desk, PPK using Emlid Studio 1.8 (Mac OS) Stop & Go was performed afterwards using UK OSNet CORS Rinex data and a FIX was able to be obtained for 7 out of the 8 points.

Several attempts were made to improve the solutions to 8 of 8 in FIX by changing the SNR and Elevation masks, but In all cases the first point collected would only ever return a Float solution. I then used the same data and processed it using Static processing with the time period restricted to the observation time on the first point (plus 1 min each side). The static processing returned a FIX solution for the point. Aside from the RMS values, the positional figures were broadly similar to the Stop & Go Float solution figures.

Is it valid to attempt to obtain a fix by using the Static processing workflow for that one point? And if so, which position should I trust- the Static Processed figures (Fix) or the Stop & Go (Float) figures - which are more likely to be correct, or to have the more realistic RMS values?



1 Like

Hi Nick

If I understand correctly, you just used static receiver for each mark ?

What were your observation times ? How long were the baselines you used for PP in Emlid Studio ?

Hi Bryan,

The points were collected using EmlidFlow on an RS3 without any RTK/NTRIP Corrections. Each point was averaged for 1 min, giving a Average Single point. The RS3 base logs were active during the collection period and where used as the Observation and Path for the Stop & Go processing.

The Project was then post processed (Stop & Go) in Emlid Studio 1.8 using the UK’s OSNet CORS base RINEX logs for the point collection period. With a bit of tweaking on the settings I could get 7 out of 8 points to FIX. The first point collected always remained in FLOAT.

As I couldn’t get it to fix, I wondered what would happen if I I then switched ES1.8 to Static processing with the same files, but restricted the processing From-To time span to a few minutes around the period the 1st point was collected. Doing this gave a FIX for the first point.

I think your static observation times should be longer than 1 min. Even if you had another RS2/3A onsite, 10 minutes would be optimal.

You didn’t tell me how long your PP baselines are to your control network. Depending on the length of the baselines will determine your observation times.

If your trying to PP baselines that are more than 2 km with your 1 minute observation, it won’t work for PP. You don’t have enough data to PP the longer baselines with.


Sorry Bryan, I’ve just realised what you where asking - Unfortunately the nearest Ordnance Survey CORS base (8km) is permanently offline due to problems with the site owner, so the distance to the next nearest one used is 38km.

The time on each station was a minute as i was breaking down the setup. I’d taken longer readings at setup, but got mixed results for those too. Iirc, they were 2mins per point, with a double measurement taken consecutively (in different projects & crs’).

Still there’s not enough data for a 38km baseline, minimum time per station ought to be at least 1 hr. Is there not a closer CORS near the site ?

If you have two RS2/3 receivers, use one as base on the fix point you can come back to (drilled hole in concrete sidewalk, drive a NO5 rebar flush with ground and have a punch mark on it; etc.).

Start up the base with raw logging u-blox and rinex format, then start collecting your CGP’s with the other receiver at a minimum observation time if 10 min if your
base is less than <2km.

Once you have the data for base and rover submit base data for reduction of your web software in your region, then once you have the true coords of the base, process all observed baseline data from the base to rovers in Emlid Studio with the true base coords. Viola ! You’ll have all your coords in one system… Your might need them one day for another project !



Thanks for the suggestions. Unfortunately, it’s simply not possible to utilise some of what you’ve suggested due to time and site constraints.

  • I’d love to have more, but I only have a single RS3 available.
  • No closer CORS are available until the Ordnance Survey can build a replacement station.
  • This site is a Historic Site is & is highly protected, so it’s illegal to stick anything in the ground - temporary or permanent - in case it damages buried artifacts or structures. Many of the other sites I’ll be visiting are also protected. To install a survey marker would probably take months of negotiations with Gov bodies, and permission would probably not be given as I’m not part of their organisations.
  • The points are GCP’s for drone mapping & modelling missions, and an hour on each is not feasible. In this case I could have managed it with 6 GCP’s, but if running a larger area there may be up to 15-20 gcps. It would also tie up the RS3 so it couldn’t provide any local NTRIP service to the survey drone.

I’d wondered about using multiple baselines/CORS (all around 24-60km), but I don’t have access to that level of software at present either.

Guess I’m stuck :frowning: (and/or need to get another RS2+/3 (for local Base) or RX (as a rover)

1 Like

You could talk to other surveyors in the area, maybe they would setup a base at their office or they might have their own ntrip service. If I was there, I would help by maybe setting a base off site ( no one to disturb it).

The key to locating GCP’s, are short baselines, then your observation times would be considerably less. If you had <2 km baselines , 10-15 minutes per point would guarantee excellent accuracy if static processing. Even with local RTK radio/ntrip your observation times could be 5 minutes (that’s also logging data if needed for PP).

We do this on our boundary surveys using both Emlid’s and Javad equipment , we always have 2-3 c m horizontal/vertical accuracies. Sometime when I have time, I also PP the same points just to verify the field data. Accuracies are always matching 1-2 cm .

Maybe this will give you some ideas, I wish I could be there to help you.

1 Like

Thanks for the ideas from both of you.

I really wish the RTK2Go casters were useable Timd, unfortunately they’ve already proved themselves unreliable.

Bryan, it does rather sound like I’m going to need to bring in another Emlid GNSS so I’ve both a Base+Rover. At least then the GCP’s would be in the same (locally) relative frame of reference as the Drone data. I’d been hoping to just be able to utilise a single RS3 to firstly get the GCP locations and then set it up as a Base for local NTRIP to the RTK drone, but it’s just not working out well that way at the minute.

Life would be so simple if there was a reliable CORS network or a cell access for an NTRIP service!


How did the fixed coordinates compare between the two solution techniques?

Hi Geochad,

The Stop & Go processing gave the 1st GCP as:

Name Longitude Latitude Ellipsoidal height Origin Easting RMS Northing RMS Elevation RMS Lateral RMS Antenna height Antenna height units Solution status Averaging start Averaging end Samples PDOP CS name
GCP 1 -2.33432436 54.78612097 539.911 Global 0.028 0.077 0.207 0.082 1.934 m FLOAT 2024-05-01 16:04:26.0 UTC+01:00 2024-05-01 16:05:26.0 UTC+01:00 301 1.1 Global CS

A couple of runs with the Static Processing gave it as (depending on SNR/Azimuth) settings:

Try # longitutde (deg) latitude (deg) height (m) Q ns sdn(m) sne(m) sdu(m) sdne(m) sdeu(m) sdun(m) age(s) ratio
1 -2.334332820 54.786129051 539.8036 1 12 0.0007 0.0004 0.0011 -0.0003 0.0001 0.0003 -1.8 3.9
2 -2.334349483 54.786192034 539.0780 1 12 0.0006 0.0004 0.0010 -0.0003 0.0001 0.0003 -14.4 3.3

You have three different coordinates there, the two closest are still different from each other by by more than 0.1 meters… that’s too much to have confidence in any of these results. I would not rely on any of it and re-observed the station for longer.