Nate's thread on triangulation led to a mention of some older Locus L1 equipment. It got me thinking. I've read that longer static observation times lead to better, more accurate results. The trade off of course, is the commercial cost of long occupations. But if cost were no object and one left such equipment up for a long time (days to weeks say), and repeated that multiple times, accumulating months of observations, do the results just keep getting better and better, or is there point of diminishing returns?
And how good is good? If one sets up say a 1000' base line, or a triangle of similar size and leaves the equipment up for a long time, what kind of standard errors could one expect for the positions and elevations, and resulting azimuths between the stations? Just curious.
And finally, does post processing with software, or via CORS eliminate the need to subsequently adjust such observations in Star*net?
There are a lot of factors on how well the averages converge, such as whether the receivers process L1 only or also L2 carrier and P code, GPS, GLONASS, etc., how many satellites and where in the sky, and how far you are from the base or CORS. Simultaneous observations on points 1000 ft apart will be much better than separate sessions with base or CORS tens of miles away.
I'm reasonably sure the ultimate limit is essentially as good as your centering errors, but that is going to take a lot more observation time than most people will invest. My impression is that the times people often talk about on this forum are to get ~1-2 cm std error which would be ~0.1 or 0.2 ft at 95%, with longer and more accurate sessions for important control. They don't always specify in the posts.
What comes out of the processing are vectors from the reference stations, or a position. These have statistical errors as any measurement must have. If the errors are significant to your work and you have other information (multiple sessions or also total station measurements), there is benefit in processing everything you have together in LS while specifying appropriate standard errors.
I've been playing with an antique Trimble 4000sst receiver that does L1 and sort of does L2. In open sky with reasonable satellite constellation, I hope to get 3 cm/sqrt(hours) or 0.1 ft/sqrt(hours) standard error. Multipath throws those numbers out the window. Those numbers are a lot poorer than modern equipment that may achieve that in several minutes instead of several hours. I process using OPUS-static, and totally disregard their "horizontal accuracy" numbers because they are so unrealistic. I can observe the same point several times and get an rms change of a few cm but reports of a few mm "accuracy". I don't understand what their report is ignoring.
I'll get out of the way now and let the experts take over.
OPUS static reports "peak to peak errors". Take a look at the about OPUS page for more detail.
Yes, there are the pk-pk numbers which are the range of values in each dimension derived from the 3 CORS used.
I was referring to the "horizontal accuracy" number in the extended report.
I was told by Dave Doyle in 2011 that a CORS needs about 2.5 years of observations to obtain an accurate velocity. I have seen CORS less than a year old with velocities, so I am not sure if they hammered that time down.
So if you go for too long, then you will have issues with the point moving by several mm.
spledeus, post: 362535, member: 3579 wrote: I was told by Dave Doyle in 2011 that a CORS needs about 2.5 years of observations to obtain an accurate velocity. I have seen CORS less than a year old with velocities, so I am not sure if they hammered that time down.
So if you go for too long, then you will have issues with the point moving by several mm.
Spledeus,
If you look closely at the Coordinate/Velocity Sheet, it will tell you whether the velocity is computed by HTDP, or computed based on observational data. Even the velocity estimates on CORS with MANY years of data, are subject to "unmodeled" movement relative to the computed velocity. The velocity is also shown/computed as a linear velocity, so annual/semi-annual variations WILL show up in the Short Term Plots (Time Series) as "apparent" trends. These variations show up nicely in the Long Term Time Series (plots), along with discontinuities of various types.
I cherry pick the CORS that I use with an eye toward CORS that have similar annual/semi-annual behavior, this usually reduces the Peak-Peak variations returned by OPUS.
Loyal
There is also quantization error in the receiver. I recall UNAVCO doing some testing on this many years ago. It was significant in some receivers at the time.
By the way if you think OPUS is optimistic, take a look at the output from NASA-APPS or CSRS-PPP.
It all depends on baseline length. You can try downloading a few days worth of RINEX files, discarding L2 data, then processing one day, two days, etc. in your favorite package. If baseline is of medium length, ionospheric will be the main error source. If baseline is short, multipath is likely the noise bottleneck. Velocity won't matter unless you're processing really long baselines, for tectonics to become different across base and user locations.
-FGN.
You could also buy this fancy high end PP software (about $10,000 I believe),
Artie Kay, post: 362776, member: 3428 wrote: (about $10,000 I believe)
Closer to $25k for a single workstation license.
Quite right Jim, I should have read the order form.
That's Switzerland for you, 500 years of peace and prosperity and they gave the world the cuckoo clock - and gps software that no ordinary mortal can afford! To be fair they did give us the Wild T2 as well.
rfc, post: 362514, member: 8882 wrote: Nate's thread on triangulation led to a mention of some older Locus L1 equipment. It got me thinking. I've read that longer static observation times lead to better, more accurate results. The trade off of course, is the commercial cost of long occupations. But if cost were no object and one left such equipment up for a long time (days to weeks say), and repeated that multiple times, accumulating months of observations, do the results just keep getting better and better, or is there point of diminishing returns?
And how good is good? If one sets up say a 1000' base line, or a triangle of similar size and leaves the equipment up for a long time, what kind of standard errors could one expect for the positions and elevations, and resulting azimuths between the stations? Just curious.
And finally, does post processing with software, or via CORS eliminate the need to subsequently adjust such observations in Star*net?
My longest observation to date, is 36 hrs. It was an L1 observation, with some of these Locus units. It was a section corner. All I could get from the software was a "Float" Solution (Probably too much bad data, mixed with good) and, I later went with Total station, and control stations, and shot it in, to confirm. I had it within 0.01'! So, on a pragmatic level, I'd say that a 24 hr observation is going to give a surveyor all he wants, for general surveying. It gives him ONE revolution of the satellites. On a more extreme level, he could say that one 24 hr observation, every 3 months for a year, would yield a more significant look at the data. This would provide completely new satellite trajectories, or paths through the sky. I do NOT know how much TIME is needed, to significantly change the satellite trajectories. But, I'm sure 4 month would give you alot! Maybe somebody else could tell us.
If you have nice and clear points, you should acquire +- 0.025' accuracy, over 2-3 miles, within 2 hrs, most of the time. (It's been a while, since I used L1 static) and this may have changed, as there are more sats up now.
But, that's "Good 'nuff" fer this ole boy!
Jim Frame, post: 362783, member: 10 wrote: Closer to $25k for a single workstation license.
GAMIT (from MIT I believe) is about the same price ($25k).
On the other hand, PAGES_NT (from the NGS), is FREE!
Just say'n...
Loyal
Loyal, post: 362871, member: 228 wrote: GAMIT (from MIT I believe)
Indeed: GPS Analysis at MIT
I don't believe opus will process L1.
It is not unusual for me to have 6hr to 10hr occupations on control points when I am doing L1 static.
When I examine the logs, there are times thru the day that as the constellation changes and the degree of interference grows and fades as the satellites come and go thru the sky.
When I have to keep my rover on a setup for a long time, the same thing happens, yet the receiver has to collect enough good date for good results.
For static, I've found, the more Coors info you download thru the ftp servers from known sites for the times your receivers are gathering information, the better the results process in GNSS Solutions.
😉
Locus L1 only have 8 channels and is limited in searching for satellites. Newer L1 only can be had for the same price that have up to 12 channels. In general a receiver peaks out and need to open channels for satellite searching, so a Locus to Locus solution could have only 6 satellites each and only 5 in common. Long occupation L1 to L1 solutions at under a few miles are as good or better than L2 solutions. You can get way with surveying with only 1 L2 receiver but if you are going to use L1 only you want 3 or 4.
Paul in PA
Back on the day when all receivers were L1, all measurements were relative. dX dY dZ mark to mark. At a 1000', using a pair of receivers, long obs (an hour) could easily be 1:50,000. But that's using a baseline processor, and a LS bundle adjustment like graphnav.
In baseline processors, L1/L2, short distances like a mile or 2, it's essentially an L1 solution. L2 is used for atmospheric modeling and L1 integer determination.
Bill93, post: 362518, member: 87 wrote: I've been playing with an antique Trimble 4000sst receiver that does L1 and sort of does L2.
As inexpensive as 4000ssi receivers have gotten, I'm surprised you haven't upgraded. I've bought several units in perfectly functional condition in the last year for about $300 or less each. A good geodetic-grade L1/L2 antenna isn't much more.
Take a look at the JPL site here: http://sideshow.jpl.nasa.gov/post/series.html
There is a link on this page above the map to "Methods" describing the process.
