Default DPOS Configuration

[Kelly Bellis]

RE: JField v2.0.0.219

Could somebody please provide details describing the differences in the three Base-Processing Options and why the default selection is made? And yes, I know Shawn made a video and that between minutes 9 and 12 he goes over some of this, but he sounded quite tired and even though I've watched it multiple times, I'm not entirely certain of the distinctions between the last two choices as I've always equated DPOS processing to always being CORS-Processed, or at least past DPOS Reports would have me believe.

 

[Matt Johnson]

See if this answers your questions:

 

[Kelly Bellis]

Not quite yet.

For starters, the language displayed on the LS screen and that which you've pasted in your reply don't match (yes, I'm anal, and I own it). Inconsistent language is agar for my confusion.

• I would have assumed that Base-Processing only meant that DPOS was only processing the base utilizing its selected CORS and that none of the vectors related to the rover were being fiddled with, just as DPOS has in the past. The pasted bit implies that there isn't any CORS involved in this choice. But then I can't understand WTF is getting processed by DPOS if CORS isn't involved. The pasted bits also seem to indicate that point positions collected by the rover are somehow being effected. With this selection, I would have also assumed that base position remains in its previous position, autonomous or otherwise, not shifted, allowing the user to evaluate the differences before pulling the trigger, again same as DPOS past.
• Base-Processing + Base Shift, again would be assumed to mean to choose for JField to go ahead and reposition the base to its freshly derived DPOS adjusted location; pulling the trigger. It would also have been assumed that all of its associated RTK gathered points would be similarly moved respectively with the new base position. The pasted bits use the acronym CORS while its absence in the pasted bits section above it has me scratching my head.
  
• Base-Processing + CORS-Processing + Base Shift, this was what prompted this thread and I think that your pasted bits reveal the salient: RTK points with sufficient Raw GNSS Data will also be uniquely processed by DPOS using its selected CORS and if this understanding is correct, shouldn't the check box for Process all Points with raw GNSS files be automatically checked?

 

[Shawn Billings]

But then I can't understand WTF is getting processed by DPOS if CORS isn't involved.

Exactly what the "pasted bit" explicitly says "base-rover vectors are processed".

 

[Matt Johnson]

For starters, the language displayed on the LS screen and that which you've pasted in your reply don't match (yes, I'm anal, and I own it). Inconsistent language is agar for my confusion.

I intentionally did not want it to match the options so I wouldn't have to repeat the same "Base-Processing" explanation three times. I updated this to clarify more:

 

[Kelly Bellis]

But then I can't understand WTF is getting processed by DPOS if CORS isn't involved.

Exactly what the "pasted bit" explicitly says "base-rover vectors are processed".

Even if the check box for Process all Points with raw GNSS files isn't checked?

 

[Shawn Billings]

Then points that "MP" marked for post processing are processed only. These would be points that were collected using the APP (activate post processing) feature. In this case a user may not have communications, and has not implicitly set the LS to record raw data for every occupation, but has Activate Post Processing turned on. This was what I did in the example in the video. It's possible that the user only wants to process these points (sort of a fill-in) and not every point with raw data.

 

[Kelly Bellis]

I intentionally did not want it to match the options so I wouldn't have to repeat the same "Base-Processing" explanation three times. I updated this to clarify more:

View attachment 4635

So, am I understanding this first option Base-Processing only correctly, that DPOS is no longer necessarily involved with utilizing CORS?

 

[Shawn Billings]

That's the whole point of Hybrid RTK. Processes from base to rover. The first option is the setting for processing from base to rover.

 

[Kelly Bellis]

Then points that "MP" marked for post processing are processed only. These would be points that were collected using the APP (activate post processing) feature. In this case a user may not have communications, and has not implicitly set the LS to record raw data for every occupation, but has Activate Post Processing turned on. This was what I did in the example in the video. It's possible that the user only wants to process these points (sort of a fill-in) and not every point with raw data.

That's maybe a good point to include mentioning, if it isn't already, in Matt's "Quick Start Guide to The Triumph-LS with J-Field 2.0" It sounds wonderful and I look forward to trying it soon. Where did you say APP gets turned on?

 

[Shawn Billings]

Action Profile Setup (press the compass button on action screen or press bottom middle button in Collect Prepare screen). You'll see the option on the bottom left. Turning APP on is like having an available backup if the RTK simply won't go to completion. While you are standing there, either not getting corrections or getting intermittent corrections, raw data is being stored. At any time the user can manually stop the collection and then accept the shot, storing the raw data for PP. If the shot goes to completion according to the user standards (epoch count, time, resets, validation, consistency) then the data is automatically deleted as the backup is not needed.

I tend to have What to Record: Raw GNSS Data, turned on for all boundary and control points and I tend to process all points with raw GNSS data. This way I always have the backup and I can compare the RTK and PPK solutions to give an added measure of confidence to my points.

 

[Kelly Bellis]

Thank you Shawn. Now I recall, you mentioned this in your video too, I believe. This feature will be genuinely appreciated in these dense woods around here. Sometimes I've waited to throw in the towel for over an hour or more... and bugger, it is usually after fulfilling setup mandates met, all but for the validation at the tail end of the observations.

And just to be clear, the minimum period required by DPOS to post-process raw GNSS data from RTK points is 5 minutes, is that correct?

And secondly, the configurations screen could make the user wonder if that time spent meeting the minimum (first) 5 minutes or whatever length they've selected), and when the user has not previously and overtly chosen to record GNSS data, whether or not the observations before count? Or in other words, is raw GNSS data always being recorded in a temporary cache?

 

[Shawn Billings]

The data is collected immediately upon Start, so all of the time you are standing there waiting for RTK, the LS is collecting raw data (when APP is activated or when What to Record:Raw GNSS Data). Also, DPOS can process files of any duration even a few seconds. The five minute mark is a minimum recommendation, but I often process raw files that I recorded for 3 minutes. I've processed much short (1 minute) for baselines of 2.55 miles.