RTK work - normal practice...

I asked a very similar question about a year ago. There is surprisingly little information on the subject. What you choose has to do with your personal comfort level.

Edit: I checked, and it was 1 year and a day ago exactly!

https://surveyorconnect.com/threads/rtk-occupation-times.277356/#post-277356

I log 2 minutes data SurveCE, 10å¡ elevation.
Then repeat that twice more.
Not sure why I don't just log 5 minutes. Just the way I do it - no valid reason.

Also come back to point later if time allows.

I'm referring to cadastral surveys, for marks found, reference stations, control.

The goal posts keep moving, which makes it difficult to say. Over the summer I did quite a bit of testing. But the firmware for my Javad reciever has changed quite a bit so my results are already dated. I think that part of the issue is a statistical question that is beyond my current understanding. If you have a standard deviation of x, how many samples are required to reduce the standard deviation some amount? This is beyond rtk, the question could also be applied to angle measures with total station. How many turns with a five second instrument can produce a one second accuracy? Is it even possible?

To answer your question, my early testing indicates that 240 seconds of data produces results that are about 15% lower SD than 20 seconds of data.

I would recommend that you do an experiment. Set up base and rover at a reasonable distance apart to mimic your normal working conditions. Collect a point on the rover for 10 minutes. Note the current average displayed on the screen at 3 seconds, 10 seconds, 20 seconds, 30, seconds, 60 seconds, 120, 180, 240, 300, 360, 420, 480, 540, and 600. Did the average change over the ten minutes? Was there a point that the average seemed to no longer change? This would mark your point of diminishing returns. If you are in open skies, you've averaged out all of the variability that can be observed over a short period of time. Now the only way to improve precision is to return at a much later time, possibly even days apart to vary atmospheric conditions. This is the best way to answer your own question. Repeat a few times and you're becoming an expert on your own system.

For what it's worth, the 2hz rate is probably not benefiting you much as the rover is using interpolated corrections from the base. Unless you're moving and need the higher rate for kinematic purposes, I'd stick with 1 hz.

Shawn Billings, post: 335225, member: 6521 wrote: For what it's worth, the 2hz rate is probably not benefiting you much as the rover is using interpolated corrections from the base.

The recent Javad release of higher correction rate capability (up to 5 Hz) is accompanied by a statement that no other manufacturer or RTN offers a rate faster than 1 Hz. I wouldn't think that the technology to do this is challenging. If the Javad statement is correct, why hasn't it been done in the past?

Two reasons. The advantage wasn't readily understood and it's a challenge to communications.

Only with common simultaneous base and rover data will rtk fix ambiguities. So if you lose your fix you will not get another fix at least until a new correction is received. The >1hz rtk rates that have existed in receivers for years will not fix any faster than 1hz. The correction data is extrapolated and the rover continues to compute a position at >1hz. With 2hz broadcasting, Javad can fix ambiguities twice as fast because more corrections are coming in. At 5hz, five times faster fixes. In the open, close to the base that might not mean much. In canopy, or over longer distances, the advantages are apparent, particularly with Javad's multiple engine resets.

The throughput of 5hz over uhf heats up the radio and uses a lot more power. Over Internet not a problem (except for data plans, if applicable). Spread spectrum seems to be good for 5hz. For uhf, I believe 2hz is probably the better choice. I don't have any personal knowledge on that however. I've been using 5hz exclusively over Internet tcp.

Jim Frame, post: 335226, member: 10 wrote: The recent Javad release of higher correction rate capability (up to 5 Hz) is accompanied by a statement that no other manufacturer or RTN offers a rate faster than 1 Hz. I wouldn't think that the technology to do this is challenging. If the Javad statement is correct, why hasn't it been done in the past?

I almost certain Topcon's machine guidance GNSS systems operate at 10 hz, and can go up to 100 hz.

https://www.topconpositioning.com/oem-components-technology/gnss-components/b110-receiver-board

