What happens in DPOS with multiple Base Station Observations?

Kelly Bellis

ME PLS 2099
5PLS
How do multiple observation files on the same point that is used repeatedly as a Base Station and which are subsequently processed using DPOS (on the LS) get treated by JField with each successive processing and adjustment application on all collected RTK points?

In theory, one might expect or hope to see some benefit in having multiple Base Station observations contribute to the refinement of the Base Station's location.

To try and discover the answer to this question, first the unadjusted points were exported, then again after the first Base Station file was processed and the adjustment applied, and then lastly, after the second Base Station file was processed and the adjustment applied. The results seemed to indicate that no adjustment was made until the last Base Station file had been processed.

This lead to the question: What happens in DPOS with multiple Base Station Observations?

Tangential question: Which coordinate value should be used for the Base Station on subsequent occupations, or does it matter?

Code:
DPOS WORKFLOW NOTES
11:19 AM   Sunday, February 21, 2016  (VKB)

OBS Day1: 02042016
OBS Duration: 07:17:00
Base Station: GNSS1-01
Coordinate Value: From Auto


OBS Day2: 02192016
OBS Duration: 03:18:30
Base Station: GNSS1-02
Coordinate Value: From 02042016's used autonomous value


Processing Date: 02212016
LS-DPOS PROCESSING ORDER USED
Base Station GNSS1-01, processed first, adjustment applied
Base Station GNSS1-02, processed next, adjustment applied
 

Attachments

  • 1503Beal - ME2K PreDPOS.txt
    3.7 KB · Views: 318
  • 1503Beal - ME2k PostDPOS after 1st Base File.txt
    3.7 KB · Views: 291
  • 1503Beal - ME2k PostDPOS(2) after both Base Files.txt
    3.7 KB · Views: 350

Matt Johnson

Well-Known Member
5PLS
During a DPOS adjustment, any point collected with RTK from corrections from that base station session will be corrected. If you manually edit a point's base station coordinates from the Points screen, all RTK and base station points with that same base station origin coordinate will be adjusted.
 

Shawn Billings

Shawn Billings
5PLS
Hi Kelly,
Currently there is no automatic method for combining DPOS processed base files into one adjusted position and translating all rover points from those base sessions to the one supreme position. I hope that we get there. I think you are right that this would be most favorable.

It is possible to do this now manually using the tools in the LS, I believe. I believe that you could perform a cluster average of the various DPOS processed based positions. Then you could edit a point from each base session and change the base coordinates to the supreme position. In theory it would work, but I must confess that I've not taken the time to do it.

Typically, I will DPOS the base session from day 1 and adjust. Then on day 2, I use the DPOS result from day 1 to seed the base for RTK. At the end of day 2, I DPOS the base data from day 2. I usually just check the comparison and leave this session unadjusted. So I'm ultimately relying on day 1 for the project.

Good questions. And I still have some questions regarding multiple base sessions using the same coordinate that are subsequently DPOS'ed. I've done this before and found some mischief, but I haven't done it again since the issue was corrected.
 

Kelly Bellis

ME PLS 2099
5PLS
@ Matt - Okay, so in other words in answer to my first question, nothing collectively happens as each RTK session is treated separately. And in answer to my second question, it doesn't matter because LS-DPOS adjustments are handled on a session-by-session basis.

Manually editing (using the Edit Point, Type-in Position option) the Base Station's coordinates from the Points screen did nothing, even after the (supposed and ill-advised) deletion of the original coordinates for that Base Station, the RTK points that had been collected and that were associated with that particular session remained unaltered. Deletion of the original coordinate likely burns the bridge for undoing an adjustment. Could you please explain the procedure more fully?

@ Shawn - I guess then cluster-averaged base stations will have to do for now, even though the 8-hour session is given no greater weight than the 2-hour session. Averages notwithstanding, from what Matt albeit briefly explained, all sessions would need to be somehow manually edited to the same base station coordinate value.
 

Alexey Razumovsky

Well-Known Member
JAVAD GNSS
5PLS
How do multiple observation files on the same point that is used repeatedly as a Base Station and which are subsequently processed using DPOS (on the LS) get treated by JField with each successive processing and adjustment application on all collected RTK points?

In theory, one might expect or hope to see some benefit in having multiple Base Station observations contribute to the refinement of the Base Station's location.

To try and discover the answer to this question, first the unadjusted points were exported, then again after the first Base Station file was processed and the adjustment applied, and then lastly, after the second Base Station file was processed and the adjustment applied. The results seemed to indicate that no adjustment was made until the last Base Station file had been processed.

This lead to the question: What happens in DPOS with multiple Base Station Observations?

Tangential question: Which coordinate value should be used for the Base Station on subsequent occupations, or does it matter?

Code:
DPOS WORKFLOW NOTES
11:19 AM   Sunday, February 21, 2016  (VKB)

OBS Day1: 02042016
OBS Duration: 07:17:00
Base Station: GNSS1-01
Coordinate Value: From Auto


OBS Day2: 02192016
OBS Duration: 03:18:30
Base Station: GNSS1-02
Coordinate Value: From 02042016's used autonomous value


Processing Date: 02212016
LS-DPOS PROCESSING ORDER USED
Base Station GNSS1-01, processed first, adjustment applied
Base Station GNSS1-02, processed next, adjustment applied
Hi Kelly, LS offers three types of DPOS request. First is base submitting. In this case DPOS itself combines multiple files. Unfortunatelly it is not yet implemented in LS.
 

Matt Johnson

