Observation time vs sample rate for q=1 fix

Hi all,
When wanting to obtain a q=1 fix using RTKpost, what is most important (given that the dataset has good data):

  • Observation time
    or
  • Sample rate

I currently use a stop-and-go workflow to make sure I have enough time in the beginning of the raw file for a fix to correlate.

I would say observation time.

If you record raw from start to the end (and not stop logging in between) for the entire job, you should have backup and enough data i think

What do you propose to use for backup ? This did indeed come to mind when I was collecting data, but I just didn’t see a way.

What is your scenario for the job, RTK or PPK (gnss setup) ? where are you working and for how many minutes/hours?

Jobsite is at a factory, moving between dusty stockpiles. 300x70 meter area.
PPK, as the site is difficult skyview-wise/building wise. Spending ~15 minutes on each point. 10 points in total.

Do you have a second RS for base or using public service?

Edit: And its survey and not RTK stakeout?

Yep, base and rover setup with RS+ (the files you got from the VRS thread actually), so I can keep the baseline to a minimum.

Edit, yep, survey, placed points on the ground, that needed to have known coordinates for photogrammetry.

Good.

Either way i do a job, start logging on rover and dont turn if off before your are completely done. Also turn on base if you have one and log correction info too.

With ntrip VRS or local public ref.station
For survey i would do similar. Like your situation when having to work in difficulty areas, a base nearby can make a difference. Even if you have a VRS service to do RTK survey, a base can provide additional info for a L1 reciver, also adding more satellite system to work with.

If you have VRS service, an option is to see if you can get fix. Then you would save time by skipping the base part. But experiencing fix issues, placing the base nearby in a better place and use VRS to fix base and have rover work from base instead.

PPK or rapid static with no realtime correction
Put up your base and start logging raw and output correction to rover.
Start rover and raw logging + input correction from base for RTK. Try getting fix in difficult areas with rover, you are now working RTK and relativ to base but we will fix absolute coordinates later.
If fix is possible, use Survey mode and collect points as usual. Points in survey mode is ONLY relative to base. To get your points absolute you could:
1.Use time when a point is collected and create point in postprocess at the same time
2.Have base adjusted from average single to absolute and adjust all points collected in survey accordingly in e.g excel spreadsheet. Use UTM grid or similar cartesian coordinate system with XYZ.

A third option if you are not getting fix. Change to static when you have put your pole with tripod over a point, have it monitored to see if a fix is possible: if still not possible to get fix, increase the time as long as you can.
In the meantime you can lookup satellite predictor and see if there is a better satellite geometry later
http://satpredictor2.deere.com/

To process your base with raw.ubx to absolute world coordinates, you can use rapid static (like i showed in seperate post) or use a single refrence station nearby and do a ordinary static post processing with files from refrence station downloaded afterwards

Edit:
For critical points, resurvey at least two or three times with 15-20min apart to rule out bad fix.

3 Likes

Awesome ! Thanks !

I had actually used a predictor (factoring in different obstructions at the different points), printed out graphs, and spent time on planning in which succession I should take the points. But, as with all great plans, they only seem to last until the first encounter with reality: upon arrival at the site, my contact couldn’t get me to my preferred roof base placement until an hour later, and my plan went haywire quite quickly. Well well!

This topic was automatically closed 100 days after the last reply. New replies are no longer allowed.