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.