Well, after further review, your RTCM age is 1.000 seconds, so the rover does appear to have good data link.
Your precision threshold theory seems most plausible. You can "start measuring", but the RTK epochs (measurements) to be used won't start populating the solution algorithm until the minimum precisions are met .
Not sure if you are using TBC (Access) to get the sreenshots of the Properties, but it looks like it you are. Do yourself a favor and switch the Precision Confidence Level reporting to "Scale to confidence level = 95%". Technically, DRMS is slightly different than 1-sigma, but if you can display 95% directly, it beats trying to discuss such matters with staff that don't understand what it is anyway. And then everyone is on the same page.
Much of the literature about RTK uses your stipulated definition of the term "fixed", which is the legacy description of the concept, as far as Trimble is concerned. There was a thread not too long ago about what RTK is actually doing/how it's measuring, and it surprised many that a 3 minute RTK "observation" was storing only 1 position solution.
GNSS positioning (RTK/Static) is all about time on a point, and changes in the satellite constellation(s). Trimble thinks that being "initialized" (fixed, but not really) for 3 minutes on a point with RTK should be enough time to get the best available precisions for a given set of site observation conditions such that the position solution satifies some set of criteria deemed to be a "successful" position acquisition. (Repeatable, accurate, precise to some statistical metric.)
Arguably, you would want the time on point to coincide with some finite integer number of measurements (epoch interval). Trimble (most?) RTK base position pulse is 1 second intervals. And typical (good) RTCM age is 1 second (or less). So it makes sense to set RTK measurement intervals (epochs) to 1 second so as to get the maximum number of measurements for a given period of observation time. This scenario gives the algorithm the most amount of data (measurements) to resolve (compute) the best position solution.
I think many people confuse (comingle) different aspects of the methods (RTK and static) between the two styles of surveying . Logging data at the base/rover while performing RTK surveying is one instance where I can imagine these mismatched settings come up. Perfect "survey style" settings for static surveying may not be the same for RTK surveying. Which is why you can create and configure them separately.
"Norman, can you expand on that a bit?"
It's more or less as Bruce described. In the brief moment between deciding to press Record and the thing actually recording the fix is lost and a false reading gets recorded.
I tend to see it in canopy situations and also near fire stations. I don't know what the deal is with fire stations but I assume they have a gnarly radio that somehow causes problems. I can sit within a couple blocks a fire station and take multiple 1 minute shots and have them read 0.10-0.15 different almost every time.
Thank you all for your well thought out and detailed responses! They were all very much appreciated.
OleManRiver...providing a field guide to not screwing the pooch when using GNSS in cover. I agree with the whole thing.
DMY, would it be more appropriate to say that the receiver had fix (it determined a whole number of carrier cycles) albeit an incorrect one? I would suggest this because I would assume the receiver would know if is using a whole integer or not. If this is the case, my question would then be, how would we know how many “distance measurements” were being influenced by incorrect ambiguity resolution? Would it only take 1 to throw the result out by 6′ in each axis like I saw here? Can the receiver not determine that the calculated position wouldn’t really be fitting very well with the other “distance measurements”?
Of course in the real world I wouldn’t just take one shot in these conditions and go on my merry way. I’m more so trying to understand exactly what is happening in the back end of the coordinate determination.
I cannot run you through the math. I can tell you that I have been told by multiple people that can run through the math how to mitigate the inherent dangers of GNSS in canopy.
But regarding a "fix", that is just a word on a computer in your hand, and garbage in = garbage out. And we are the ones putting in the garbage. We set the fix parameters, when and how it stores, etc. "Fix" is a word that is essentially a marketing term by the time it gets down to the end user. Yes, it has actual meaning, but by the time it gets down to the word on our data collectors, it means what we say it means.
Your questions are about the processing is what a certain purveyor (RIP) of GNSS surveying equipment was trying to answer with his V6 solution, from what I understood. Unfortunately, his personality combined with the industry going into harden silos kept that discussion out of the mainstream.
I see you are using SP-85 receivers.
Nothing wrong with that.
But they are previous generation units - nowhere near as good as an R12 or similar under canopy, nor as good at eliminating multipath.
Dont expect them to give good numbers if you use them like you see in some of the current media and advertising.
This exact same scenario happened to me, only once in 15 or so years using RTK systems. About 6 years ago I worked at a company and was using a SP80 base/rover system with Survey Pro, can't remember the versions of firmware or software. Surveying in treed BC mountainous terrain, trying to set some marks on a boundary. There were some "questionable" locations along the way where you knew it wasn't a good idea to use RTK but curious to test the limits we got a measurement with surprisingly good quality statistics, so of course we wanted to check it a few times. First three times all agreed very well, stopped and set a mark, went to check it after and now the same calculated position magically moved something like 70cm. We did several more completely independent initializations over approximately 30 minutes until we had some confidence that we had a reliable measurement.
So what causes it? Well using RTK where it shouldn't be used is the quick and easy answer, but at the same time you expect the equipment not to give you false information. I simply attributed the failure to firmware and software algorithm shortcomings. Some manufacturers specifically have marketed their improvements in this area, Leica for example uses RTK Plus and SmartCheck terminology which makes use of the 500+ channels that the modern GNSS boards now have.
I think it's less likely to see this happen with modern receivers, I certainly have never experienced it with the GS18 receivers we have used for the past several years, and we have definitely pushed them at times. Having said that, I don't trust the CQ numbers reported by Leica Captivate when they get to 4cm or higher.
I don't think the book is closed on these algorithms yet, so I believe we can expect further improvements with newer hardware and software.
Jim you are spot on there & this measurement was actually done in a test comparing an SP80, R12i and Emlid RS2 in:
1. Good local GNSS conditions (clear view of the sky)
2. Questionable local GNSS conditions (semi-obstructed view of the sky)
3. Poor local GNSS conditions (fully obstructed view of the sky)
Data collection is now finished and the video will be uploaded to my channel ( https://youtube.com/@the3rddimensionsurveying?si=T59d3rKyhn7rxsFk) in a week or so.
To sum up what I saw, over 3 days of testing was the R12 performed slightly better than the other two in test 1, test 2 the SP80 actually did slightly better than the other 2 and test 3 the SP80 was unusable & the RS2 was between 2-4x worse than the R12.
It would be interesting to see a Javad in there with the V6 processing and see if it did what was claimed.
One reason, your equipment is old. Looks like you are receiving US and glonass satellites , so I’m guessing you’re using a R10-1. When using that in the woods, occasionally I’d get an observation 5 feet off horizontally or 5-10 feet off vertically. But with R12i, that’s a thing of the past which at first added Galileo, then Beidou last year when upgraded my base to R780.
If you’re using a R10-1 type receiver in 2024, it's like trying to dig a hole with a tree branch while the guy next to you is using a backhoe.
A RTK observation of 30 minutes is wasted time, unless you’re also storing static data. Once your precision values stop improving on an observation, extra time doesn’t improve your observation, but can hurt it if you lose a satellite or geometry changes and your precision gets worse. With my R12i and R780 base , don’t need an observation longer than 15 seconds 98% of the time. But I do multiple observations resetting satellite tracking between them and adjust observations.
Spectra precision is cheap, but the hit against it is they are not durable. And that SP80 is old and doesn’t receive most of Beidou satellites. One of your problems is not receiving all the GNSS signals available today.
R12 is top of the line product and SP80 is basis R10 model 1.
