First Test of the Triumph-LS Plus: Real World Productivity Increased by 310%

Matthew D. Sibole

Well-Known Member
5PLS
This was a screen shot of today’s test with the LS+. I am trying to dial down settings to see where it will end up storing a bad shot. On this test it still did not store a bad shot. It ran for 5 hours 50 min. It stored 148 shots. It had an average of just under 2 minutes per shot.

I am super impressed and am so glad I upgraded my LS.

F7F3C15C-6779-4856-BB3D-CB7DE5036031.jpeg
 

Matt Johnson

Well-Known Member
5PLS
This was a screen shot of today’s test with the LS+. I am trying to dial down settings to see where it will end up storing a bad shot. On this test it still did not store a bad shot. It ran for 5 hours 50 min. It stored 148 shots. It had an average of just under 2 minutes per shot.

I am super impressed and am so glad I upgraded my LS.

View attachment 9898

If you haven’t done so yet please try processing with DPOS, choose the PPK solutions and then run the survey statistics screen again to see how it compares.
 

Matthew D. Sibole

Well-Known Member
5PLS
I ran the points through DPOS and only had 1 point that came back that held the DPOS position. It was a bad fix. I had many other points that did not agree RTK-PPK. If I chose PPK for all points the statistics are terrible. Even the 50% is 2.81'.
 
Last edited:

Shawn Billings

Shawn Billings
5PLS
I have found DPOS with multi constellation is much more robust than DPOS with GPS + Glonass only, and that the time required for an RTK position under canopy with GPS + Glonass only is usually enough for multi constellation DPOS to get a good solution. Since you are running LS+ high-performance 4 engine RTK, I'm sure it's outrunning what DPOS can do even with four constellations.
 

Matt Johnson

Well-Known Member
5PLS
Since you are running LS+ high-performance 4 engine RTK, I'm sure it's outrunning what DPOS can do even with four constellations.

I don't think this should be the case or expectation. The same data is being processed with both RTK and DPOS but DPOS has the benefit of being able to examine the data at one time where RTK is epoch by epoch. I agree with Javad that the post processed solutions should always be better.

Matt, I would also try the Justin 2 engine on the Debug server to see if it works any better for your data.
 

Shawn Billings

Shawn Billings
5PLS
V6 RTK performance has, with very few exceptions, always been superior to DPOS post processing. I agree with the theory that PPK should be better than RTK, but it has not demonstrated in my practice. I have found that MSM PPK has been superior to GPS + GLO RTK.
 

Alexey Razumovsky

Well-Known Member
JAVAD GNSS
5PLS
I ran the points through DPOS and only had 1 point that came back that held the DPOS position. It was a bad fix. I had many other points that did not agree RTK-PPK. If I chose PPK for all points the statistics are terrible. Even the 50% is 2.81'.
DPOS deals about 30% of outliers on your project. All of them are 5-15 epoch solutions. DPOSed rover files are too small. In a case like this (middle canopy) PPK needs 1-2 minutes long observation.
Conclusion: your survey profile does not correspond well to DPOS.
 
Last edited:

Matthew D. Sibole

Well-Known Member
5PLS
I knew it would not be. I ran this test on Michaels settings to see if I could reproduce his results in my location. Not quite as good as Michael's but still impressive.
 

David M. Simolo

Well-Known Member
V6 RTK performance has, with very few exceptions, always been superior to DPOS post processing. I agree with the theory that PPK should be better than RTK, but it has not demonstrated in my practice. I have found that MSM PPK has been superior to GPS + GLO RTK.
I am using a T3 base and T-LS rover, mostly 4 constellations/2 engine firmware the last month. I have been quite impressed with the RTK performance but the PPK results are often contradictory by several feet, even on some 10 minute plus occupations in various degrees of no-leaf canopy. I would say that my field procedures have confirmed the RTK DPOS results and disproven the PPK DPOS results on many such instances.
Below are screen shots of 3 examples from yesterday. I had to manually select the RTK version for point no. 800011
 

Attachments

  • 20200506-08.49.55_00222_Processed_Point_Info.png
    20200506-08.49.55_00222_Processed_Point_Info.png
    74.9 KB · Views: 326
  • 20200506-08.50.23_00222_Processed_Point_Info.png
    20200506-08.50.23_00222_Processed_Point_Info.png
    78.4 KB · Views: 330
  • 20200506-08.50.55_00222_Processed_Point_Info.png
    20200506-08.50.55_00222_Processed_Point_Info.png
    76.3 KB · Views: 313
Last edited:

Nate The Surveyor

Well-Known Member
I'm using a t2 on base. And old LS board, (not upgraded).
Most of the time, the PPK agrees with RTK.
I have found that if rtk struggles, ppk struggles more. RTK in marginal places is more consistently correct.
So, maybe the increase in RTK performance, via the new constellations, has increased the difference between rtk and ppk.
 

Shawn Billings

Shawn Billings
5PLS
I am using a T3 base and T-LS rover, mostly 4 constellations/2 engine firmware the last month. I have been quite impressed with the RTK performance but the PPK results are often contradictory by several feet, even on some 10 minute plus occupations in various degrees of no-leaf canopy. I would say that my field procedures have confirmed the RTK DPOS results and disproven the PPK DPOS results on many such instances.
Below are screen shots of 3 examples from yesterday. I had to manually select the RTK version for point no. 800011

Make sure that you are not using Debug server. It's GPS and Glonass only at the moment and the standard DPOS is multi constellation.
 

Tyler

Member
What boundary settings have those of you with the TLS+ been using recently for best results? Our TLS+ seems to be taking a while to get a fix in areas that seem pretty open. I'm wondering if I have a setting wrong somewhere. (I'm also using a 1-M Base)
 
Top