I'm headed to a very remote area next week and cell coverage will likely be very unreliable due geography and project area. I'd like to run RTK (cellular) as I normally do, but expect there will be gaps in my coverage when I could use PPK or straight static instead. I haven't actually done PPK before so I was looking at the infill options. I would like to collect PPK and try to process it, but if that fails have a good old static session to fall back on.
Can someone explain to me the difference between "RTK & Infill" and "RTK & Logging" under the trimble base options? Do I get a .DAT in both situations?
Thanks.
I believe there isn't any difference in the base. Either of them will create a .DAT file of everything, which you can send to OPUS. Optionally if you have your rover set to RTK & Infill also, then you post process the two files for the stuff you had no RTK radio coverage. Thus the term "infill", in strict Trimblese jargon.
I use the "logging" mode often to send to OPUS. Never messed with "infill", I just figure something else out. If you didn't upgrade to TBC you can't post process anything anyway, thanks to the so called "GPS clock" that expired a couple years ago.
Good luck
Real-Time Kinematic Surveying - Training guide
Part Number 33142-40, Rev D April 2004
(A good guide to get if you have a chance)
Trimble RTK & Infill survey style
By default, the base receiver is instructed to generate real-time kinematic message at one-second intervals and to simultaneously log raw data at five seconds intervals for the duration of the survey
Use this style for real-time topographic or control surveys if there is a risk of radio link interruption.
RTK & Logging
The RTK & logging survey type is similar to RTK expect that raw GPS data is recorded for the entire survey. This method is useful if raw data is required for quality assurance purposes.
Both will give you raw data at the base. The infill will only have post-processed kinematic vectors when radio link is down. The logging records always.
During a RTK & logging truck survey a while back repeated during a period of 3 months at rate of once/week, we found that PPK data gave us better accuracy stats (default at 95% in TBC) then RTK data (default at 68% in TBC).
If you expect to have to use PPK it's a good idea to set the Base to log at 1 or 2 second interval rather than 5 seconds. Otherwise you'll have to wait at each PPK point for 5 seconda. It makes the file much bigger at the base but the receiver memory has plenty of spare capacity, assuming you clear it out from time to time.
Once you have post processed the basic date you get a set of answers. Generally if you then run a full adjustment which reprocesses everything the results are much better (on the first pass TBC seems to attempt a solution on the PPK points close to the last RTK ones and doesn't always get it right).
I've done a number of experiments using a total station target mounted under a GPS receiver and the PPK answers are very close after the second processing.
Try and pick up one or two of the RTK points when you are on PPK as that will give you an element of comfort that everything has worked OK (but give them different reference names so that TBC doesn't try and do anything clever with the two readings).
From a document I received from Michael McInnis of System Dividends (gpstraining.com)...
RTK real time kinematic which allows survey grade data collection, stakeout, and complete transformations – ALWAYS requires radio contact between base and rover(s) – requires initialization
RTK & Infill real time kinematic and selectable post process infill (the operator can switch to raw data collection when necessary) which allows survey grade data collection, stakeout, and complete transformations – allows post processing of radial base/rover vectors when the radio link is down – requires initialization
RTK & Data Logging real time kinematic and continual raw data collection which allows survey grade data collection, stakeout, and complete transformations – ALWAYS logs raw data for post processing, regardless of the radio link status – requires initialization
RTK & Data Logging real time kinematic and continual raw data collection which allows survey grade data collection, stakeout, and complete transformations ?? ALWAYS logs raw data for post processing, regardless of the radio link status ?? requires initialization
Reviving an old thread:?ÿ I'm not a Trimble RTK user, so this continues to confuse me.?ÿ The last time I collaborated with a Trimble shop I had hoped to get raw data in addition to the RTK vectors, but I guess we had the DC configured wrong, as I didn't end up with raw data.?ÿ I'm going to try again on another project with the same firm, and will see if RTK & Data Logging gets me there.
Question:?ÿ does the resulting DAT file have breaks in it that TBC can recognize to filter out the data collected while the receiver is moving between points?
@jim-frame Yes, TBC is able to parse the rover data between roving sections and points observations.?ÿ
We've got infill enabled on the equipment where I work but I've yet to use it.?ÿ I asked the same question and was told there's a window where the shot is being taken that'll be indentifiable. ???ú????
I use RTK & Logging when ever I'm hunting monuments, once found I collect observations for the amount of time as I would for fast static. I process the vectors in TBC and output using Trimble data exchange format. This format is then imported to StarNet as a .GPS file, RTK vectors and raw observations are listed. I only adjust the raw observations and use the RTK as check shots.
The last time I collaborated with a Trimble shop I had hoped to get raw data in addition to the RTK vectors, but I guess we had the DC configured wrong, as I didn't end up with raw data.
When most people talk about running "RTK and Logging" they are (usually) referring to the survey method at the base. It's fairly rare to see folks use it at the rover.
?ÿ
I process the vectors in TBC and output using Trimble data exchange format. This format is then imported to StarNet as a .GPS file, RTK vectors and raw observations are listed. I only adjust the raw observations and use the RTK as check shots.
Out of curiosity, why not keep everything in TBC and process there?
When most people talk about running "RTK and Logging" they are (usually) referring to the survey method at the base. It's fairly rare to see folks use it at the rover.
But is there any reason not to?
Out of curiosity, why not keep everything in TBC and process there?
For me the reason is that it's easy to get my SurvCE total station data into Star*Net format, not so easy to get it into Trimble format.
@rover83 I like the ability to weight observations individually if necessary, this applies to both GPS & total station data. TBC will not allow this as far as I know.?ÿ
Using RTK & Logging at the base and rover allows collection of a baseline for any length of time you require, just my method.?ÿ
RTK & Logging
The RTK & logging survey type is similar to RTK expect that raw GPS data is recorded for the entire survey.
Surprised to see such an egregious atomic typo in what is a Trimble Manual.?ÿ
But is there any reason not to?
Well, the base doesn't move obviously so if you want to use it at the rover then you need some additional electronic sorcery to sort of which data of that is good, and of course that costs money...
if you want to use it at the rover then you need some additional electronic sorcery to sort of which data of that is good, and of course that costs money...
Yes, TBC is able to parse the rover data between roving sections and points observations.?ÿ
So the requisite sorcery appears to be built into TBC.?ÿ I'll be getting a couple of test files in a few days so I can verify this.
