RTPK and Tilt Compensator

[John Thompson]

I used J-Field PreRelease 3.0.10.398 for the first time today. The automatic starts on RTPK and the dN, dE and dU display of the RTPK solution are nice improvements. Kudos to the developers.

I notice the Collect Action screen now displays Confidence, Consistency, and Var. (Variety?) What does that number mean?

I also noticed that the RTPK solution does not seem to be corrected by the tilt compensator. I was shooting the base of several power poles today with the tilt compensator turned on and the RTPK solutions were consistently off in the direction that the rover pole was tilted. Looks like the DPOS PPK coordinates are also off that same distance and direction.

 

[Adam]

Correct, rtpk doesn't work with tilt compensation. The var number represents variety of signals. 0.75 or more with 4 constellation seems to be a good number for that setting from my testing so far.

 

[Mark Wheeler]

Do they plan on adding tilt compensation in the future? Seems practical.

 

[Darren Clemons]

Correct, rtpk doesn't work with tilt compensation. The var number represents variety of signals. 0.75 or more with 4 constellation seems to be a good number for that setting from my testing so far.

I noticed the var yesterday also. What criteria has to be met to get the number above 0.75? When it does get above that number there’s a green bar above the scatter plot. I’m assuming that is indicating some kind of “extra” confidence in the shot?

The ability to select the rtk or the rtpk right on the collect screen is a terrific addition! Once we get a first shot stored and collect a second, you can toggle that back/forth right on the screen and watch your dtl box and verify which one, if either, matches.

The green box and thumbs up at the bottom of the scatter plot is also very nice . I still think we are only seeing the spread of the horizontal and vertical in those final numbers though? I would like to see the differences between the final rtpk and rtk coordinates once the shot is completed.

The auto start rtpk after 2 minutes is great also, but with what I saw yesterday, it continues to try and refigure even as the session progresses. Once past 300 seconds, we’ve not gotten good results at all with rtpk as it bogs up with too much data. Maybe there could be a setting to stop doing rtpk after a certain amount of time?

I second what John said - kudos to the developers!! Great additions!

 

[Shawn Billings]

Darren,
Once the RTPK has a solution, the residuals between RTK and RTPK are shown where the RTPK progress bar was. After a few seconds, RTPK process starts again and you can not see the residuals until there is a new RTPK solution. The user can change the setting for when RTPK starts processing. For my work yesterday I set it to 30 seconds in medium canopy with terrific success.

A new version of the RTPK engine is soon to be released that will not bog down with longer raw data sessions. It will automatically break a long raw data file into smaller raw data files and process those smaller files and compare the solutions. This has been demonstrated in testing to provide much, much more reliable fixes in post processing (very similar to our verification process that compares multiple fixes to find a consensus on the correct solution).

The variety number builds on the fantastic observation users have noted with multi-constellation data that two fixed engines in agreement point to a very likely correct solution without the necessity of time that our previous verification process required with GPS and Glonass only data. The variety number is used to rate the difference in the engines that have provided fixed solutions to the current position. I'm not exactly sure what the value represents and I'm not entirely sure after thorough testing that it will remain in view for users. Once we know a minimal, reliable value, perhaps it will simply be hard coded and replaced with a thumbs up or something similar to let the user know the RTK solution is verified based on two or more engines using significantly different signals.

Lastly, we've been discussing the merits of averaging RTK and RTPK solutions (when both are within a specified tolerance) to reduce coordinate clutter and perhaps improve precision. From the testing so far it sounds like an appropriate and useful approach. This has not yet been implemented.

 

[Nate The Surveyor]

Minor complaint: I don't get dist to last, until 2 minutes on a particular shot. This is due to "prefer RTPK". Since RTPK is not available until it has enough data for this.
And, since toggle for prefer RTK vs RTPK does not become active until both are available.
Suggest: It uses RTK always, regardless of toggle for RTK vs RTPK. And, that toggle be active at all times. But, maybe I'm jumping the gun here... I'll bet that you've already thought of that, and have a better solution than mine.
Thank you,
Nate

 

[Michael Stazhkov]

Minor complaint: I don't get dist to last, until 2 minutes on a particular shot. This is due to "prefer RTPK". Since RTPK is not available until it has enough data for this.
And, since toggle for prefer RTK vs RTPK does not become active until both are available.
Suggest: It uses RTK always, regardless of toggle for RTK vs RTPK. And, that toggle be active at all times. But, maybe I'm jumping the gun here... I'll bet that you've already thought of that, and have a better solution than mine.
Thank you,
Nate

Nate, please disable in Action profile -> Options -> Prefer RTPK Solution. This "Prefer ..." toggle button use this setting for default value.

 

[Darren Clemons]

Darren,
Once the RTPK has a solution, the residuals between RTK and RTPK are shown where the RTPK progress bar was. After a few seconds, RTPK process starts again and you can not see the residuals until there is a new RTPK solution. The user can change the setting for when RTPK starts processing. For my work yesterday I set it to 30 seconds in medium canopy with terrific success.

A new version of the RTPK engine is soon to be released that will not bog down with longer raw data sessions. It will automatically break a long raw data file into smaller raw data files and process those smaller files and compare the solutions. This has been demonstrated in testing to provide much, much more reliable fixes in post processing (very similar to our verification process that compares multiple fixes to find a consensus on the correct solution).

The variety number builds on the fantastic observation users have noted with multi-constellation data that two fixed engines in agreement point to a very likely correct solution without the necessity of time that our previous verification process required with GPS and Glonass only data. The variety number is used to rate the difference in the engines that have provided fixed solutions to the current position. I'm not exactly sure what the value represents and I'm not entirely sure after thorough testing that it will remain in view for users. Once we know a minimal, reliable value, perhaps it will simply be hard coded and replaced with a thumbs up or something similar to let the user know the RTK solution is verified based on two or more engines using significantly different signals.

Lastly, we've been discussing the merits of averaging RTK and RTPK solutions (when both are within a specified tolerance) to reduce coordinate clutter and perhaps improve precision. From the testing so far it sounds like an appropriate and useful approach. This has not yet been implemented.

Shawn, where do we go to change the default setting for when rtpk starts automatically?

 

[Adam]

verify settings, boost verify, upper left.

 

[Shawn Billings]

 

[John Thompson]

rtpk doesn't work with tilt compensation

Now that the software checks for agreement between RTK and RTPK results, this has become more important. I hope correction for tilts for RTPK is in the works.