GNSS Solution. Compute VRS with baseline up to 1000km and usage of 15min Rapid Static

New video out on how to compute VRS from stations up 1000km away with GNSS solution
Special thanks to @r.pazus for tips and info about rapid static computation and great knowledg about processing with long baseline and processing in general.

To compute vrs from long baseline is excellent in areas with poor access to VRS service or baseline longer for PPK to handle.
With base and rover out in the field, you dont need known point or live RTK feed in any way.
Start your base and log raw data from average position. Your rover can work RTK from base or just log raw data. Keep a minimum of 15min raw data on base for rapid static to work, rover can have less and work as PPK instead.
When done. Download obs and nav data from gnss service, e.g https://igs.bkg.bund.de/
Then process raw basedata, compute VRS and generate absolute coordinates for base and rover.
Accuracy is sub cm, but depend on distance from baseline lenght.

From my example i generate VRS 7,2m away from base with baseline refrence 140-480km and an offset from known point about 5,2cm. Can`t do that with PPP and L1!!

PS! verify VRS with NRCAN PPP or known point

Its an old software but still kick some serious coordinates :wink:

EDIT: After watching the video i noticed now i filled in the delta height in the wrong colum in RTKconv.
This would throw my offset of with 65mm… well well. Not going to make a new video for that :roll_eyes:

Edit: I updated this with a video describing rapid static

7 Likes

Hi @TB_RTK,

Nice info. Did you try to watch differences between VRS under gnss solutions and averaging position from these 3 bases with ppk rtklib process ?

No i haven`t. Do you know of good way to process or handle multiple refrencestation with rtklib?

Thank you for taking the time to put this together.
Dave.

No just thinking about computing 3 solutions then averaging these 3 solutions …

Nah, im not getting fix with baseline above 300km from this survey ( To short time) .Two out of three stations drops out of the average in PPK. VRS is way more accurate in this case i would say

Did you look into how hard it would be to setup the software for auto-download of the files?

Tried few times but its so easy to just download manully i just gave up.
Gonna try again. 2 sec

Got the download function to work. Had the stations letters uppercase and changed them to uncapitalized.
Its now working to download from gnss solution
clip2clip1

Gotta try that then! Does it have to be per station all this?

do you mean your stations? if they are not there, then you need to add them one by one

That’s what I feared…
have you tried highrate data, or does your 3 stations not provide this?

These daily observations is produced after a day or so. So high rate is really not necessary, unless your are in a hurry?
Where are you located? country is close enough :yum:

Also… to generate vrs you need more then 15min observation. Need hours to be accurate enough

With RTKPost I have seen that sometimes 30 sec sampling rate screwed with the fix. Reverting to multiple 1 hz 30 min files did the trick (but have also seen the opposite)…
I’m in Denmark, so generally have good conditions for VRS, as I would be inside a CORS triangle.

Using the automatic downloader, how did you fix the iono error ? Did you setup these as well ?
I get stuck here, as it tries to connect to some non-responding server in Switzerland.
I can’t see any reference to that server in both of the service setups (ref and emph).

Its due to the file type you are trying to load into GNSS.
Do you have a link to a station this file is wanted?

Euref - SMID, BUDP and SULD.
(downloading the 24h 30 sec int 18d files, along with the 18n files)

These two? Did you manually download

Yep, those two, i.e.
Didn’t download manually. I set up the software to automatically grab the 18d and 18n, which works, but then iono-thing start going on.
Can you reproduce if you do automatic download?