dmyhill, post: 365198, member: 1137 wrote: In my mind, the .3' vertical would not be "fixed", unless the reported RMS reflected that.
If you do indeed flesh out the investigation, including the correlation (if any) of the actual error to the modeled error would be of great interest.
I believe that the term "fixed" really only has merit to me when the modeled error is a real world number.
Your definition of "fixed" is inaccurate. Fixed, is a flag from the processor that the difference in cycles between the base and the rover have been accurately determined. It's a statistical value based on some confidence level, usually 2-4 sigma. The L1 carrier signal has a wavelength about 0.6' long. If the wrong number of cycles are determined, you could expect an error (3D) in position in excess of this.
Receivers also determine the fractional part of the incoming wave, similar to the way an EDM works. I believe that phase detection is good to about 1% of the wave length. This is why an EDM uses more than one frequency. For precise differencing in GPS using the L1 carrier phase, 1% is about 0.006 or 2mm, which explains why we can get much better than 0.6' with GPS. But there are other issues that degrade our accuracy, so the 2mm phase determination doesn't exactly translate to 2mm position accuracy.
In this test, it would certainly appear that all points are easily within one cycle of each other, suggesting that for each point the correct number of cycles between the base, 195' away, and the rover under the trees, were determined in both RTK and post processing. The phase proved much more difficult to determine due to multipath, which Javad refers to as a bent tape. The signals rattled through the trees above, deflecting with every contact, essentially bending the tape between the satellites above and rover below.
By my own observations, in very good conditions, I expect an accuracy of 5mm+0.7ppm horizontal RMS and 7mm+0.7ppm vertical RMS with this system and observations in excess of 3 minutes. At 195 feet this should have translated to 0.02' horizontal and 0.02' vertical. Looking at the 68% distribution above, it looks like I got about 3-5 times worse due to multipath.
To sum this up, "Fixed" has a very specific meaning.
Shawn Billings, post: 365255, member: 6521 wrote: Your definition of "fixed" is inaccurate. Fixed, is a flag from the processor that the difference in cycles between the base and the rover have been accurately determined. It's a statistical value based on some confidence level, usually 2-4 sigma. The L1 carrier signal has a wavelength about 0.6' long. If the wrong number of cycles are determined, you could expect an error (3D) in position in excess of this.
Receivers also determine the fractional part of the incoming wave, similar to the way an EDM works. I believe that phase detection is good to about 1% of the wave length. This is why an EDM uses more than one frequency. For precise differencing in GPS using the L1 carrier phase, 1% is about 0.006 or 2mm, which explains why we can get much better than 0.6' with GPS. But there are other issues that degrade our accuracy, so the 2mm phase determination doesn't exactly translate to 2mm position accuracy.
In this test, it would certainly appear that all points are easily within one cycle of each other, suggesting that for each point the correct number of cycles between the base, 195' away, and the rover under the trees, were determined in both RTK and post processing. The phase proved much more difficult to determine due to multipath, which Javad refers to as a bent tape. The signals rattled through the trees above, deflecting with every contact, essentially bending the tape between the satellites above and rover below.
By my own observations, in very good conditions, I expect an accuracy of 5mm+0.7ppm horizontal RMS and 7mm+0.7ppm vertical RMS with this system and observations in excess of 3 minutes. At 195 feet this should have translated to 0.02' horizontal and 0.02' vertical. Looking at the 68% distribution above, it looks like I got about 3-5 times worse due to multipath.
To sum this up, "Fixed" has a very specific meaning.
Shawn, do you know if the software is weighting points differently when averaging a cluster in the LS? For instance in canopy I might first try a shot without verify reset, then with it, or with differing times and confidence levels set. So theoretically some of the positions in the cluster should be more reliable than others. Does the average cluster routine take that into account?
And, I don't see a way to remove a position I don't like from the cluster, at least while in the routine. Although I can change the distance allowed, but that might remove a couple I want and leave the ones I don't, and then have to do it over with ones I want, would be nice to allow removal from the cluster average by point number.
Duane,
You are correct that cluster average and cogo>average use a weighted average. The weighting is based on RMS. If you want to manually control what points are included and which are not, use average in Cogo.
Shawn Billings, post: 365255, member: 6521 wrote: Your definition of "fixed" is inaccurate.
To sum this up, "Fixed" has a very specific meaning.
I am sorry that you felt I defined "fixed". I simply observed that no matter what any receiver tells me, if it says it was fixed with an VRMS of .3', I won't believe it. I don't care who made it. (Which is why I was curious about the modeled accuracy for those shots.) No need to get defensive here, I am not attacking your product.
In fact, I wish all sales people for GPS equipment were doing and exploring and publishing like you.
If the modeled accuracy, however expressed, was reasonably correlated to the results, that is outstanding.
What you were testing, if I understood your OP, was whether your software would give you a false fix.
Essentially, "fixed" means that the reciever has convinced itself that it is correct within the accuracy it is publishing. (To condense your post.) You might want to review the studies out of the UK before concluding that the .6' threshold is a good rule of thumb, although the typical 0.3' rule of thumb does to seem to bear out in your testing.
My understanding is that if you had one minute observations in RTK @5hz, they are really 300 individual observations, all averaged, typically rejecting certain readings that exceed certain parameters. In that context, you expected that in those conditions the software might fool itself for a minute. So, you extended the number of averaged observations to what you felt was prudent. (I hope I am understanding.)
What you really can see here is less about RTK in general, and more about how your software handles poor conditions. I find the test fascinating. But of interest to me would be the number of rejected readings, how many, the extreme numbers within each of those sets of collected readings.
On the software I use, that would be unavailable in the raw data, because I have it set to not record and not move forward on the observation count, depending on certain parameters.
Again, I enjoyed seeing your post. No attacking your equipment from here.
Shawn Billings, post: 365258, member: 6521 wrote: Duane,
You are correct that cluster average and cogo>average use a weighted average. The weighting is based on RMS. If you want to manually control what points are included and which are not, use average in Cogo.
Thanks Shawn. I haven't explored the cogo functions much. I suspected weighting was happening but wasn't sure how. By rms seems reasonable but glad to have the cogo function to eliminate points as well. I had it set to confidence and consistency 7 & 5, 120 epochs. 120 apparently wasn't enough to reach those levels on two shots, but on the third it reached 16.75 and 106.80. The third was closest match to 6 hour static, although the average of the three was better in easting and elevation. Only talking 5 hundredths or less anyway. But I was impressed with the elevation considering I mounted the base on the truck now, average was within 0.01'. And it's a tough enough spot that the six hour static had 1/2 tenth difference between OPUS and DPOS, and I can't get a fix at all with the rtn on this position. In beast mode I'm only spending 40 seconds or so per collection. I still get impatient though, please ask Javad why it has to take so much longer than my edm?:)
dmyhill, post: 365259, member: 1137 wrote: I am sorry that you felt I defined "fixed". I simply observed that no matter what any receiver tells me, if it says it was fixed with an VRMS of .3', I won't believe it. I don't care who made it. (Which is why I was curious about the modeled accuracy for those shots.) No need to get defensive here, I am not attacking your product.
In fact, I wish all sales people for GPS equipment were doing and exploring and publishing like you.
If the modeled accuracy, however expressed, was reasonably correlated to the results, that is outstanding.
What you were testing, if I understood your OP, was whether your software would give you a false fix.
Essentially, "fixed" means that the reciever has convinced itself that it is correct within the accuracy it is publishing. (To condense your post.) You might want to review the studies out of the UK before concluding that the .6' threshold is a good rule of thumb, although the typical 0.3' rule of thumb does to seem to bear out in your testing.
My understanding is that if you had one minute observations in RTK @5hz, they are really 300 individual observations, all averaged, typically rejecting certain readings that exceed certain parameters. In that context, you expected that in those conditions the software might fool itself for a minute. So, you extended the number of averaged observations to what you felt was prudent. (I hope I am understanding.)
What you really can see here is less about RTK in general, and more about how your software handles poor conditions. I find the test fascinating. But of interest to me would be the number of rejected readings, how many, the extreme numbers within each of those sets of collected readings.
On the software I use, that would be unavailable in the raw data, because I have it set to not record and not move forward on the observation count, depending on certain parameters.
Again, I enjoyed seeing your post. No attacking your equipment from here.
My understanding is that DPOS fixes 15-20 best ambiguities first, then recalls all other float ambiguities to get final integer solution. So the solution is either fixed or not, and is not something you can look to as an indicator of measurement quality (as opposed to an OPUS S). More similar to an OPUS rapid static than an OPUS static maybe? The RTK solutions use both kalman filter and software algorithms to eliminate (hopefully) the false fix created by multipath. So you can look at confidence level, which I think is comparing different algorithm solutions and consistency level, which I think is comparing solutions within an algorithm. I agree the rms alone does not necessarily mean the solution is a good one. Having taken a stab, I'm sure Shawn will jump in here and correct me:)
dmyhill, post: 365259, member: 1137 wrote: No attacking your equipment from here.
I didn't take your post as an attack. You made an assertion I did not agree with. I wasn't being defensive either. I was sharing my understanding of the word "fixed" in context of precision GNSS differencing.
dmyhill, post: 365259, member: 1137 wrote: In fact, I wish all sales people for GPS equipment were doing and exploring and publishing like you.
I appreciate the kudos. I'm a surveyor first and not much of a salesman. I use this system almost everyday in the real world of surveying to make a living and building and maintaining a professional reputation, so I have a vested interest in how this equipment works in my environments. We've been doing this same sort of testing since we started with L1 only, post processed GPS in 2000. We studied, as best we could, how the equipment worked in different settings and how we could push the envelope to get more out of the system than people expected. Sometimes we found the envelope was where it was for good reason. Other times we found the envelope was very pessimistic. Dad found that he could use L1 only processing with CORS 100 miles away to get reliable positions within 3cm of "truth". No one, to my knowledge, had ever done that before. Someone, somewhere probably had, but we never heard of it. Turned out his idea was very similar to how an RTN models atmospheric conditions within the polygon of reference stations. I suspect the idea of an RTN predated his discovery circa 2000-2001.
Every user should find the breaking point of their gear, in my opinion. The gear alone isn't the only variable in the equation. The operator's location, site conditions, methodology, correction source, et al, all play a role in how the equipment will perform. I would warn users not to extrapolate too much on the results of what I've published here. I obtained these results, on this day, with this equipment in these conditions. Your mileage may vary.
dmyhill, post: 365259, member: 1137 wrote: Essentially, "fixed" means that the reciever has convinced itself that it is correct within the accuracy it is publishing. (To condense your post.) You might want to review the studies out of the UK before concluding that the .6' threshold is a good rule of thumb, although the typical 0.3' rule of thumb does to seem to bear out in your testing.
Perhaps an oversimplification. As I said a fixed solution relates to the number of cycles between base and rover. There is an additional part of the measurement that includes the fractional part of the phase. From my experience, I would agree with you about the 0.3' rule of thumb. Going back to my days using L1 only, I don't recall any good fixes with errors in excess of 0.3'. I'll claim ignorance to some degree on this. I don't believe this 0.3' rule of thumb is a precise value. I'm also not sure what effects the merging of other frequencies into a multi-frequency, multi-constellation solution has on this 0.3' rule. I've seen the UK study referenced a time or two, but I've not read it.
dmyhill, post: 365259, member: 1137 wrote: If the modeled accuracy, however expressed, was reasonably correlated to the results, that is outstanding.
My understanding is that if you had one minute observations in RTK @5hz, they are really 300 individual observations, all averaged, typically rejecting certain readings that exceed certain parameters. In that context, you expected that in those conditions the software might fool itself for a minute. So, you extended the number of averaged observations to what you felt was prudent. (I hope I am understanding.)
What you really can see here is less about RTK in general, and more about how your software handles poor conditions. I find the test fascinating. But of interest to me would be the number of rejected readings, how many, the extreme numbers within each of those sets of collected readings.
Currently I cannot comment on the error estimates of the post processed results. The post processing feature is in beta and the reported error estimates are not functional (as of yesterday). I too would like to see how the error estimates compare to the results. There are also other quality indicators. The RTK populates each epoch on a dot plot for horizontal and vertical. Experienced users can watch these plots and see abnormalities. Also the number of engines used in the six engine processor will indicate potential issues. This test completely removed user intuition and was fully automated, both for RTK and Post Processing. I suspect a savvy user might have spotted warning signs regarding the "outliers", but I can't say for sure right now.
In your example of 300 epochs at 5Hz, you have 300 observations based on the same fix (most likely). So they are highly correlated. The reason I added more time was not for the additional epochs to average in the solution, but the idea that a bad fix will unravel given enough time, regardless of the number of epochs included.
Total Station Results for the Test Point:
N 6835834.623
E 3100880.310
U 396.129
(US Survey Foot)
Recall that the RTK average for this point was:
N 6835834.638
E 3100880.302
U 396.112
The Post Processed average for this point was:
N 6835834.655
E 3100880.278
U 396.118
All of which are in very good agreement, which we would expect since this is an average of 187 points collected over a period of 11.5 hours.
For now I cannot answer the question about RMS for the outlier points, but I can offer some data on the RTK points that were on the fringes of the average. The following screen captures were taken automatically by the software as specific points during collection. They are included in the final pdf report exported by the receiver.
This shows our "Phase 1" verification phase where engines are constantly reset until a consensus can be made around a particular fix. The number or agreeable fixes that determines the consensus is set by the user under "Confidence Level". You see that one bad fix was identified in this phase. It exceeds my tolerance in horizontal and vertical distance from the consensus. This is 25 seconds after the shot started. In that time 20 different fixes were determined by the six RTK engines. The bad fix is rejected from the average position for the point.
This is at the end of the shot, 189 seconds after the shot has begun. The screen plot shows a lot of noise, both in horizontal and vertical. This point was the worst of the 187 points collected, being almost 0.18' from the total station derived horizontal coordinates for this point and 0.34 foot from the elevation. The VRMS shows to be 0.07 foot (upper right white box) and the HRMS shows to be 0.05 foot. The 95% for the horizontal is 1.6x HRMS and the 95% for vertical is 2x VRMS, so these would be approximately 0.10 and 0.13 at 2 sigma. The plots seem more revealing though. Any points that exceed my tolerance of 0.13' horizontal from the average or 0.26' from the vertical are excluded from the average. If more than 30% of the total number or epochs are excluded, the software starts over automatically at "Phase 1". There is an option to show how many have been rejected, but I do not have it on in this screen capture.
This shows the contribution of each of the six engines for the first phase. Notice that 2, 3, 4 and 5 contributed most of the fixes but each engine did contribute at least one fix. Since each engine relies on slightly different algorithms, this tells us that we have agreement between fixes using several different processing estimates.
This is the horizontal and vertical plot for the same period.
This is the vertical contribution for each engine for the entire 189 second observation
This is the combined vertical and horizontal contribution of each engine for the entire 189 second observation.
For the most part, I seldom check these graphs, but they are stored with every single observation (per user configuration) and available at any time for the user to review.
Were I standing at the instrument watching this shot, I would reject and start again. But I wasn't really doing a precision test, I was looking for failures. The extreme spread is more than I would expect, so I would have started again.
This is a comparison screen capture from a point recorded just prior to point 23. Point 20 is right at the edge of distance from the average that contains 68% of the 187 points. It's the outside of the 1 sigma ring, so to say, of the 187 points. It is 0.05' horizontal and 0.08' vertical from total station determined coordinates for this point. See if you can spot the difference from the much less accurate point 23...
Here is the first Phase, where the software is constantly resetting the engines. The extreme spread of the individual fixes is relatively low.
Looking at the final position, the dot plot looks very uniform, no funny shapes (such as C's or hockey sticks). The closer that the horizontal plot looks like a thumb print, the better. And the closer that the vertical plot looks like a sine wave, the better. The extreme spread of the vertical is a little rough, but if you look carefully, the main reason for this is the early single engine epochs from Phase 1. The Horizontal RMS is 0.03' and Vertical RMS is 0.04'. This is noisier than we would expect in the open, but understandable given the canopy.
Only four engines contributed fixes to the initial Phase 1 test.
But ultimately all 6 engines were fixed at some point during collection. Notice engine three has a little trailing, but the others look very condensed.
Thank you. That is very interesting work.
Thanks for posting another interesting write up and once again over my head. Haha.
Out of curiosity have you ever tested multiple brands of RTK units at the same time for accuracy results, use in canopy, time to fix etc?
Shawn Billings, post: 364882, member: 6521 wrote: About a week ago I was doing a test under canopy to determine three things:
- The use of observation time to detect bad fixes in moderate canopy with RTK.
- The effectiveness of post processing with relatively short observation time in moderate canopy.
- The battery life of the spread spectrum radio I was using at the base.
When I refer to moderate canopy, this was my test site (enjoy the snazzy Dating Game sounding music):
[MEDIA=youtube]WEzjmP-Rqi0[/MEDIA]The base was about 195 feet away in an open environment. Corrections were broadcast at 5Hz over FHSS. The test was designed to run as long as my base radio battery lasted, which was 11.5 hours. I had the rover set to collect data for at least 3 minutes with several engine resets throughout the observation. My theory, when I started this test, was that a bad fix cannot last more than about 1.5 minutes. Most only last a few seconds, but under the right (or rather wrong) conditions, it is possible to see a bad fix last longer. I've not seen it last longer than 2 minutes though. Over the course of 11.5 hours, I collected 187 points using the auto-accept and auto-restart feature in the receiver. I could then leave the receiver unattended for this test. While the receiver was crunching out the RTK observations, it was also collecting raw GNSS data, as was the base receiver. The average time on site for each point is about 3.5 minutes.
The 187 RTK points 187 total produced an average position of:
N 6835834.6382
E 3100880.3018
U 396.1117
(US Survey Feet)Later, I sent the base raw data file and the rover raw data files to Javad's new DPOS server, which is capable of not only processing base receiver files with CORS data, but also processing the vectors from base to rover and from rover to CORS. For this test, I omitted processing to CORS as my occupation times were not long enough to produce good results.
The 187 post processed points (referred to as Base Processed or BP) produced an average position of:
N 6835834.6553
E 3100880.2777
U 396.1177
(US Survey Feet)The difference between the average position RTK and the average position BP:
dN 0.017
dE -0.024
dU +0.006The next question would be to know how the distribution of the 187 points was around the average...
Shawn Billings, post: 365316, member: 6521 wrote: This is a comparison screen capture from a point recorded just prior to point 23. Point 20 is right at the edge of distance from the average that contains 68% of the 187 points. It's the outside of the 1 sigma ring, so to say, of the 187 points. It is 0.05' horizontal and 0.08' vertical from total station determined coordinates for this point. See if you can spot the difference from the much less accurate point 23...
Here is the first Phase, where the software is constantly resetting the engines. The extreme spread of the individual fixes is relatively low.
Looking at the final position, the dot plot looks very uniform, no funny shapes (such as C's or hockey sticks). The closer that the horizontal plot looks like a thumb print, the better. And the closer that the vertical plot looks like a sine wave, the better. The extreme spread of the vertical is a little rough, but if you look carefully, the main reason for this is the early single engine epochs from Phase 1. The Horizontal RMS is 0.03' and Vertical RMS is 0.04'. This is noisier than we would expect in the open, but understandable given the canopy.
Only four engines contributed fixes to the initial Phase 1 test.
But ultimately all 6 engines were fixed at some point during collection. Notice engine three has a little trailing, but the others look very condensed.
Just for the record.... I want to 6th grade, and 10th grade.
My schoolin is wayyy down at the other end of things.
I have done many things, that are NOT wise.
The Javad system is more complex, than any other out there right now. BUT...
The parts you NEED are within reach, to ANY surveyor, that can pass the LS Exam. If they want it.
There are 2 things you need in life. Motivation, and Aptitude.
I learned SPC, (what Little I know) from a simple diagram, showing flat spots on a ball. They are artificial. They are Arbitrary. They are handy. They are a tool of expressing relative relationships.
Once you learn the Pythagorean Theorem, All the rest of it is academic! (sorry, make a little joke)
Line upon line, precept upon precept. Here a little, and there a little.
The Javad appeal, does not extend to everybody. But, those who do like it, won't come back.
That being said, there is something there. For those who like stuff like that.
MOST surveyors, started with something... and went where they are.
Like this:
Monroe Hand Crank Calculator.
Olivetti Underwood, (programmable) Program cards.
Then, some kind of TI-55, and TI-59, with print out.
Then, HP 41, with survey module.
HP 48 SX
HP 48 DX
Then, a few other devices.
TDS Ranger
and some of our modern data collectors. Carlson.
Javad went to the table, without this background in the HISTORY of land surveying. He got input from Land surveyors, and did his thing. Some of the thought processes, will make new roads in your head. But, it's fun. It's an adventure. And it is fast. And it works.
Time to DPOS yesterday's job, and put it on SPC.
Nate
TX Surveyor,
TXSurveyor, post: 367433, member: 6719 wrote: Out of curiosity have you ever tested multiple brands of RTK units at the same time for accuracy results, use in canopy, time to fix etc?
I have done my own redneck, observations. To some extent. There are places, where GPS don't go. Mineshafts.
I have retraced some of my own work. The differences are not much. Yesterday, I found a difference of 0.12'. HOWEVER. The main difference is the TIME necessary, to have HIGH confidence.
Often I spent 1.5 hrs, getting a 100% confidence shot, with conventional RTK.
And, Now, that is 10 mins with JAVAD. Or less, sometimes.
N
I'm intrigued by this Javad equipment. I'll have to look into it.
Base/Rover setup ~$15-20k investment if I'm understanding this correctly?
Does it use Galileo and/or Beidou?
Mark O, post: 368014, member: 11591 wrote: I'm intrigued by this Javad equipment. I'll have to look into it.
Base/Rover setup ~$15-20k investment if I'm understanding this correctly?
Does it use Galileo and/or Beidou?
The Triumph LS can track those two constellations Mark. The Base/rover setup is priced at $19990 with the Triumph 2 and a 1 watt radio.
Javad or others should be paying Wendel to allow this on going commercial AND advertising of his equipment; by end users that may or may not be compensated from the sales generated.
Adam, post: 368016, member: 8900 wrote: The Triumph LS can track those two constellations Mark. The Base/rover setup is priced at $19990 with the Triumph 2 and a 1 watt radio.
"can track" and "using" in a solution are different things. I don't know the answer to whether it "uses" those constellations in a solution.
leegreen, post: 368019, member: 2332 wrote: Javad or others should be paying Wendel to allow this on going commercial AND advertising of his equipment; by end users that may or may not be compensated from the sales generated.
It's a fair question: where do you find the line between advertising and information useful to the community?
Shawn and a few others clearly have a business relationship with Javad, but if they're providing descriptions of equipment that operates significantly different from other gear on the market, is it advertising or user assistance?
In Nate's case, I'm pretty sure it's just a matter of an enthusiastic end user sharing his experience with the community. More enthusiastic than most to be sure, but nothing nefarious that I can see.
Jim Frame, post: 368043, member: 10 wrote: It's a fair question: where do you find the line between advertising and information useful to the community...
In Nate's case, I'm pretty sure it's just a matter of an enthusiastic end user sharing his experience with the community. More enthusiastic than most to be sure, but nothing nefarious that I can see.
I noticed Nate's avatar picture. He is sitting and stroking the Javad in his lap with a sly grin, sort of kinky.
Jim Frame, post: 368043, member: 10 wrote: It's a fair question: where do you find the line between advertising and information useful to the community?
Shawn and a few others clearly have a business relationship with Javad, but if they're providing descriptions of equipment that operates significantly different from other gear on the market, is it advertising or user assistance?
In Nate's case, I'm pretty sure it's just a matter of an enthusiastic end user sharing his experience with the community. More enthusiastic than most to be sure, but nothing nefarious that I can see.
Ahh, Nefarious Nate and his Javad minions. Discussing their equipment in public like it's a presidential debate or something:) I suppose it could get tiring for those not feeling the JAV. But seriously, I would like to hear more about other brands here. I'd be pleased to read more about Topcon from Lee. Don't know how Wendell feels about it all.