Sudden Loss of Workable Fix in Open

Wes Cole

Active Member
Our crew working with the LS+ has reported the same issues all week, between the hours of 2-4 +/- they are having trouble getting any reliable data. Now, to be fair, they are working in some pretty terrible GPS conditions, however when trying to set some control in a fairly open road yesterday they struggled to get good data during this timeframe.
 

Adam

Well-Known Member
5PLS
Our crew working with the LS+ has reported the same issues all week, between the hours of 2-4 +/- they are having trouble getting any reliable data. Now, to be fair, they are working in some pretty terrible GPS conditions, however when trying to set some control in a fairly open road yesterday they struggled to get good data during this timeframe.
Send your projects to support and post the name of them here Wes. Any data we can send the team while the issue is happening will be helpful.
 

Nate The Surveyor

Well-Known Member
I believe that they should already not be used. You can check the satellite status screen and look for code 06 which means they are unhealthy and not used.

GAL 14 is visible now and already flagged unhealthy.
View attachment 11448
Is there a way for me to flag a sat as unhealthy?
To "just remove it from the solution"?
As our USA GPS satellites get older, I can see an ongoing need to do this.
What I'd REALLY like is a little utility that you set your rover in 100% sky view. Initiate "health check, and remove bad sats from equation". And, what it does is determine a good fixed coord for this out-in-the-open spot. Then it runs through some automated process to kick out any sats that disagree with this "true" solution.
I can see that there are sats all around the world. If one sat gets out of orbit, or for some reason is giving a bad solution, it is simply turned off.
Again, I don't know how effective this could be, and how much work this would take, but in my mosquito bitten way of thinking, this is needed, and will continue to be needed, as our satellites age, and their orbits are deteriorating.
Thank you,
Nate
 

Nate The Surveyor

Well-Known Member
We recently spent 20 min in an open space, waiting on a decent fix.
What if the health problem the sat has, is not known by the sick satellite?
Maybe the health monitor part is sick?
N
 

Matt Johnson

Well-Known Member
5PLS
The satellite heath status is determined by the people who operate the constellation. I don't think there is anyway a end user or some tool in a receiver can reliably determine a satellite is unhealth and should never be used. The firmware already searches for measurement outliers when then trying to determine what signals to filter out.
 

John Troelstrup

Active Member
The above discussion has me now checking satellite information frequently when having trouble acquiring a fix. The problem is I do not really know what I am looking at.
With the exception for SS code 6 meaning it is not healthy and used.
I sometimes have several 4s. What does 4 mean?

It appears that there is a load of info here and I would like to know what I am looking at.
I assume SS means Satellite Status.
What do the range of numbers mean?
What do the different colors mean?
Range of numbers?

Is there a resource that explains this. I want to become a user of the information available to me
John
 

John Troelstrup

Active Member
Thank you Matt. I will go play with that immediately.

I recently acquired new equipment that is fully uploaded to the RTPK and full satts.
Will the Help Hardware be a useful resource for helping me with my learning curve transition?
 

Alexander Khvalkov

Active Member
JAVAD GNSS
I have been analyzing the data of the three points: 2004, 2009, 2010 that were measured on June 14 and 15. Point 2010 locates at open sky, see please attached Google Map picture, and has 100% RTK fix on both the days. Point 2004 locates at a canopy and has poor fix on both the days, most probably because of the canopy. The most interesting is point 2009 because of big difference in performance of RTK: 15-th is much better, see attached. I am still in process of investigation and going to provide a report when be ready.

As for affect of Galileo, it does not seem to be probable, at least we did not notice such an effect, but maybe we need to run real time processing with reset of RTK permanently and to log 24-hour data permanently to post-process. Periodically, quite rarely, AltBoc signal might be wrongly locked by one or two satellites, and when SNR is low, but this can be treated by reset of tracking or switching AltBoc off.

If total number of signals in an engine does not reach the limit, about 35, it may happen if RTK itself throws out the signals from processing, but this is seen on the screen, or because of insufficient number of tracked satellites on rover or coming base's corrections, but all these are also seen on the screens.
 

Attachments

  • All_3_points.png
    All_3_points.png
    2.9 MB · Views: 179
  • pv.txt_localPlane.png
    pv.txt_localPlane.png
    66.1 KB · Views: 180
  • pv2.txt_localPlane.png
    pv2.txt_localPlane.png
    84.2 KB · Views: 173
  • pv2.txt_localPlane.png
    pv2.txt_localPlane.png
    100.2 KB · Views: 180
  • pv.txt_localPlane.png
    pv.txt_localPlane.png
    97.7 KB · Views: 190
  • pv.txt_localPlane.png
    pv.txt_localPlane.png
    86.7 KB · Views: 175
  • pv2.txt_localPlane.png
    pv2.txt_localPlane.png
    62.3 KB · Views: 170

James Suttles

Active Member
Slow time of day again. I have attached another project file from a completely different LS plus. The point that is completely out in the open is 9902SJ. It set and floated for several minutes and then finally collected the point.

Other Points that struggled were 9902SJ, under an apple tree, and 9906SJ is in about 80% open area.


Let me know if you are unable to download the project.
 

Mark Wheeler

Active Member
During either the East cost doldrum window or times of low sat count due to heavy canopy, is there a setting/setup to switch to that could automatically select from the best satellytes available at the time and put them all into one engine to hopefully bypass the down time for non-fixes? I realize this takes away from the whole 4 engine independence and variety, but to have another option for this time frame would be helpful (versus going back to the office).
 

Alexander Khvalkov

Active Member
JAVAD GNSS
We have been doing long tests observing quality of fix, namely such parameters as time-to-fix, number of used satellites, position estimated, etc. For this purpose, a Triumph-LS s/n #00188 (6-engine version), was set up on the factory's roof getting RTCM3 corrections from a base nearby. Four RTK engines were configured to work with only one satellite system: GPS, GLO, GAL, BEI. The fifth one - also with BEI but no AltBoc, the last one - GPS+GAL. The engines are configured to reset right after fix, set,/par/pos/pd/resetfix,y. The data are being logged at 10 Hz rate. Unfortunately we met problems with 24-hour logging because of periodical reset of FW, the reason is unclear yet, but what is seen from the data, there is no any peculiarity at about 2 - 3 PM Pacific Time. If you see the issue described above, please do such a test logging data capturing also 1 hour before and/or after the period to have an ability to compare.
 

Attachments

  • July_3_2021_timeToFixOnTime_Fragment.png
    July_3_2021_timeToFixOnTime_Fragment.png
    121.8 KB · Views: 160
  • July_3_2021_timeToFixOnTime.png
    July_3_2021_timeToFixOnTime.png
    95 KB · Views: 189
  • July_3_2021_nOfSats.png
    July_3_2021_nOfSats.png
    79.9 KB · Views: 181
  • July_3_2021_timeToFix.png
    July_3_2021_timeToFix.png
    48.4 KB · Views: 164
  • July_4_2021_timeToFixOnTime_Fragment.png
    July_4_2021_timeToFixOnTime_Fragment.png
    161.3 KB · Views: 165
  • July_4_2021_nOfSats.png
    July_4_2021_nOfSats.png
    79.8 KB · Views: 170
  • July_4_2021_timeToFix.png
    July_4_2021_timeToFix.png
    49.8 KB · Views: 168
  • July_4_2021_NumOfSatsOnTime.png
    July_4_2021_NumOfSatsOnTime.png
    76.8 KB · Views: 167
  • July_3_2021_NumOfSatsOnTime.png
    July_3_2021_NumOfSatsOnTime.png
    84.4 KB · Views: 158
Top