PPK Settings within Emlid Studio

jake_g · February 25, 2025, 6:28pm

Hi all,
Would anyone be willing to share their settings used in Emlid Studio to;

Process a logged single measured point (Emlid RS3) using OS (UK) rinex data

Then settings used during the ‘Stop and go’ processing once the step previous has been completed based on 2 RS3s (rover and base)

I thought I had it cracked, however I noticed a horizontal difference today when checking against a control point on a job. I then rechecked my processed base point and noticed that it was nearly 200mm off in position to my VRS measured point, and the Control station XYZ (control station and VRS tied in within 20mm). This processed base point showed a fix when processed.

I also can’t get my head around why when processing against OS rinex and a local base on site, fix only accounts for a small portion of the log when changing the settings to display all solutions rather than ‘one best’

I then changed some settings like fix and hold etc and my processed XYZ changed again. I’m not sure how I can have faith in what is being produced when you can get different results based on different settings

Thanks!

scottmitchell63 · February 25, 2025, 8:54pm

Hi Jake.

What was the baseline length from you to the OS station? Length of your logs etc.

You can change the elevation and SNR masking to exclude poorer data. The defaults are usually fine though.

jake_g · February 25, 2025, 9:01pm

Hey Scott,
The baseline was around 20km in this instance - so not too far
Im tweaking the settings to try and get as close to the VRS measure as possible, however I cant get closer than 80mm in position, but perfect on height.

Logged the point for just under 2 hours

Thanks!

scottmitchell63 · February 25, 2025, 9:06pm

If you look at the skyplot, do you have many cycle slips? All available constellations checked etc?

Is it your VRS point or a supplied one?

jake_g · February 25, 2025, 9:43pm

I dont think so, im not too familiar with what im looking at when analyzing the data but I have attached screenshots

Thanks!

scottmitchell63 · February 25, 2025, 10:04pm

Looks good. No major cycleslips and skytrack is OK. How many satellites does the result say it has used?

Have you tried any other OS stations? What it your coverage like in the area? Other than HOOB it looked pretty stable across the network on the 24th.

jake_g · February 25, 2025, 10:10pm

Around 10-13 maybe?

What I also cant get my head around is why the FIX solution isnt for the entire log and only for a ten minute duration? Unless this is normal?

I have tried another OS Station about 36km away and this also gives a different result, almost a similar error but in the opposite direction

scottmitchell63 · February 26, 2025, 8:07am

It sometimes loads fixes at parts of files due to matching sky view and satellite overlap, but yeah you would expect a spread of fixes throughout.

It might sound stupid but have you got the full data set from the OS? It seems strange that you have 15 minutes of fixes and they then crash at exactly 3pm. You may be missing a file from 3 onwards. Summer time is a UTC +1 issue but just make sure you have all the data. I usually go an hour extra either way to make sure when I search and download.

jake_g · February 26, 2025, 8:51am

Hey Scott,
I have just downloaded the extra hour either side and seem to be getting a 90% fix now which is great! Thanks for that tip

I downloaded both Gaydon & Birmingham OS files and ran them with the same settings.
Even though I am getting a 90% fix on both datasets, the below co ords are produced.

BIAX (Birmingham)
52.12035472°N -1.76138071°E 97.3860m (36.5km away)

GAYD (Gaydon)
52.12035430°N -1.76137868°E 97.4423m (20.9km away)

Difference between both

Settings used for both

scottmitchell63 · February 26, 2025, 10:10am

That’s good you’ve got a fuller fix.

The results from the two will differ as they are including the propagated error for each baseline vector.

You can fix and hold GPS and GLONASS to see if that tightens things up.

What is the average like compared to the VRS point you were looking to match? There are also stations at droitwich and claw to test to see how a circular set of results look.

ElectroNick · February 26, 2025, 11:05am

You could also try setting your elevation mask to around 25-30 - looks like most of the (few) cycle slips are on the lower parts of the Skyview. Also see if excluding the Beidou (untick Beidou satellites and set BDS to OFF). I’ve found including them in the processing sometimes doesn’t help here in the UK for some reason. QZSS can be unchecked too. Add the GLONASS Satellites back in and setting GPS & GLONASS to Fix & Hold should also help.

I’m with Scott on grabbing an extra hour each end from the OSNet too - although I think each of their log files usually covers 90mins from the hour change.

jake_g · February 26, 2025, 11:22am

I have just ran it with 25 elev mask, unticked beidou and set BDS to off, and it has tightened up closer to the VRS point.
Only 72mm difference in position, and 0mm in height!

Maybe this is the best we can get?

Thanks gents

ElectroNick · February 26, 2025, 11:42am

You can try increasing the Elevation Mask again, see if 30 or 35 give you any better result.

inkar.madikyzy · February 26, 2025, 6:35pm

Hi Jake,

I see you’re already investigating this with Scott. Let me jump in.

First, I’d like to make sure I’m on the same page:

You first noticed the discrepancy in the Stop & Go results. Is this offset consistent across all points?
Could you share your Stop & Go logs, CSV file, and the known coordinates of your control points?

I also see that the base position is in question:

The VRS-measured point and control station match within 20mm. Was the base initially measured in FIX using a VRS? And was it set up on a known control station?
Now, you’re doing static processing using OS RINEX files—can you also share those logs?

Thank you! It’d help me piece everything together.