Option to restrict DPOS to only use GNSS basestations

[Steve Reutebuch]

We are using TR2 units to get approximate coordinates for forest inventory plots. These plots are always in areas of heavy tree canopy and very high multipathing. We have found through testing (against a circuit of hubs surveyed with a total station in a dense forest) that if we have 12 or more sats and we collect at least 15 minutes of static data at a point and then post-process with a nearby GNSS (GPS+GLONASS), that we can usually get point horizontal accuracy of approx. 1m, which is our target accuracy for forest inventory plots.

If we process the same plots with DPOS, often the majority of basestations that DPOS selects are GPS-only rinex. The solutions have much poorer accuracy (compared to processing in Justin using only GNSS basestations). This is likely because in DPOS, the GLONASS signals aren't used in the GPS-only basestation solutions and the number of sats drops to the point where multipaths are not being detected and removed, resulting in poor solutions.

Would it be possible to add an option to DPOS that allows the user to specify that DPOS only use GNSS (GPS+GLONASS) basestations in solutions?

I'm attaching an example DPOS output for a 15 min static occupation (T6P6jps) that illustrates this issue.
The GPS-only basestations only use 9 sats in solutions; whereas, the GNSS basestations use 15-17 sats. The horizontal error for T6P6 is 5.79m. When I process the same file in Justin using only GNSS basestations and a cut off mask of 20 degrees , the error is 0.60m.

 

[Matt Johnson]

Hi Steve, I notice that you are only recording 30 second data. Many of the stations around you log data at 1 second intervals so I would suggest you record data at 1 Hz as well to see if that helps your solutions.

 

[Steve Reutebuch]

We log 1 sec data on the rover, but the rinex file that DPOS automatically downloads for the selected basestations is 30 sec rinex data. In Justin, these 30 sec basestation files are interpolated to 1 sec data during processing so that my 1 sec data is fully utilized in the solution. I am assuming that DPOS also interpolates the basestation data to 1 sec intervals, but would like to have this confirmed by Javad.

 

[Kelly Bellis]

Hi Steve,

This is one of those areas where I don't think there are hard numbers. At 15 minutes, the question becomes more vividly into the foreground in regards to recording preferences. I'm inclined to think that 15-minute occupations would benefit from shorter intervals between recorded epochs than 30 seconds.

How did you determine that the recorded 30 epochs were being interpolated by Justin into 900 epochs?

Addressing your point second paragraph, presently, the DPOS user is not able to overtly pick and choose which CORS to use like you can in Justin or other softwares. While I also share your desire for such functionalities, the automated selection by DPOS of relevant CORS has and continues to be improved. This has largely been from the perspective of the JField version of DPOS.

 

[Steve Reutebuch]

Hi Kelly--I think you mis-read my previous post: We record 1 sec data on our field rover units. But, the CORS rinex data that DPOS (and Justin) automatically download has 30 sec epoch. This is not a problem because Justin and DPOS automatically interpolate the 30 sec rinex into 1 sec intervals so that all the rove 1 sec data can be used in the solution. We record 1 sec data on the rovers because in a heavy canopy environment, the chances of getting a few consecutive epochs of data with at least a majority of signals (using both GPS and GLONASS sats) that are not multipathing is greater with 1 sec data. We're only shooting for +/-1m horz accuracy on our post-processed occupations.

If the post-processing software throws away all the GLONASS signals (because it allow use of GPS-only basestations), then the post-processed position is usually greatly degraded in heavy canopy areas (errors of 5 m or more). So, for our application (getting forest inventory plot positions with accuracy of +/-1m horz), we must always limit our basestations to those that have GLONASS data. Without the option in DPOS of limiting basestations to GNSS (GPS+GLONASS), we can't reliably use DPOS, expect for in open areas.

 

[Matt Johnson]

In your DPOS report I saw that only 385 observations were used. When I submit 1 second files to DPOS I typically see many more observations being used. I'll see if Alexey can answer your questions.

 

[Steve Reutebuch]

The rover file T6P6.jps has 960 1 sec epochs in it. It is in an area of heavy canopy (we are mapping forest inventory plots) so it is likely that many of the epochs were discarded, although when I processed this file in Justin 2.111.149.6, the Fixed Ratio was 100%.

 

[Alexey Razumovsky]

Hi Kelly--I think you mis-read my previous post: We record 1 sec data on our field rover units. But, the CORS rinex data that DPOS (and Justin) automatically download has 30 sec epoch. This is not a problem because Justin and DPOS automatically interpolate the 30 sec rinex into 1 sec intervals so that all the rove 1 sec data can be used in the solution. We record 1 sec data on the rovers because in a heavy canopy environment, the chances of getting a few consecutive epochs of data with at least a majority of signals (using both GPS and GLONASS sats) that are not multipathing is greater with 1 sec data. We're only shooting for +/-1m horz accuracy on our post-processed occupations.

If the post-processing software throws away all the GLONASS signals (because it allow use of GPS-only basestations), then the post-processed position is usually greatly degraded in heavy canopy areas (errors of 5 m or more). So, for our application (getting forest inventory plot positions with accuracy of +/-1m horz), we must always limit our basestations to those that have GLONASS data. Without the option in DPOS of limiting basestations to GNSS (GPS+GLONASS), we can't reliably use DPOS, expect for in open areas.

DPOS service was designed for surveying particularly. We do not plan do extend functionality of free service. In the meantime we are going to extend web inteface with 'Exclude list' of CORS stations.

 

[Alexey Razumovsky]

The rover file T6P6.jps has 960 1 sec epochs in it. It is in an area of heavy canopy (we are mapping forest inventory plots) so it is likely that many of the epochs were discarded, although when I processed this file in Justin 2.111.149.6, the Fixed Ratio was 100%.

Fixed Ratio isn't relable in environment you pointed. If post-processing engine discards a lot of measurements then it will increase Ratio. Good solution is a solution with a Ratio 95-100% and 1-5% discarded data.

 

[Steve Reutebuch]

Thank you Alexey for the advice on using float (rather than Auto) solutions when post-processing occupations under heavy canopy. Also, being able to simply exclude CORS basestation that don't have GLONASS in DPOS would be great.

 

[Alexey Razumovsky]

Thank you Alexey for the advice on using float (rather than Auto) solutions when post-processing occupations under heavy canopy. Also, being able to simply exclude CORS basestation that don't have GLONASS in DPOS would be great.

1. GLONASS data aren't worse then GPS ones in 'Code' or in 'Float' modes. 'Float' mode brings more accurate position. 2. DPOS is ready do accept 'Exclude list' of CORS. We are waiting for web interface.

 

[Kelly Bellis]

Cool!