PPK

It depends on the receiver. However, in general you can control the occupations using "Survey: Log Raw Data". The screen will be different depending on the receiver model in play.

On some receivers that we sell you can open a raw file, check the list of existing files, mark beginning of occupations and end of occupations (site tagging) and close the raw file.

On other receivers you may need to open the file (typically by pressing a Files button to open the file and begin recording. Then the 'Log Raw Data' screen only allows tagging sites.

What receiver model are you dealing with? (I probably won't have one, but someone else can chime in.)

On the older Topcon units, there was a button on them. Press it, for 2-3 seconds. It creates the file name, and all. Press again, and it stops the raw file.
My point is that this is a variable. Different receivers different way.
N

Just start logging kinematic on rover usually at 1 sec interval. Or if there is no such option then log using static. Important thing is that both receivers are logging at same rates. You get coordinates from your post processing software by changing type of data for rover to kinematic.

It's a hiper plus. I know how to start a static session. I do it by pressing the button on the receiver. 15 min. Minimum for opus. But what about ppk, what's the minimum occupation time, in clear sky.
what do I do with the tps file? Or the file
that Carlson might generate

PPK is same as RTK except for the corrections sent from base to rover. No minimum occupation time or to put it another way, you need same 1 second of data for both base/rover. If both receivers have enough satellites for data during that 1 second then your software can get a fix solution. you download both raw data & process similar to static except you set the rover to "kinematic" mode in the software. process the 2 files and you will get a vector for each second of data common to the 2 receivers. some will come out as 'fixed' while other may have 'float' solutions.
i use this for topo/bathy survey where radio is difficult to set due to terrain. to counter 'float' solutions, i usually set up 2 base receivers against several rovers. that way i have redundancy.

Does it work with RTN data? You can get the static files from RTN, then process with your field data?

To emphasize the point made earlier - you must be logging at the base. If I have any doubts about whether the RTK signal can be held throughout the survey then I always set the base to log at 1 second interval, so if I have to swap over to PPK then I know the reference data is there. If you don't need it then you don't have to save the base logged file.

It's generally wiser to take several seconds of readings on each PPK point to ensure you have it, since you do not have the RTK reassurance of seeing the data has been captured and the point quality.

chris mills, post: 392356, member: 6244 wrote: To emphasize the point made earlier - you must be logging at the base. If I have any doubts about whether the RTK signal can be held throughout the survey then I always set the base to log at 1 second interval, so if I have to swap over to PPK then I know the reference data is there. If you don't need it then you don't have to save the base logged file.

It's generally wiser to take several seconds of readings on each PPK point to ensure you have it, since you do not have the RTK reassurance of seeing the data has been captured and the point quality.

Ideally this is true that you must have a base running in order to post process your rover data, but not necessarily. If your survey control is tied into the CORS network to begin with in a pinch you can download CORS data from the NGS site and use that data as a substitute for your base, assuming your rover observations are long enough commensurate with the distance to the nearest CORS. This has saved my bacon on more than one occasion when my base shut down unexpectedly or got blown over on another occasion. It's a good idea if going that route to make some ties to existing control as a check on your results. Logging base/rover data is SOP for me when I suspect I may have had some issues with my RTK solutions. It gives you the option of post processing that questions RTK data to get a better idea of what was going on at the moment the controller software came up with a solution. I'm sure you could do the same thing with data logged on receivers that part of your RTN system. Heck, one time I even used data being logged by geophysicists studying plate tectonics to post process my rover data in a remote part of Alaska where there were no CORS stations. Not ideal, but it worked.

Williwaw, post: 392381, member: 7066 wrote: Ideally this is true that you must have a base running in order to post process your rover data, but not necessarily. If your survey control is tied into the CORS network to begin with in a pinch you can download CORS data from the NGS site

Agreed, but it depends on where in the world you are. Presumably the USA stations supply data at 1 second intervals. In the UK the national reference system only supplies data at 15 second intervals

It varies from station to station here. I guess my point is sometimes you just have to be a bit creative and think outside the proverbial box. Shorting observation times can sometimes come back to bite. Like taking only a 15 minute observation to process in OPUS. Better go at least 20 because with the terrain and latitude here, good chance a few minutes of that data are going to be useless.