What procedure should be used to keep an RTK receiver from updating its base station during a session? We use a private network. I don't know if we use MRS or SBL for a solution. Does the receiver update base stations because it's almost equidistant bewteen two base stations, and it's struggling to decide which one to use?
If you are talking about RTN stations, select a specific CORS mountpoint instead of using Nearest. You could use Nearest to determine what CORS to use, the switch to that specific mountpoint. Or maybe you could start your survey and then turn off GGA to Network. Then the network won't know where the rover is. But the Network may not like that if Nearest is selected.
Here are the details of the network.
?ÿ
?ÿ
I have to experiment with your suggestions on a slow day. Thanks!
You may need to talk to the network operators, but whenever possible I have always configured receivers to pull a multi-station solution but generate vectors to the nearest physical base station.
If it does in fact switch to a different station during a workday, it doesn't matter since the solution is not really single-baseline anyways, and having that tie to the physical station allows us to QC and adjust vectors in post-processing.
?ÿ
After reading that second post...are they really using NSRS2007? That's an odd realization to use. I thought that it was essentially an adjustment of passive monuments to align them to CORS96 positions. And it's old...epoch 2002 I think. It may not matter that much where you are located, but it's a little strange that they're not broadcasting the current NSRS reference frame.
If that's correct, I would assume you are running an older geoid model?
?ÿ
......it depends
A VRS solution is generally a subscription service that either is free or costs a few for access.
We had a single base solution until the county decided it wasnt worth the effort to maintain(typical) and we were forced to usethe VRS. And were also decided to do a static session network adjustment because we work in our LDP we created.
?ÿ
?ÿ
If that's correct, I would assume you are running an older geoid model?
I have to admit that I'm ignorant when it comes to geoid models. I was just watching a YouTube video (Topcon MAGNET Field how to start network GNSS). What do the characters after g2012 in geoid model g2012bu8 mean? How do you download the most current geoid model into MAGNET Field or any other field controller?
I haven't used Topcon in a long time, so I'm not sure how to do the import.
The filename looks like the grid-specific BIN files that the NGS puts out on the Geoid12 home page.
The "B" is for Geoid 12B, which is no different than 12A in the continental US. The "U" is shorthand for continental US (there is an "A" for Alaska, "H" for Hawaii, etc.), and the "8" is the grid number, determined by latitude and longitude.
This page explains the nomenclature.
My guess is that you will need to download the appropriate BIN file, and load it up to your data collector in the folder where the other geoid files reside, and you will be able to see it when starting a job.
The NGS recommends pairing the correct geoid with the correct reference frame/realization, so I would just double-check with the network operators to find out what they are actually broadcasting before deciding which geoid to use.
Honestly, for a lot of work it won't make that much of a difference - for most civil engineering projects it's more about relative heights rather than absolute heights. But it's a good to understand the possible ramifications of using a geoid that was developed for a different realization of NAD83.
The use of an LDP should not influence base station solution you choose to utilize.?ÿ You can, in Leica at least,?ÿ choose to have the RTN automatically determine you projection but I've never really understood the need.?ÿ The RTN should broadcast in the underlaying geodetic datum and the rover should convert that into your chosen coordinate system.
There are some differences in 12A and 12B within the continental US.?ÿ Mostly along the Gulf coast if I recall.?ÿ
I'm not 100% sure on the root of your problem. But my experiences are nearly 99.8% Trimble. With that being said, if you are using a Base/Rover or a site with multiple bases just change the station/index (channel) so they are not stepping on each other. Lose one, jump onto the next as you wish or need. Be sure to set a check point when switching!
If you are dealing with VRS you should be able to adjust the settings to keep it from jumping, but I haven't every had any issues with base jumping in VRS, unless you are logging static at the rover and plan to post process and the jump happens during an observation.?ÿ?ÿ
Mr. Putman is correct...Geoid and Coordinate transformation happens at the controller, the Datum is broadcast from the base in either raw X,Y,X or NAD83, WGS84, ITRF, etc. The State Plane, LDP or local is a parameter set on the controller/rover.?ÿ
Now if you are talking Topcon GPS - no idea, nor do I want to know (sorry just being honest), I am tainted and bias towards Trimble and Javad gear. Topcon GNSS gear scares me.
Understood.
In our case they (now Us because they was before I showed up last year) had been using either the single base solution and or the VRS and then also began migrating and modifying the LDP.
We were seeing up to .2' between the two systems when comparing out the residuals.
Currently we are static(not changing) in our LDP paradigm so the VRS is dialed into our workflow and have tightened up our residuals to just a few hundredths all the time with exceptions due to network lag or poor satellite geometry.