This is where the confusion lies. >1hz positioning has existed for years. The rtk processor uses an extrapolated correction to compute the positions. What Javad has done is push more corrections per second. These additional corrections allow for faster fixes. Yesterday under pretty bad canopy, I acquired 23 fixes in 98 seconds. I was receiving 5hz corrections from my base, 30572 feet away. This would have required about 5 x 98 seconds to acquire at 1hz (490 seconds = 8 minutes 10 seconds). I had 23 good single epoch fixes and 4 bad single epoch fixes that were overruled by the 20 good ones. I also shot this point by total station and the coordinates compared sub-centimeter. The total point included over 28 fixes, 353 epochs of data and required about 4.5 minutes. This would not have been possible in this time frame at 1hz base correction output and >1hz positioning would have had very little effect.

I have been testing procedures with RTK for a long time. In the early days I was the button pusher. We tested numerous combinations of measurements and adopted policies based on the estimated errors from the controller. Within a few months I could tell the results were fictitious. It forced me to return to school and bury myself in the books again.
I no longer rely on displayed precision and proprietary quality indicators. Every manufacturer I've tested continues to abuse stats. The idea that every epoch counts as an individual measurement is misleading. The point of diminishing returns is reached rather quickly in a single session with RTK. A more reliable position will be gained with shorter observations under varying circumstances rather than letting it cook RTK. The longer session continue to show you a (false) smaller root of the biased epochs.
We currently run 2 sets of 30 second observations at different times. If a point is tough to get to we cook rapid static. The vectors and conventional data are adjusted together in StarNet. The adjustment isn't to fool myself by moving things millimeters. It's to determine valid error ellipses. Our procedures usually produce a centimeter or a little better in the relative tests.
My point is to suggest testing your vectors as opposed to believing the controller or an undefined report. It will help you develop a more reliable procedure.

