PPK: CORS Sampling Rates vs. Reach Logging Frequency

[RTK_Hunter]

PPK question. Using Reach M on fixed-wing. Logging set to 14hz GPS only. My local CORS stations are generally 5 second sampling rates. When I go to PPK my 14hz log, RTKLib interpolates between CORS sampling points and Reach log right? I haven’t post-processed the 14hz log but just got me thinking. I know generally it works just fine for PPK on UAV so probably more a question on how RTKLib resolves/interpolates the difference in CORS rates and Reach .pos sampling rates. Is there a threshold in PPK where you can only resolve as well as the base station data allows?

I setup a separate Reach RS+ as a base station and logged only GPS at 14hz as well. My assumption was I could resolve this location statically and have 14hz sampling rate to PPK against my Reach M log on fixed-wing also logging at 14hz. Overkill or good practice in this situation?

[chascoadmin]

If you have a base I don’t know why you would ever use CORS. All the base is used for is corrections. On construction site we localize by setting it up in the most convenient place, let it establish coordinates and checking in to the other points if we need GCP’s.

My best results have come from base @ 1hz gps-only and rover (drone) and 14hz gps-only with 3 GCP’s. If you accurately measure your setup you can collect GCP’s with your drone as a rover. I am experimenting with 10hz and additional constellations - which I think will be even better, but am having some event capture issues at the moment so I can’t be sure. I have been processing in estimation of the full track instead of the events file and it has sufficed well.

[RTK_Hunter]

If you have a base I don’t know why you would ever use CORS. All the base is used for is corrections.

I need to tie project to some reference, most often NAD83. I rarely am at a site for more than a day so no coming back after PPK and usually have no known points nearby to place base over and enter manually.

If you accurately measure you setup you can collect GCP’s with your drone as a rover.

No need, have another Reach RS for my rover. This is partly why I use a Reach base as I am usually collecting other data before/after flight or when feeling froggy at the same time

I still got some dialing in to do on UAV system settings so I’ll try out as you suggest, thanks. My question was more oriented towards the inner workings of RTKLib and how handles differences from CORS and Reach sampling rates, specifically when in the 14hz range.

[TB_RTK]

I dont think you will see better result with faster update rate on a static base. In the RTKlib manual it describes moving rover at 20Hz and Base (VRS) at 1Hz.
Rover at 14Hz limits satellite systems to be used, therefor its important to use the ones you have wisely.
Enable Rec dynamic will add velocity and acceleration states to the kalman filter.
Also keeping the distance to base to recommende values is a key. Pushing the distance here will affect the accuracy and making it more difficult to resolve a FIX.
With L1 i think having a base on the ground is the way to go for highest aerial PPK accuracy.

[TB_RTK]

specifically when in the 14mhz range.

now thats some high end gear

[RTK_Hunter]

specifically when in the 14mhz range

Woops… Shh new units on beta from Emlid

I dont think you will see better result with faster update rate on a static base. In the RTKlib manual it describes moving rover at 20Hz and Base (VRS) at 1Hz.
Rover at 14Hz limits satellite systems to be used, therefor its important to use the ones you have wisely.
Enable Rec dynamic will add velocity and acceleration states to the kalman filter.
Also keeping the distance to base to recommende values is a key. Pushing the distance here will affect the accuracy and making it more difficult to resolve a FIX.
With L1 i think having a base on the ground is the way to go for highest aerial PPK accuracy.

This is helpful, thanks. It wasn’t clear to me if I were logging more data on rover at 14hz if it would require me to feed more base data during post-processing to produce a better result.

I have generally always enabled recorded dynamics in RTKPost as I have almost always PPK’d my rover against my own base on a relatively short baseline. Nothing statistical but seems to resolve better, makes sense giving RTKPost more data.

If also relying on one constellation (GPS @14hz) I would think one would want to be cognitive of satellite quality and atmospheric conditions when plan to operate. Probably of equal importance to resolve a FIX for entire flight @ 14hz.