Static Processing in TBC

OPUS Required

Or gather the CORS yourself.

Paul in PA

OPUS Required

Note that the poster is in the UK. I don't think OPUS and/or CORS is going to work for him. But I'm sure that there are European/International equivalents that would.

Averaging autonomous positions at a single base will not produce a survey grade position, no matter how long the occupation. Survey grade GNSS measurements are always the product of vectors between 2 (or more) simultaneously operating receivers.

Government agencies throughout the world have continuously operation stations collecting data on well known points which can often be downloaded for use. Here in the US we call those CORS. There are many on line systems that will use that data and combine it with your data set to return a position for your receiver. The American version is called OPUS.

It's possible that OPUS might work, after a fashion, in the UK. I know that AUSPOS and the Canadian version of OPUS returned positions for Oklahoman bases during the government shutdown a couple of years ago. The NAD83 datum wouldn't be appropriate and I'm not sure that the ITRF datum would match UK needs either.

Using TBC here in the US, it is possible to import data from CORS directly into the program to process static data. If you have publicly available ref station data in the UK, I see no reason why you couldn't do the same. Check out the TBC tutorials and work flow solutions on their facebook page. They are very helpful.

OPUS Required

Thanks I can download reference station data from our national provider - Ordnance Survey.
http://www.ordnancesurvey.co.uk/gps/os-net-rinex-data/

I have done this before and it worked ok. I was thinking that you should be able to process the station on it's own if you have enough data. But I know what you mean, you are always comparing to something.

Thanks again for your help.

What your attempting to do is differentially correct your base's observation data to derive a position relative to other know points. First step is to identify those stations and the adjustment that your seeking to relate to and their proximity and reliability. The second step is after identifying those stations, to download their observation data and use their downloaded data to differentially correct (process in TBC) your own base data, holding the positions of the known locations in the network. You cannot differentially correct data against itself. In the U.S., OPUS is used to differentially correct data through an online NGS utility. I'm certain the U.K. has some equivalent, or at a minimum a network of equivalent 'Continually Operating Reference System', or 'CORS' stations, as here, where you can download their observations and published station values. I've used all kinds of sources for data in the past including USGS crustal deformation stations that are monitoring crustal movement and volcanology since Alaska doesn't have the density of CORS stations of the lower 48. Some times you have to get a little creative. 😉

The rest is fairly straightforward post processing.

I'm a little late to the party here, but...

As has been noted, "processing" a standalone position will never get you much better than a meter. You can send the files to Trimble's RTX PP - http://trimblertx.com/UploadForm.aspx - and get a cm level solution. I would think that with that much data you'd have a pretty good idea of the precision. I would start there.

I'm sure that your Ordnance Survey CORS data can be retrieved using the Internet Download feature in TBC. Ultimately with data sets that long I'd bring in data from at least four CORS stations, along with the final IGS orbits, and process and adjust it myself in TBC. If you have any questions about how to do that feel free to contact me at the e-mail in my profile.

Thanks Lee, I can download the rapid and precise orbits using the "internet download" feature - very handy.

Unfortunately it's not set up for reference station data from the UK. There is nothing there to speak there.

Rinex data is quite easy to download from OSNET though.
I have managed to process the baselines and adjust the network.

I am currently adding more observations as time allows in parallel with the topo control stations - also co-ordinated using the same method. I have a 27mm discrepancy in ellipsoid height at the moment based on a 4 hour observation. I will do some further investigation.