Well-Known Member
5PLS
Okay, so in other words in answer to my first question, nothing collectively happens as each RTK session is treated separately.

Yes

And in answer to my second question, it doesn't matter because LS-DPOS adjustments are handled on a session-by-session basis.

Yes

Manually editing (using the Edit Point, Type-in Position option) the Base Station's coordinates from the Points screen did nothing, even after the (supposed and ill-advised) deletion of the original coordinates for that Base Station, the RTK points that had been collected and that were associated with that particular session remained unaltered. Deletion of the original coordinate likely burns the bridge for undoing an adjustment. Could you please explain the procedure more fully?


In the released version of J-Field base, base station coordinates are modified from Base/Rover Statics screen by pressing the Base button. In J-Field 1.11.9.xxx the Edit points screen has been improved to allow base station coordinates to be modified by tapping on the box with their coordinates.

what Matt albeit briefly explained, all sessions would need to be somehow manually edited to the same base station coordinate value.

If the sessions all have the same base coordinate, then the base coordinate only has to be manually adjusted once at it will apply to all RTK points with that base station coordinate.
 
Last edited:

Jim Frame

Well-Known Member
The way I deal with this is to export gfiles and include them in a Star*Net adjustment. That way I can specify a single position for each unique base point, and all vectors from all sessions taken at that base point propagate from there. I realize this isn't an approach that will appeal to everyone, but it's a relatively simple and user-controlled process.
 

Alexey Razumovsky

Well-Known Member
JAVAD GNSS
5PLS
A least squares adjustment for all vectors from all sessions sounds good. Maybe Alexey can think about this for the LS-DPOS as well as the Firefox/IE/Chrome-DPOS.
My opinion is that idea to refine post process results outside DPOS is a nonsence.
 
Last edited:

Kelly Bellis

ME PLS 2099
5PLS
My opinion is that idea to refine post process results outside DPOS is a nonsence.
Such is the fabric of my life.PNG
 

Alexey Razumovsky

Well-Known Member
JAVAD GNSS
5PLS
DPOS is able now to adjust solutions with variance-covariance matrixes and deals final position. Should we provide LS users opportunity to refine position with multiple site occupations or this case is for Justin?
 

Matt Johnson

Well-Known Member
5PLS
DPOS is able now to adjust solutions with variance-covariance matrixes and deals final position. Should we provide LS users opportunity to refine position with multiple site occupations or this case is for Justin?

It would be good to have this feature in J-Field at some point I think.
 

Adam

Well-Known Member
5PLS
It seems any post processing software has no future in US. OPUS is absolute favorite.

I have never been found of OPUS, Over the past years I have compared OPUS to observations on the North Carolina Geodetic Survey's RTN. I decided a long time ago the the networks elevations were more reliable and took far less time. Horizontally, OPUS and the network are about the same. I used DPOS I forgot about OPUS .
 

Alexey Razumovsky

Well-Known Member
JAVAD GNSS
5PLS
I have never been found of OPUS, Over the past years I have compared OPUS to observations on the North Carolina Geodetic Survey's RTN. I decided a long time ago the the networks elevations were more reliable and took far less time. Horizontally, OPUS and the network are about the same. I used DPOS I forgot about OPUS .
I compared OPUS and Justin which is beside DPOS. I'd like to be aware of PC software future in US.
 

Joe Paulin

Well-Known Member
It seems any post processing software has no future in US. OPUS is absolute favorite.
Alexey,

OPUS is what we know here in the States, and it's free, hence contributing to it's popularity. That being said, I am very open to using DPOS, especially for it's ease of use. Javad static files and DPOS just make sense to me - automatic submission with auto recognition of things like antenna and antenna height, no need to convert to rinex, seamless integration and adjustment. This is great stuff! We are slow to come around - old habits are hard to break. I find my self checking DPOS results with OPUS results just as a lot of others do. Don't get discouraged, DPOS is fantastic!
 

Matthew D. Sibole

Well-Known Member
5PLS
DPOS is a great feature! As Joe stated, do not get discouraged. You guys are doing a great job and it is features like this that out Javad up and over the top of any other receiver on the market. Your responsiveness to our request are second to none and implementation is very fast. DPOS and Hybrid RTK are above and beyond expectations! They make my job easier! Keep up the great work!
 

Nistorescu Sorin

Active Member
This is a comparison between a 2 hour L1/L2 GPS+GLONASS postprocessing(1) and a 5min L1 GPS+GLONASS(2+3) at 9km, directly with a IGS station (similar with CORS), all done with Justin software using my 7" phablet in the field. The units are in meters.

I think many people will use DPOS.
 

Attachments

  • 1 Justin postprocess GPS-Glonass L1_L2 2hours.txt
    82 bytes · Views: 331
  • 2 Hybryd point 801 L1-only 5min.txt
    7.7 KB · Views: 386
  • 3 Hibryd point 802 L1-only 5min.txt
    7.7 KB · Views: 329

Jim Frame

Well-Known Member
I'd like to be aware of PC software future in US.

The market for desktop vector processing has never been very large, and with the proliferation of RTK (especially network RTK) it's gotten a lot smaller. However, the need isn't going to disappear anytime soon. Static observations are still required to get reliable height transfer over large distances, particularly when the results have to meet NGS specifications. OPUS only offers true station-to-station network processing via OPUS Projects, which requires 2-hour observations. We generally use 1-hour sessions for these projects, so relying on OPUS would more than double our observation time commitment (because of daily mobilization overhead), which is the largest cost component of these projects.
 
Top