Using my Leica 1200 in the open (specifically, not under canopy) I take five shots in a row for control points and the unit averages them. (In my opinion, similar to a carpenter's measure twice and cut once philosophy). I have tested this procedure on a calibrated baseline with excellent results. The purpose of the control points is to give me points I can set up on with my Leica reflectorless to shoot hidden property corners, building corners, etc. I have yet to see a measured difference between control points exceeding 0.025 feet, after several years of doing this. Every now and then I keep track of one hundred of the differences and calculate the average - which is 0.009 feet horizontally (I rarely care about verticals).

I use great care with the rover on a bipod to make sure the rod is vertical, and I know how to avoid situations that will degrade the results. I also set the reflectorless up carefully. And I use a painted brick for the reflectorless backsight, so it is set up exactly over the point.

Positioning rate: 20hz, 5hz is that good?

The GPS I'm buying is 20hz, 5hz. Why is it stating 20hz, 5hz in the specs? What does it mean?

These high update rates have application where the receiver is moving, as with machine control or positioning the camera/lidar in an aircraft. It means little to more traditional uses.

I suspect the real impact of higher rates to be a negative. It's going to be another excuse to use RTK under canopy, next to tin roofing, etc. Bean counters will probably want boundary points collected with 2 seconds of data too...

Higher transmit rates (>1Hz) will proportionately decrease the time required to resolve ambiguities, i.e. time to fix or TTF, compared to 1Hz transmit rates. If it usually takes 10 seconds to get a fix at 1Hz, you'll be able to get a fix in 2 seconds at 5Hz. If, under canopy, it takes 30 seconds to get a fix at 1Hz, you'll be able to get a fix in 6 seconds at 5Hz.

Higher position rates (>1Hz) will have little affect on accuracy and no affect on TTF. Positions are determined from extrapolated correction data. The positions are accurate, but if the fix is lost, it will not be reacquired at least until new corrections are received by the rover. Usually, when you see a rover spec'd at >1Hz it is based on extrapolating correction data. More points per second, but no change in TTF.

If reducing TTF allows you to gather more redundancy on a point (more independent fixes) under canopy in less time, then higher transmit rates will result in better return of investment. Users can work in more places with RTK with increased QA/QC, more quickly. Will the user gather the necessary redundancy? That's up to the user. I sincerely hope so.

My business model does not include bean counters.

Shawn
It all but goes without saying most folks here aren't 'average users'. My comments are directed at those who invest no time in learning what the equipment can and cannot do. Watching one man crews run under canopy to get a shot before the unit loses lock has left me a bit jaded. I can already here the 'now we can tie 4 story building corners with it' comments. Does everyone do this sort of stuff? No, but plenty do.
Rant over, Tom

I am in the camp that believes that if you can obtain fixes much faster under canopy, then you will not be tempted to accept crap. If I can obtain shots which consist of 6 engines reset, and 120 honest epochs every 30 seconds, it is actually more tempting to then collect half a dozen of these measurements, and have unbeatable confidence. Having a base that transmits corrections at 2 or 5 hz is simply an amazing improvement.

BTW...Watching one man crews run under canopy to get a shot before the unit loses lock is not surveying, that sounds simply disgusting!! There is a place for people like that.

It seems to me that under canopy positions with fixed solutions that don't stay fixed very long need to be checked now and then with completely independent measurements like some conventional traversing to the same points to see how the conventional positions compare to the RTK positions. The entire stochastic modeling of GNSS positioning which produces "error statistics about precision" is not all that meaningful as it is never scaled to actual residuals from known positions. Accepting positions simply on the basis of statistics about precision seems a bit iffy to me. I would certainly want some checks based at least on significantly different satellite geometries or completely independent checks from traversing methods.

gschrock, post: 335246, member: 556 wrote: High rate GNSS has been around for a long time for different applications: machine control, marine & airborne, robotics, even RTK - but of course the base needs to be high rate as well...

I often use 5hz with my single base setups. Especially when staking, a second is a long time to wait for an updated position. (Both Base and Rover are 5hz, I think they are rated to 20hz or more, but that takes more $$$. These are GR3's, and pretty old.)

What exactly is Javad offering that is new or unique, I wonder?

It is apparent to me, that most that are reading this, have not really grasped it.

WE ARE NOT TALKING ABOUT POSITION UPDATE RATES.

We are talking about BASE TRANSMISSION rates. As far as I am aware, only Javad has implemented this. Just because you purchased the 5hz option for a receiver does not matter. That would only affect its use as a rover, not a base.

All brands of GNSS receivers can interpolate positions, and output them as fast as you want. Not a big deal, and nothing new. This is not at all what is being discussed. What is being discussed is the absolutely incredible effect that high base transmission rates can have upon the ability to obtain a fix in very difficult locations. In a bad wooded location with 5hz base transmissions, I can achieve in 5 minutes what can not be achieved in a half an hour at a 1hz base transmission rate. This is not an exaggeration at all. This is the big benefit of what is being discussed.

A secondary benefit is that the user is no longer using an extrapolation mode for position determination. Extrapolation harms precision, which is the reason that all receivers also offer the option of correlating position output with the actual arrival of the correction message. For a Topcon receiver, this is known as "Delay" mode, and it is more accurate than the extrapolation mode. Above, "dmyhill" commented that he runs his rover receiver at 5hz, as a one second update absolutely stinks for stakeout work, and I agree. The side benefit of the high transmission rate is that you can still operate in the more accurate "delay" mode, and still have 5hz position updates. If you do not think that there is a loss of precision caused by using an extrapolation mode, it is only because you have not tested it to prove it. (it is small, but still worth eliminating).

I'd be surprised if anyone is getting 5hz transmit over uhf.

The only hard stance I've seen being made on this issue is that >1hz transmit improves time to fix (ttf) over 1hz, proportionally. 5hz transmit will improve ttf at the rover by 5x over 1hz transmit.

There are limits. Broadcast bandwidth, message, and processing speed at the rover being the most significant factors.