I feel the need for a GPS for Dummies book.
- "Excessive rod movement detected. Stabilize rod." No 18-wheelers going by, just a slight breeze. Great PDOP, 13 satellites.
- Rod height at 0.000. Is MAGNET Field messing with me? BTW, we're using a Topcon Hiper SR. Had to type in 6.562 for a height. If you're not collecting elevations, do you still need a rod height? I figure a rod height is needed even for lat, lon because you're dealing with satellites. Ellipsoid height?
- I was told to shoot the traverse points I set for 15 minutes. When I enter 900 epochs into MAGNET Field, it comes back with "Keep epochs within the 1 - 600 range. It won't accept 900.
"Excessive rod movement detected. Stabilize rod."
Meaningless Magnet babble.
1.)?ÿ Do you have some satellites turned off??ÿ How come you're only getting 13?
?ÿ
2.)?ÿ No, you don't need a rod height if you don't care about elevations.
?ÿ
3.)?ÿ I think you're better off taking 2 3-minute observations on the traverse points and averaging them (spin rod 180 between shots) than doing 1 15-minute observation.
If you're not collecting elevations, do you still need a rod height? I figure a rod height is needed even for lat, lon because you're dealing with satellites. Ellipsoid height?
GNSS is inherently 3D, so yes absolutely rod heights matter, especially if you are intending on post-processing and running an adjustment. If you're doing multiple measurements on points at different rod heights without inputting those heights, you'll never be able to get a good adjustment in post-processing.
I was told to shoot the traverse points I set for 15 minutes.
If you're going to sit on a point for 15 minutes, you might as well just run a static session, or at the very least turn on logging at the rover so you can post-process and adjust using both RTK and static/PPK.
Under typical conditions and assuming full GNSS equipment, RTK observations tend to reach diminishing returns at about 1-2 minutes for horizontal, and 2-3 minutes for vertical. Best practices would be to do what @bstrand suggests first, making sure to average the observations and check your standard deviations of the averaged point, and then return at least 20-30 minutes later and do the exact same routine. I would guarantee that the vertical is going to change noticeably in that time interval, and possibly the horizontal too depending on site conditions.
As mentioned a 2nd occupation is a very good practice (and the minimal procedure you need to prove the 1st measurement). I typically measure a static point 10 minutes. I return with at least a two hour time offset (preferably a different day) and measure a 2nd occupation with 10 minutes of static time. A good way to do this, is A->Z points one day and Z->A points on day two watching you two hour offset as the points get close to same time each day. I also rotate the pole 180 degrees between the two occupations (always oritent the same way on first occupations (north for me, but I suppose anything works), then it is easy to remember to oriente to south for 2nd occupation. Watch your DOP's, cycle slips, trees, etc. and modify (lengten) occupation times if needed. Way faster to stay another 10 minutes or so than return.
Those procedures unless you want super tight control (ie: more time, more occupations, more money) will produce usually sub 0.05' horizontally and sub 0.10 feet vertically relative to the base station or CORS the vast majority of the time.
SHG
Some training would help.
If you need 15 minutes, you shouldn't need 1 second epoch rate. Suggest you configure Magnet for 5 second epoch rate for 180 epochs would get you 15 minutes.?ÿ And as others have mentioned,?ÿ turn on static data to compare an OPUS-RS or post processing.?ÿ
So there are consequences, but still no meaning.?ÿ I see this regularly. I think it has more to do with the connection with the base than with conditions at the rover. That's just a feeling.?ÿ?ÿ
GNSS is inherently 3D, so yes absolutely rod heights matter,
I'm surprised about how many GPS surveyors don't realize this.?ÿ At many GPS seminars the speaker will ask the crowd to point along the GPS ECEF z-axis and most will point straight up.?ÿ Wrong, the z-axis is Cartesian so is oriented from the earth's center of mass to the North Pole (IRP) so you should point North (except if the seminar was held at the North Pole, then you'd be right).
A clever speaker would then ask if the z-axis coincides with the Earth's instantaneous rotational axis.?ÿ Wrong again, The z-axis extends through ( accurately) IRP True North, which does not coincide with the instantaneous Earth's rotational axis.?ÿThe slight "wobbling" of the rotational axis is known as polar motion which differs by a few meters over the short term is not considered by GPS ECEF measurements, which are tied?ÿgravimetrically to the Earth's crust.?ÿ ECEF rotates with the earth, and therefore coordinates of a point fixed on the surface of the earth do not change.
Here's a diagram that may help figure this out.?ÿ I think the problem is most GPS receivers transform the ECEF raw data to Lat-Lon-El or local coords like N/E/El?ÿ State Plane on the fly or even assumed coords (ugh).?ÿ The button pushing field guy doesn't have a clue except bragging my shots close to less than 0.02' onsite.
?ÿ
@bstrand?ÿ
1) No. We use only U.S. and Russian birds.
2) Understood.
3) Management argues that one of the 2, 3-minute observations might be garbage. You would then be averaging a good observation with garbage. At least one individual on this forum has down-played turning the rod 180 degrees, saying it's unnecessary. I was taught that a morning and an afternoon session (3 minutes) of at least a 4-hour separation is the way to do it. You want to use 2 different satellite geometries.
I don't know why management thinks 15 minutes is a magic number. I watch the H and V residuals as the session runs, and there's normally no more than a 0.001' change in either after 3 minutes. Is 15 minutes a minimum duration for a static session??ÿ
@rover83?ÿ
Can you direct me to any "how to" information on logging and post-processing?
If one of the sessions is garbage, they won't agree.?ÿ So my rule would be at least two sessions, and if they disagree by more than some tolerance continue to do more sessions until I see the pattern and can average the ones that agree with each other within that tolerance.
Turning the rod will reveal or average out rod bubble adjustment errors.?ÿ If you check your bubble calibration and don't knock it out of adjustment in transport, then turning won't do much, but how do you know??ÿ Older GPS antennas probably shouldn't be turned,?ÿ due to offsets in their models, and this would look like disagreement in the sessions. I hear the newer ones are more symmetrical.
OPUS-RS has a 15 minute minimum , but I think some of the proprietary software will use less for static.
?ÿ
Check if you're in an Active MOA. south Dakota is home to the B1 fleet some they might have been spoofing for an operation, and of FAA could be tuning etc.
We do a 4 shot avg(yes it's over kill) and take 5 measurements in 3 seconds. Has been doing a fantastic job for the initial control for traverses until we level through them.
Rod height always required, and busted often when not attached to fixed rods or any length.
How the deer been up there? Are you helping to keep the population down at all?(not with your vehicle....)
Looks like you have a sound, logical procedure in place.
I think you're confusing me with someone else. I'm in Florida.
I'm sorry you're right
I was thinking about Travis Mohawk dude avatar
The MOA comment stands as you're full up on Air force bases areas of operations and yeah the FAA too.
?ÿ
Sorry again for the mix up.
You're dealing with anaconda infestation of you're in the south Florida area.
?ÿ
Carry on nothing to see here.
?ÿ
This is going off of memory from an older version of Topcon field software, so it may not be exact: To enable logging, in the GPS Survey Configuration screen there should be a check box that say something like "Post Processing". Make sure that is checked.
Post processing is essentially the same procedure as static baseline processing, only now you will have stop-and-go/kinematic data at the rover. The RTK vectors will already be set i.e., there's nothing you can do to improve or change them after the fact. But you can refine the kinematic data, bring in additional base stations, grab updated ephemerides, etc. before processing.
I don't know what post-processing software you are using, but its help manual and tutorials are where I'd start.
Agree.?ÿ
?ÿ
As a rule of thumb you want something over 30 points in a data set to ensure a normal distribution of errors within the set. 15 minutes at 30 second epochs would give you just barely that. 15 second epochs fattens that up above minimum. 1 second epochs is just a pile of super-redundant data.?ÿ ?ÿ
15 minutes of occupation gives the satellites time to traverse the sky somewhat, and thus alter the multipath effects.?ÿ So there is some value in that. But the same virtues could be had by occupying for 3 minutes (using at least 5 second epochs to collect a normally distributed data set in that time), and then a second 3 minute set starting 12 minutes later, and averaging the results. Even better would be to do the reoccupation a couple of hours (or more) later, when the satellites are in a much greater different geometry, and average that.?ÿ?ÿ
Do 3 x 2 minute observations. Better yet, do 3 x 1 minute obs and use the extra time to "dump" the solution, possibly even reset the VRS (if you are doing network). Three shots like that will make me feel much better than 9 minutes.
And, since it is RTK, each epoch is an observation. When you do multiple epochs, it is an average. SurvCE shows you the stats from the epochs, farthest out, mean, etc. IMHO (based on research) three single epoch measurements with resetting the solution between each one would be better than a 900 epoch "observation".
?ÿ
To be clear, I am not advocating the above approach, it would just be better than the original idea of 900 epochs. And to be fair to the OP, that method was kind of normal when we first started with RTK for a number of reasons.
