How does ReachView time-out ephemeris data?

thomas.purk · May 7, 2017, 5:28pm

We hope to use the Reach system for real-time GIS map making so the need for absolute accuracy makes this a concern.

Something I’ve noticed in RTKLIB on a Windows computer, is that the rtknavi.ini file caches satellite ephemeris data at the bottom of the file. I found this after getting some really bad results from some sample sets. I was finally able to track down the problem after spending a lot of time investigating the various streams in RTKMONITOR. The GNSS rover chip was piping over fresh observables but not fresh ephemeris data. The RTK base was piping over fresh observable.

Normally in this condition the compute logic (whether RTKLIB or “on-chip”) would simply not be able to calculate a solution of any kind because the ephemeris data is absolutely needed. But I found that RTKLIB extracted the weeks-old ephemeris data from rtknavi.ini file and computed a REALLY REALLY bad solution. This is a very worrying problem because the data collector in the field will likely not notice this and unknowingly record the data thinking it’s good when actually it’s very bad.

Not sure why this would happen, but my theory is that the GNSS Rover may be in a satellite reception area good enough to receive observation data but not good enough to receive good ephemeris data. I’ve read that satellites broadcast ephemeris every 30 seconds and it takes 18-20 second to download the whole thing. If that is true a temporary but consistent reception outage between the rover a satellite every 30 seconds could create a situation where observation data is received but ephemeris data is not.

I believe “on-chip” type systems invalidate the ephemeris data after 20-30 minutes. I’ve seen some systems allow you to select special modes that save the ephemeris data for up to 45 minutes. This is for the purposes of working under tree canopies. You power the system on in clear sky and wait 5-10 minutes. Then you go under the tree canopy and collect. Again I assume the tree canopy allows the smaller observation data to get through but not the larger ephemeris data.

Since ReachView is based on RTKLIB, does anyone how long ReachView will cache ephemeris data? Is there any aging logic? Since I can’t access the rtknavi.ini file my workaround does not work with ReachView. is anyone aware of another workaround.

bide · May 7, 2017, 7:32pm

That is very interesting. Thanks for bringing it up.

So let me get this straight, in the worst case, you are under canopy and the wind is blowing the branches and leaves around. This would possibly cause an outage every few seconds on most or all satellites which would corrupt the ephemeris, but not necessarily the observations. So, rather than giving no status because of no ephemeris, RTKLIB will use a backup of a previously saved ephemeris, but give the user no indication of that, and still produce Single, Float, and Fix status. So this would seem advantageous in getting started quickly, but it would seem to be a bug in this rather imporant corner case. Have I got that right?

The temporary workaround is to start up in the clear, wait 10 minutes for a full ephemeris download, and then go under canopy for max 20 minutes (to be determined) until coming out into the clear for 10 minutes to get new ephemeris again.

This screams like, in RTKLIB, it should be a blocker to fix status (and float too?) until the new ephemeris is downloaded, and it would be nice then if ReachView could show the “age of ephemeris data.” Maybe keeping with the theme of Green, Yellow, Red icons depending on the age.

As for an answer, I would suspect ReachView would handle it the same as it uses RTKLIB also, but if you want to investigate for yourself, I believe that part is still open source. Go to Emlid on Github;repository: RTKLIB; branch: reach, and check it out!

Now, if you know beforehand that you are going to be working under canopy, then when you set up your base, what about just enabling the ephemeris messages to be sent to the rover?

It is still not the answer to the problem as stated above. The user still needs to be denied or notified, so they know that they should take corrective measures.

Sorry, @thomas.purk I feel like I have just restated your entire post, but now I have it all straight in my mind

thomas.purk · May 7, 2017, 11:20pm

[quote=“bide, post:2, topic:5971”]
So, rather than giving no status because of no ephemeris, RTKLIB will use a backup of a previously saved ephemeris, but give the user no indication of that, and still produce Single, Float, and Fix status. So this would seem advantageous in getting started quickly, but it would seem to be a bug in this rather imporant corner case. Have I got that right?[/quote]

Caching ephemeris data is definitely an advantage for shorter time-to-first-fix and warm-start scenarios. UNLESS, the ephemeris data is old enough to degrade the accuracy of the point. If we are going for centimeter level mapping data it may be better to stop including satellite observations in the point estimation after the ephemeris data for that satellite is too old. A gnss system should do this automatically in my opinion.

I think you suggest a good practice. To my understanding ephemeris data is downloaded from each satellite individually, unlike an Almanac which is downloaded for the entire constellation from any single satellite in the constellation. So, the method you suggest to perform a cold start in open sky to replace old ephemeris data is a good one. Maybe a few times per collection day is all that is needed? However, I believe that old ephemeris for any given satellite is only deleted and replaced by RTKLIB if a new one is available, so some old data could remain for any given satellite that is not view during the open sky initialization.

This is also a good idea if using the Reach as a mobile base or some other base where the ephemeris RTCM messages are available. In fact I’ve pulled RTCM ephemeris data from 3rd party base stations as the 3rd “Correction” stream in RTKLIB to test my own traditional base stations as a rover. It works. This could be a really good solution for low-cost L1 chips and mid-cost antennas like the ones I’ve been working with and obviously emlid has been also. I believe the $1,000 antennas paired with the $10,000 receivers pull ephemeris much more easily than these low cost units. The low cost units pull the observations just fine, so why not try to pipe in the ephemeris over NTRIP? The only draw back is that your base correction service must support transmitting ephermeris, and most don’t in my experience. So if you are using the Reach with a traditional base station this might not be an option.