Ok check it out. under light canopy ( no leave minimal overhead limbs. ) We located several point along the New River for an elevation certificate. the points 501 through 504 were collected letting the unit process at its own rate with120 epochs with v6 verification, the points 505-508 are the same points in reverse they were collected with 120 epochs verified with v6 verification also, the only difference was that i reset the engines and tracking on my own at each location between 505 and 508 ( because i tend to be impatient ) . There is over a 1' difference at points 504 and 505. any thoughts from the Javad users ?
PointNo. Northing(Y) Easting(X) Elev(Z) Description
501 1026186.10 1310764.88 2486.58 Nip 13
502 1026059.49 1310783.72 2486.77 Nail Sycamore
503 1025876.62 1310736.33 2492.16 Nip
504 1025844.16 1310806.99 2488.53 Nail
505 1025842.36 1310807.07 2487.84 Nail
506 1025876.55 1310736.27 2491.96 Nip
507 1026059.63 1310783.68 2486.70 Nail Sycamore
508 1026186.15 1310764.72 2486.60 Nip 13
160913 1026471.98 1310657.61 2489.27 0
Randy, Time on point is essential in the LS finding bad fixes, 120 epochs isn't enough especially with 5 Hz. I use a min 3 minutes. In Canopy I may use 5 or 10 minutes and repeat shots.
I agree with Adam. 120 epochs at 5Hz happens pretty quickly (as fast as 24 seconds). I would recommend at least 2 minutes in a questionable environment. Like Adam, I usually occupy for a minimum of 3 minutes in canopy. Time on site helps considerably (not just epoch count).
Also, can you say if you used validate at the end? Validate resets at the end of the observation for one last check on the initial fix.
Even with Validate on, I recommend using a minimum of 2 minutes.
Dittos on the time. It needs 120 seconds + to catch a bad fix.
Other things I watch, are if elev is jumpy, Then, re observe.
The next version (Which I have the prototype of, as it's in testing) will have a setting for time, in addition an epoch count.
This is real handy. So, you can SET a minimum of 120 seconds, and 50 epochs, or 120 epochs.
It's a product that is expanding.
It USED to be that 120 epoch would catch that error, (at the 1 hz rate)
For now, for any point of high significance, make sure you have at least 120 seconds on it.
(I'll admit, I'm an over kill kind of guy, and often do this 3 times, JUST to see the spread in the shots.)
The equipment is fast enough, to allow a good check.
Nate
I might add that in canopy I have been using 60 for confidence.
Here is a PDF of your points, showing the spread.
As I look at it, I draw some conclusions.
Your Rod bubble is probably not good, or needs adjustment.
Your Northerly 2 Data sets are pretty close for elev. If you observed these, facing different directions, each time, this would indicate rod bubble error.
Or, you used the monopod, with out tilt corrections on.
And, the large spread, in elev, on the lower 2 is excessive. Especially the southerly one.
IF this were my project. I'd carefully run the LS through all it's Calibrations.
Then, I'd either double check the POLE bubble, (You could skip this, IF you were careful to always face some direction, however, I'd seeing an error here.
And, I'd run through these with a bipod, and I'd run them,
And, I'd set the LS like this:
From the Action Setup Screen:
Start with start button.
Only RTK fixed
Correction for tilts OFF
Level offset, (Index this)
Activate PP, after 5, is ok
(Next column)
How to stop,
Stop after 200 epochs
Auto accept NO
Auto Restart NO
(VERIFY)
WITH V6 reset
Confidence Guard set to 0.13 and 0.23
Min Engines At LEAST 3
Flashlight blink, your choice
Confidence 25
Consistency 60
Max Groups 5
At the bottom of the screen, Validate Result
with at least 3 engines.
Now, after indexing the pole bubble, re run this project. When you get to the end, where you turn around, and go back, pick it up, and walk a circle, in the clear, and set it back on the point.
Redo this, and post the results.
If you are not getting better, And, I mean alot better, I'd want to come and inspect what is going on.
Cheers.
Nate
Thanks . My concern was that I may be interrupting the process by resetting the engines. After awaiting a fix after losing a fix it seems that if you do a reset the fix comes faster. I have never used the word "fix" three times in a sentence before.
No, you are just fine, resetting rtk.
It's set on mine as button u1.
If I change environments, I often press it, before beginning an observation.
And, if things aren't happening fast enough, occasionally then too.
N
Randy Rhodes, post: 369246, member: 10669 wrote: Ok check it out. under light canopy ( no leave minimal overhead limbs. ) We located several point along the New River for an elevation certificate. the points 501 through 504 were collected letting the unit process at its own rate with120 epochs with v6 verification, the points 505-508 are the same points in reverse they were collected with 120 epochs verified with v6 verification also, the only difference was that i reset the engines and tracking on my own at each location between 505 and 508 ( because i tend to be impatient ) . There is over a 1' difference at points 504 and 505. any thoughts from the Javad users ?
PointNo. Northing(Y) Easting(X) Elev(Z) Description
501 1026186.10 1310764.88 2486.58 Nip 13
502 1026059.49 1310783.72 2486.77 Nail Sycamore
503 1025876.62 1310736.33 2492.16 Nip
504 1025844.16 1310806.99 2488.53 Nail
505 1025842.36 1310807.07 2487.84 Nail
506 1025876.55 1310736.27 2491.96 Nip
507 1026059.63 1310783.68 2486.70 Nail Sycamore
508 1026186.15 1310764.72 2486.60 Nip 13
160913 1026471.98 1310657.61 2489.27 0
I would be interested in what do the quality indicators look like, compare 504 with 505. Click on those points and see what the rms is and the error elipse, confidence, consistency (although I'm not sure any of those will necessarily indicate a problem). My understanding is the number of epochs should be controlling over time it takes to get them. I might be on a point for 5 minutes to get 120 epochs in 60 seconds and it should continue to gather epochs until confidence and consistency levels are reached anyway, and then reset and validate. But you may be onto something. I don't usually reset tracking or engines, but I did the other day on one point after getting impatient. I have reason to believe that point is .9 ft off and will be remeasuring it this week. The other indicator of a problem on that point was a long time to validate, almost gave up and recorded it without a verification. In addition I only had two engines fixed and part of the time only one. You get that in really tough environments and the locations need to be checked.
Another factor, that can contribute is the satellite configuration. If the sats are in poor config. Then it can make mild canopy, into bad canopy. Somebody suggested that we put a satellite configuration chart, into the javad. I think that's a wonderful idea.
Nate The Surveyor, post: 369479, member: 291 wrote: Another factor, that can contribute is the satellite configuration. If the sats are in poor config. Then it can make mild canopy, into bad canopy. Somebody suggested that we put a satellite configuration chart, into the javad. I think that's a wonderful idea.
What kind of chart are you thinking of Nate? I'm wondering what it would add to the sky plot and listing of satellites already shown?
It would be a simple graph chart, showing, the times of day when things are poor. Showing the spikes, when things are the best.
The idea is to not head into a hole, with poor sat config.
To do some mission planning, hitting certain spots, when sat config is optimal.
Somebody over at the Javad site mentioned this. I thought it was a good idea. I tried for a bit, to find his comment, but failed.
N
Nate The Surveyor, post: 369484, member: 291 wrote: It would be a simple graph chart, showing, the times of day when things are poor. Showing the spikes, when things are the best.
The idea is to not head into a hole, with poor sat config.
To do some mission planning, hitting certain spots, when sat config is optimal.
Somebody over at the Javad site mentioned this. I thought it was a good idea. I tried for a bit, to find his comment, but failed.N
I agree, mission planning would be good, especially with space weather forecast (been burned a couple times by that).