When I do want to post process manually, I do similar to A Harris.
If I use the published NGS CORS stations, I would be looking at 40 miles, 60 miles, and 80 miles as the closest three points.
When using data from the Kentucky Transportation site, I can get data for a couple of as yet published to NGS sites that are 18 miles, 40 miles, and 40 miles.
There is no significant difference in the geometry of either set of points.
I then process in Topcon Tools.
My use for this is only to get my data very close to being on the Kentucky South Zone state plane coordinate system so that my projects more easily drop right into my office GIS. I do not recall the last time I had a request from a client to be on any particular coordinate system.
> The reason that I ask, is because I recently received some Static GPS data that was computed by someone who had NO CLUE about how this SHOULD be done.
Having read many of your post on processing GPS data and having been fortunate enough as to have you review some data before, I know that you are very well versed on the subject.
What would be your suggestion for the best practices to post process manually and what would be an example of some of the things that the person in the above quote did that they should not have done?
Jon
Okay...well here's my “short list:”
1. Vet the CORS sites that I want to use. This requires a close look at BOTH the Short-Term and Long-Term Time series.
If the Short-Term Times Series looks OKAY (less than ~5mm NEU), then that tells me that the IGS08 coordinate AND VELOCITY estimates are pretty good, that nothing weird has happened recently (earthquake, equipment change, etc), and is also a quick check for recent “data gaps” or behavior issues.
The Long-Term Time Series (complete history of the NGS data set through GPS Week 1631, April 2011), gives me a feel for the annual and semi-annual variations, as well as a good indication the overall behavior (stability) of the site. It also alerts me to any discontinuities that I may need to deal with (usually applies only to OLDER data sets). I don't generally need to perform this step, because I pretty much KNOW the history of the CORS in my area.
2a. Download the CORS Coordinate data (see [partial] example below), and solve for the “day of observation” IGS08 position of each CORS that I want to use.
2b.I will usually check the latest cors_08.bin file (last update 12/20/2012) and verify coordinate and velocity estimates on all selected CORS sites (in my experience a waste of time, but I would hate to miss something). In fact, I suspect that these two files are probably inter-related in the NGSIDB. Lately I have been skipping step 2a, and just getting my coordinate & velocity data from the cors_08.bin file)
3. Download the best available IGS Orbit data (igb08 RAPID or FINAL).
4. Make sure I have the LATEST igs08.atx file (currently igs08_1719.atx updated 12/19/2012), and that my software is using the RIGHT poop.
5. Once that I'm satisfied that I have everything loaded up properly (HIs, Antenna Models [SV & CORS], Coordinate estimates, etc), I pull the trigger, and see what happens.
6. Assuming everything turns out as expected (usually does), I proceed on to COLUMBUS for adjustment (in IGS08 @ epoch of observation).
7. Once that turns out satisfactorily (sometimes requires repeating steps 5 and/or 6 a time or two), I then use the LATEST HTDP (currently 3.2.3) to get from IGS08_2012.xxxx to NAD83(2011) 2010.0000.
To tell you the truth, I haven't done too much of this the last couple of years. The Static Data that I have been processing lately (nearly all of it), has been limited to singular (RTK_Base Station) occupations (8-12 hours each), so OPUS_S has been my weapon of choice. I still vet the CORS, but get the “day of observation” igs08 coordinate estimates, and baseline vector data (w/ covariance matrix) out of the extended output report. This then goes into COLUMBUS, and on to HTDP, GEOID12a, etc. Sometimes I'll combine several OPUS_solutions (additional CORS sites), sometimes not.
As far as what I have seen done “wrong” goes:
Mixing NAD83 coordinates with WGS84/IGS08 orbits (vectors).
Mixing “nominal” antenna calibrations with NGS/IGS calibrations.
Using CRAPPY coordinate estimates (see time series above).
Ignoring velocity issues (where there ARE SOME).
These “errors” can be either trivial or nontrivial, depending on where you are, the length of your baselines, and of course, your expectations to start with.
Relative differential movement of the CORS (even in NAD83), can be a nontrivial consideration even here in the Eastern Great Basin. Playing the whole game (as OPUS does) mitigates this (and other) issue(s) about as well as can be.
Obviously selecting 3 CORS surrounding your receiver and using the NAD83 coordinate estimates, isn't going to return very good results IF those three CORS are moving in DIFFERENT DIRECTIONS relative to NAD83.
Remember, your baseline processor computes the dX,dY,dZ between the CORS and your receiver as of TODAY (or whenever you were there), NOT what it might have been several years ago.
Flame on
Loyal
OOPS...forgot the "example"
***IGS 08***
RED BUTTE (RBUT), UTAH
Created on 31Aug2011 at 09:29:54.
_____________________________________________________________________________
| |
| Antenna Reference Point(ARP): RED BUTTE CORS ARP |
| ------------------------------------------------ |
| PID = AF9633 |
| |
| |
| IGS08 POSITION (EPOCH 2005.0) |
| Computed in Aug 2011 using data through gpswk 1631. |
| X = -1797278.855 m latitude = 40 46 51.82726 N |
| Y = -4491525.894 m longitude = 111 48 31.53784 W |
| Z = 4145132.598 m ellipsoid height = 1667.763 m |
| |
| IGS08 VELOCITY |
| Computed in Aug 2011 using data through gpswk 1631. |
| VX = -0.0157 m/yr northward = -0.0080 m/yr |
| VY = 0.0009 m/yr eastward = -0.0149 m/yr |
| VZ = -0.0063 m/yr upward = -0.0003 m/yr |
Loyal, partial hijack
> Okay...well here's my “short list:”
>
> 1. Vet the CORS sites that I want to use. This requires a close look at BOTH the Short-Term and Long-Term Time series.
>
> If the Short-Term Times Series looks OKAY (less than ~5mm NEU), then that tells me that the IGS08 coordinate AND VELOCITY estimates are pretty good, that nothing weird has happened recently (earthquake, equipment change, etc), and is also a quick check for recent “data gaps” or behavior issues.
>
> The Long-Term Time Series (complete history of the NGS data set through GPS Week 1631, April 2011), gives me a feel for the annual and semi-annual variations, as well as a good indication the overall behavior (stability) of the site. It also alerts me to any discontinuities that I may need to deal with (usually applies only to OLDER data sets). I don't generally need to perform this step, because I pretty much KNOW the history of the CORS in my area.
>
> 2a. Download the CORS Coordinate data (see [partial] example below), and solve for the “day of observation” IGS08 position of each CORS that I want to use.
>
> 2b.I will usually check the latest cors_08.bin file (last update 12/20/2012) and verify coordinate and velocity estimates on all selected CORS sites (in my experience a waste of time, but I would hate to miss something). In fact, I suspect that these two files are probably inter-related in the NGSIDB. Lately I have been skipping step 2a, and just getting my coordinate & velocity data from the cors_08.bin file)
>
> 3. Download the best available IGS Orbit data (igb08 RAPID or FINAL).
>
> 4. Make sure I have the LATEST igs08.atx file (currently igs08_1719.atx updated 12/19/2012), and that my software is using the RIGHT poop.
>
> 5. Once that I'm satisfied that I have everything loaded up properly (HIs, Antenna Models [SV & CORS], Coordinate estimates, etc), I pull the trigger, and see what happens.
>
> 6. Assuming everything turns out as expected (usually does), I proceed on to COLUMBUS for adjustment (in IGS08 @ epoch of observation).
>
> 7. Once that turns out satisfactorily (sometimes requires repeating steps 5 and/or 6 a time or two), I then use the LATEST HTDP (currently 3.2.3) to get from IGS08_2012.xxxx to NAD83(2011) 2010.0000.
>
> To tell you the truth, I haven't done too much of this the last couple of years. The Static Data that I have been processing lately (nearly all of it), has been limited to singular (RTK_Base Station) occupations (8-12 hours each), so OPUS_S has been my weapon of choice. I still vet the CORS, but get the “day of observation” igs08 coordinate estimates, and baseline vector data (w/ covariance matrix) out of the extended output report. This then goes into COLUMBUS, and on to HTDP, GEOID12a, etc. Sometimes I'll combine several OPUS_solutions (additional CORS sites), sometimes not.
>
> As far as what I have seen done “wrong” goes:
>
> Mixing NAD83 coordinates with WGS84/IGS08 orbits (vectors).
> Mixing “nominal” antenna calibrations with NGS/IGS calibrations.
> Using CRAPPY coordinate estimates (see time series above).
> Ignoring velocity issues (where there ARE SOME).
>
> These “errors” can be either trivial or nontrivial, depending on where you are, the length of your baselines, and of course, your expectations to start with.
>
> Relative differential movement of the CORS (even in NAD83), can be a nontrivial consideration even here in the Eastern Great Basin. Playing the whole game (as OPUS does) mitigates this (and other) issue(s) about as well as can be.
>
> Obviously selecting 3 CORS surrounding your receiver and using the NAD83 coordinate estimates, isn't going to return very good results IF those three CORS are moving in DIFFERENT DIRECTIONS relative to NAD83.
>
> Remember, your baseline processor computes the dX,dY,dZ between the CORS and your receiver as of TODAY (or whenever you were there), NOT what it might have been several years ago.
>
> Flame on
> Loyal
>
ok, now you got me thinking. i suppose the next thing i need to look in to is how much our local stations are moving. this is something we have not done in the past.
we 'upgraded' our hardware and software last month to a real time network.
my disagreement with a coworker about this is as follows; coworker 'the real time network will precludes the need for post processing, as the vectors are good enough to use outright'. my opinion 'the rtn is nice, but since we only get a single vector to a single mark, the coordinate transformation is inferior/wrong, as it is only a product of holding an x, a y, and a z (only three values). not enough, as a coordinate transformation in 3d (gps) should use a MINIMUM of seven values. we need dx,dy,dz,scale,rx,ry,and rz, as i understand it.
since we have two static receivers and this new rtn rover pole, i believe we should use the static receivers along with the pole. the rtn receiver should be set to record a KINEMATIC track. this gives us the advantage of post processing all three receivers with CORS, etc. coworker believes the static receivers are no longer necessary. seems a fundamental mis understanding to me.
i HAVE done some testing of the vector quality of the rtn vectors versus post processed CORS vectors. so far, ALL of the CORS vectors have been superior in quality over the rtn. what i am looking at/for is the v-cv matrices for this comparison. there might be other parameters i should consider as well, but right now i am not sure what else to look at.
please weigh in on this. rant off, continue flaming
I used TBC to bring data in and verify OPUS solutions and learn PP in TBC. That said, OPUS is REALLY handy and I don't do it much. However, those rare moments where OPUS is down, then I do it and roll on. I always verify with an OPUS solution after the fact.
The antenna's are set up in the software so that I don't worry about. Trimble software and hardware.
Loyal, partial hijack
I have made this rant before: In my book, the "R" in RTK stands for recon.
If you abandon the post-processing for the RTK network, the only redundancy you have
is repeat RTK shots under a different constellation, and you can never truly remove all the correlation.
The RTK network is right enough 80-95% of the time. This makes it hard to convince anyone of the need for a separate redundant check. "Diesel's burnin'! We can't waste time on that egghead crap!"
If you work for a big outfit that has deep pocket insurance, go for it. The time savings outweigh the potential risk. If you wind up jackhammering out five jobs in a hundred, you hopefully made enough on the other 95 jobs to pay the E&O deductable and the new increased premium.
Not so for a small shop or a solo operator.
Loyal, partial hijack
Eddie;
As far as the 'inner workings' (behind the curtain) of RTN(s) go, I'm NOT the guy to ask. I “know” a little bit about it, but not much. Gavin is the expert, and maybe he will chime in, and set the record straight. It is my understanding, that RTN(s) use the igb08 Ultra-Rapid Ephemeris, so exactly how that gets transformed to NAD83(2011) Epoch 2010.0000 is a question for Gavin. In fact, I'm not really sure that ALL RTN(s) are actually aligned to NAD83(2011) Epoch 2010.0000 at this point.
To transform [say] an Epoch 2012.1234 IGS08 Coordinate, to a NAD83(2011) Coordinate (also @ 2012.1234) requires a 14 parameter transformation.
See:
http://geodesy.noaa.gov/CORS/coords.shtml
To get from there (2012.1234) to NAD83(2011) Epoch 2010.0000, requires the use of a velocity model (HTDP v3.2.3). East of the Rockies, this isn't [usually] too big a move (there are of course exceptions I suppose).
In response to you question about field procedures... I dunno. I would suggest running some tests, and taking a hard look at the results. I would be a little surprised if the RTN values don't agree [very well] with OPUS derived values (but you won't really KNOW until you CHECK). I have had only limited experience with RTN derived values, and I was not particularly impressed. BUT, it was limited to a particular RTN, AND the data was collected by OTHERS.
I have VERY little experience with kinematic processing, it is just not something that I have ever had a reason to play with. I would think that your “stops” on a given station, would be of insufficient duration to process into the CORS, and yet be fine for RTK, RTN, or post-processed-kinematic solutions. Depending on how you organized, computed, and constrained a hybrid “stop-n-go” + RTN + OPUS “network,” I suspect that the results would be [at the very least] interesting.
I don't know how much help this is, you are drifting quite a ways out of my comfort zone.
Loyal
Kris
"The antenna's are set up in the software so that I don't worry about. Trimble software and hardware."
Welllll... That would NOT impart much of a warm and fuzzy to me.
I would suggest CHECKING the Antenna Calibration Models that TBC is USING. The default may be "Trimble Nominal," which is NOT what you want when playing in the NAD83(2011) sand box. Be SURE that it is set to IGS or NGS ABSOLUTE.
Hint: If ALL of the R8 antennas (receivers) indicate an ARP-to-L1pc offset of 0.0649 meters, then it is set to "Trimble nominal," which AIN'T what you want.
Loyal
Loyal, partial hijack
> I have made this rant before: In my book, the "R" in RTK stands for recon.
>
> If you abandon the post-processing for the RTK network, the only redundancy you have
> is repeat RTK shots under a different constellation, and you can never truly remove all the correlation.
>
> The RTK network is right enough 80-95% of the time. This makes it hard to convince anyone of the need for a separate redundant check. "Diesel's burnin'! We can't waste time on that egghead crap!"
>
> If you work for a big outfit that has deep pocket insurance, go for it. The time savings outweigh the potential risk. If you wind up jackhammering out five jobs in a hundred, you hopefully made enough on the other 95 jobs to pay the E&O deductable and the new increased premium.
>
> Not so for a small shop or a solo operator.
:good: :good:
Loyal, partial hijack
> > Okay...well here's my “short list:”
> >
> > 1. Vet the CORS sites that I want to use. This requires a close look at BOTH the Short-Term and Long-Term Time series.
> >
> > If the Short-Term Times Series looks OKAY (less than ~5mm NEU), then that tells me that the IGS08 coordinate AND VELOCITY estimates are pretty good, that nothing weird has happened recently (earthquake, equipment change, etc), and is also a quick check for recent “data gaps” or behavior issues.
> >
> > The Long-Term Time Series (complete history of the NGS data set through GPS Week 1631, April 2011), gives me a feel for the annual and semi-annual variations, as well as a good indication the overall behavior (stability) of the site. It also alerts me to any discontinuities that I may need to deal with (usually applies only to OLDER data sets). I don't generally need to perform this step, because I pretty much KNOW the history of the CORS in my area.
> >
> > 2a. Download the CORS Coordinate data (see [partial] example below), and solve for the “day of observation” IGS08 position of each CORS that I want to use.
> >
> > 2b.I will usually check the latest cors_08.bin file (last update 12/20/2012) and verify coordinate and velocity estimates on all selected CORS sites (in my experience a waste of time, but I would hate to miss something). In fact, I suspect that these two files are probably inter-related in the NGSIDB. Lately I have been skipping step 2a, and just getting my coordinate & velocity data from the cors_08.bin file)
> >
> > 3. Download the best available IGS Orbit data (igb08 RAPID or FINAL).
> >
> > 4. Make sure I have the LATEST igs08.atx file (currently igs08_1719.atx updated 12/19/2012), and that my software is using the RIGHT poop.
> >
> > 5. Once that I'm satisfied that I have everything loaded up properly (HIs, Antenna Models [SV & CORS], Coordinate estimates, etc), I pull the trigger, and see what happens.
> >
> > 6. Assuming everything turns out as expected (usually does), I proceed on to COLUMBUS for adjustment (in IGS08 @ epoch of observation).
> >
> > 7. Once that turns out satisfactorily (sometimes requires repeating steps 5 and/or 6 a time or two), I then use the LATEST HTDP (currently 3.2.3) to get from IGS08_2012.xxxx to NAD83(2011) 2010.0000.
> >
> > To tell you the truth, I haven't done too much of this the last couple of years. The Static Data that I have been processing lately (nearly all of it), has been limited to singular (RTK_Base Station) occupations (8-12 hours each), so OPUS_S has been my weapon of choice. I still vet the CORS, but get the “day of observation” igs08 coordinate estimates, and baseline vector data (w/ covariance matrix) out of the extended output report. This then goes into COLUMBUS, and on to HTDP, GEOID12a, etc. Sometimes I'll combine several OPUS_solutions (additional CORS sites), sometimes not.
> >
> > As far as what I have seen done “wrong” goes:
> >
> > Mixing NAD83 coordinates with WGS84/IGS08 orbits (vectors).
> > Mixing “nominal” antenna calibrations with NGS/IGS calibrations.
> > Using CRAPPY coordinate estimates (see time series above).
> > Ignoring velocity issues (where there ARE SOME).
> >
> > These “errors” can be either trivial or nontrivial, depending on where you are, the length of your baselines, and of course, your expectations to start with.
> >
> > Relative differential movement of the CORS (even in NAD83), can be a nontrivial consideration even here in the Eastern Great Basin. Playing the whole game (as OPUS does) mitigates this (and other) issue(s) about as well as can be.
> >
> > Obviously selecting 3 CORS surrounding your receiver and using the NAD83 coordinate estimates, isn't going to return very good results IF those three CORS are moving in DIFFERENT DIRECTIONS relative to NAD83.
> >
> > Remember, your baseline processor computes the dX,dY,dZ between the CORS and your receiver as of TODAY (or whenever you were there), NOT what it might have been several years ago.
> >
> > Flame on
> > Loyal
> >
>
>
> ok, now you got me thinking. i suppose the next thing i need to look in to is how much our local stations are moving. this is something we have not done in the past.
>
> we 'upgraded' our hardware and software last month to a real time network.
>
> my disagreement with a coworker about this is as follows; coworker 'the real time network will precludes the need for post processing, as the vectors are good enough to use outright'. my opinion 'the rtn is nice, but since we only get a single vector to a single mark, the coordinate transformation is inferior/wrong, as it is only a product of holding an x, a y, and a z (only three values). not enough, as a coordinate transformation in 3d (gps) should use a MINIMUM of seven values. we need dx,dy,dz,scale,rx,ry,and rz, as i understand it.
>
> since we have two static receivers and this new rtn rover pole, i believe we should use the static receivers along with the pole. the rtn receiver should be set to record a KINEMATIC track. this gives us the advantage of post processing all three receivers with CORS, etc. coworker believes the static receivers are no longer necessary. seems a fundamental mis understanding to me.
>
> i HAVE done some testing of the vector quality of the rtn vectors versus post processed CORS vectors. so far, ALL of the CORS vectors have been superior in quality over the rtn. what i am looking at/for is the v-cv matrices for this comparison. there might be other parameters i should consider as well, but right now i am not sure what else to look at.
>
> please weigh in on this. rant off, continue flaming
Why bother investing in RTN, if you need to back it up with static? Defeats the purpose. I responded to Half Bubbles post in agreement, but now that I read this I have to disagree. What are you using it for that would require all these redundant sub operations?
Ralph
Loyal, partial hijack
>
> Why bother investing in RTN, if you need to back it up with static? Defeats the purpose. I responded to Half Bubbles post in agreement, but now that I read this I have to disagree. What are you using it for that would require all these redundant sub operations?
>
> Ralph
ralph,
i am not sure what you disagree with. clarify.
the tone of my posting is rtn for control and/or boundary
how much work are you comfortable with if it is not redundant? do you measure important marks only once?
my point is that work needs to be recordable and defensible. rtn, for the most part, is not recorded by the operator. the observables are not saved or stored. i would suppose that to be the case for most operators. the alternative would be to record the raw data with the computed vectors. if need be, the data can be post processed.
our particular rtn contract only allows a vector from either the nearest or best available reference station. one vector for one mark. yes, you can take more measurements, but is that the type of redundancy i want to see? no, that is simply meaned measurements from a single control station.
Loyal, partial hijack
>
> our particular rtn contract only allows a vector from either the nearest or best available reference station. one vector for one mark. yes, you can take more measurements, but is that the type of redundancy i want to see? no, that is simply meaned measurements from a single control station.
Ok now I understand. My bad
Here's my experience:
I just finished a project which was over water, shore to shore was about 6000' on average. I started the project with a Trimble R8 receiver on NYSNET (NYSDOT Network). I created a baseline using a couple of USACE monuments and established 8 points (3 minute occupation time). The following week I received my Carlson Rover (BTW I was the first one in the Country to have a Super G setup) re-occupied all 8 points with the Carlson. It was the first time I had done RTN and I didn't believe what I was seeing, so I proceeded to setup my total station and created a braced network in which one of the legs was over 8000'.
The largest discrepancy I had between the three (Trimble R8, Carlson Rover and Trimble 5603) was .03'. Either I'm the luckiest man alive or this thing really works. So for me there was some repeat-ability. I imagine that the more you work with it, the more you'll establish your own checks and tests and the confidence you'll gain. But I really believe that having a static setup in addition to RTN is defeating the purpose.
Ralph
Loyal, partial hijack
> If all of our users were as conscientious as you three we'd have a lot less headaches.
>
> I reccomend throwing some static in becuase it often takes litle or no extra effort (leave it running on a few points while you are puttering about the site). Does no harm to have some backup if needed (and it usually does not). How many redundant shots, and shots on what are essentials. It doesn't have to turn into something oppressive or time consuming. A terrestrial shot across a site is a nice touch, and it pays to take a shots along courses less than 150' (again, mostly uneccesary but does no harm).
>
> Suspect the positions of the CORS in a network? No problem, you can download all of the CORS data you want and run countless hours of PP sessions if need be. But like you said, when someone gets some time with it under thier belt they get an idea of how best ot use it, the limitations, and the potentials.
>
> The folks that shoot and run without any forethought or afterthought are like the fly-tie bandits with a total station; people that get so used to tight instrumentation that they stop checking. Both are bad news.
:good: :good:
Loyal, partial hijack
I haven't done static (except for redneck science experiments) for a couple of years. I use the RTN now mostly.
To go along with the previous rant:
A total station can tell you how good something is, but never where it is.
A GPS can tell you where something is, but never really how good (without post-processing, anyway)
When the data collector tells you you have a fix and a small error ellipse, THAT's ONLY A PREDICTION! You won't know anything about it until you post process it, either by tieing it with terrestrial measurements, by comparing to static, or at the very least, by comparing with an RTK shot later in the day. (That's "post", in a simple way.)
With static GPS you're getting redundancy over time in one place. So you can occupy one station for 4 or 8 hours and have some redundancy and solve out the multipath and such. To do the same with RTK, you'd have to come back at a different time / under a different constellation, say, twice more at 4 hour intervals. Both approaches seem like a waste of time when you could be doing something else.
With enough RTK shots at different occupied stations, and with those stations tied together with terrestrial measurements, the subtle part is this: It's the network of all those measurements that is the redundancy. You can take a gnats-hindquarters swiss watch set of total station measurements and by themselves in least squares in a local coordinate system they are dead on to .01' at 95% confidence.
Try to drop that onto a few RTK shots and into some sort of geospatial datum (state plane, LLH, whatever, and suddenly your tight control network has error ellipses the size of the RTK shots. At first you knew "how good" the network of TS observations was relative to itself, but not "where". You try to add in "where" but with only a couple of RTK shots the confidence in "where" is not so great so now the RTK undertainty is propagated to every station in the TS network. We know that network is tight relative to itself but we are not nearly as sure "where" it is.
You could do more RTK shots at different times of day or you could decide to do static. Either one is a time sink. Keep moving, keep shooting TS data and get a single RTK shot on the occupation point. When you get about a dozen the whole network will start to tighten up in the geolocated sense of "where" that is getting closer to the Swiss watch ideal. It's tight both relative to itself and relative to geolocation. Now you know both "where" it is and "how good" it is and they are both defensible.
So that's the story of how I finally learned to love RTK.
Loyal
Thanks for the outline. No flames from me on that. Seems like a pretty conscientious way to resolve your position. That would seem like a prudent method to do your work if you are required to report on the state plane or provide state plane coordinates to a client.
The reason I asked was that I have attended a number of GPS seminars over the years. While the information presented would not be 'conflicting' with each other, there is often a 'best practice' presented in one way then a slightly different 'best practice' presented by another seminar instructor. So I am always on the lookout for what others in the know would consider to be the "right" way to reduce ones observations.
GOOD stuff Gavin
Keep it coming...
Loyal
Gavin
Sure, send them over when you get a chance.
Loyal
Gavin
Me too !
glad to be your "behind the times" myth-bearer example on the latest in RTK.
A lot of my skepticisms up til now might be based on the peculiarities of the equipment I have been using. *Just* the difference between a 2m pole and an 5.50' antenna height with the Smart Station on a tripod could account for the larger error ellipses I typically see. (Also for a reluctance to get a fixed position, this winds up being more frustrating than the larger error ellipses). This is probably why I have had better success with rapid static (45-90 minutes): resolving multipath with time rather than antenna height.
Lately I am looking at RTK data from the same color GPS and antenna on a 2m pole, and it is usually about twice as good as I have gotten used to with the Smart Station over the years, both in predicted accuracy (a priori on DC) and in the least squares combined with the TS data. Pretty much 1cm x 2cm any time it has a fix.
Great info about the time between RTK observations to reduce correlation being shorter nowadays.