A Javad dream place.

[Cody Jones]

There currently is an option to record data that won't be associated with a point using the "Start Continuous Recording" option found after clicking the GNSS Data Recording white box option.

View attachment 5351

This data won't be processed with DPOS since it's not associated with a point.

Yes but a point cannot be stored without stopping the static file. We were locating a few corners next to a new road with moderate to heavy canopy. I located them using a twenty minute static. A couple of days later my boss located the same one with RTK; and there was a significant difference. So I went out to reobserve the points again for another twenty minute static. I thought that I could start the static file with the start continuous recording button (record GNSS unchecked). While it was recording data I was going to locate the points with RTK; or so I thought I was to be able to compare the RTK values with the post processed. I set the LS to auto restart three times. The one point that was out in the open did go through the three shot routine but I had three three to four minute static files. If the LS did not record a point then I did not have a static file. I was hoping to be able to compare the values against each other as just another check in the moderate canopy environment. It may be a flawed way of thinking, (and let me know if it is), that if a couple of verified RTK shots over a shorter period of time agree, would it not be nice to have a static file that covers the entire time the LS is one the point and not just for one shot.

 

[Nate The Surveyor]

"It would be Nice..."
how to integrate that into the point numbers, and data flow, and make it FUNCTIONAL, and USEFUL is a bit challenging. But, I agree we want it.

 

[Matt Johnson]

2.) Distance Distance intersection, in stake out.

Andrey simplified the process of staking offset points created from the CoGo functions. Now the "Offset" white box has an option to "Stake created point" when it is called from the Stake Action screen:

 

[Nate The Surveyor]

What if there were an option to SET the point number, and description, of the static shot, which is available at the time the static file is initiated? And, if we start walking, with it running, it alarms, and flashes "Static file still running, Terminate Static file? Y/N?" This way, we would have full control of that static file, in the field. Thinking out loud here....

 

[Randy Rhodes]

"start continuous recording" needs to be able to assign a point number, both for post processing or for dpos.

 

[Matt Johnson]

What if there were an option to SET the point number, and description, of the static shot

The method to do this is by setting the Action Profile to Standalone and/or the Position Accuracy to Accept All. Then static data can be collected and associated with standalone points in J-Field. If you want a single solution from multiple observations, I still believe the correct method is to flag these data files so they are treated as an observations from a single site when processed by DPOS.

 

[Nate The Surveyor]

What I'm talking about is a method to simply, and painlessly do rtk, non exclusive, multiple shots, with ppk running in the background, ONE ppk observation. That processes with dpos.
N

 

[Cody Jones]

What I'm talking about is a method to simply, and painlessly do rtk, non exclusive, multiple shots, with ppk running in the background, ONE ppk observation. That processes with dpos.
N

Thats exactly what I was trying to say.

 

[Matt Johnson]

What I'm talking about is a method to simply, and painlessly do rtk, non exclusive, multiple shots, with ppk running in the background, ONE ppk observation. That processes with dpos.
N

The biggest problem I see is that this would not solve the problem of combining raw data collected from multiple observations when the observations are not back to back. What is the main reason that you don't just increase the duration of the RTK point in lieu of averaging multiple back to back points together?

 

[Nate The Surveyor]

Well, Matt, a single PPK file, 20 minutes long, is better than 3 ppk files, with 6-7 minutes each. At least, we are led to believe that... from past experiments. And, we want to GRAB the RTK shots that look good, while that is happening, for immediate purposes, especially for computing off of, for further searching. And, we want to use the 20 minute single PPK file for the plat later, as it has the stronger coordinate.
N

 

[Shawn Billings]

I once thought that I would prefer a single 20 minute file over three 7 minute files, but as I've used this more, I think in most cases, I would prefer the three 7 minute files, except under the worst canopy situations. The reason is this: I have no redundancy in the single 20 minute solution from DPOS. I've seen enough bad fixes reported in extremely hostile GPS environments from DPOS that I would not trust it without some redundancy. Three 7 minute files will give me a check on the (hopeful) fix from DPOS. Typically DPOS does very well, but it can give a false fix that can only be identified by a repeat observation.

 

[Adam]

Thats true Shawn. In really bad environments the RTK points may not be worth much, so you really need two static files for comparison.

 

[Matthew D. Sibole]

I totally agree with Shawn here.

 

[Matt Johnson]

I know Javad and Alexey strongly disagree with dividing static files. My preference is still to post-process the full observation but then have an option for longer files (> 10 minutes) to subdivide it into 3 sections which would be processed independently for comparisons to the solution from the full observation.

 

[Alexey Razumovsky]

Has somebody seen wrong fixed CORS solution with small residuals in DPOS report? If so then put the report here.

 

[Matt Johnson]

Alexey, if J-Field DPOS was to submit 2 files with the same "marker name" to the server would it treat them as a single site and process them together? I'm just curious what needs to be done to support using a multiple observations for a single site.

 

[Alexey Razumovsky]

1. Yes for Justin, if interfiles time gap does not exceeds preset threshold. No for DPOS as number of submitted files should be equal number of points(J-field vs DPOS restriction).
2. To support dposing multiple observations we need to modify J-field.

 

[Matt Johnson]

1. Yes for Justin, if interfiles time gap does not exceeds preset threshold. No for DPOS as number of submitted files should be equal number of points(J-field vs DPOS restriction).

How does Justin handle them when their is a time gap between observations?

 

[Alexey Razumovsky]

Justin merges files with identical receiver ID that satisfied time gap criterium.

 

[Shawn Billings]

Has somebody seen wrong fixed CORS solution with small residuals in DPOS report? If so then put the report here.

My examples of wrong fixes have not been CORS it has been base>rover giving a bad fix in bad environments.