TBC baseline processor using GPS only rather than GPS+GLO

If the ephemeris type is set to Precise, it will not process data for which there are no precise orbits. My guess is you need to download GLO orbits, since by this point they should be available for 7/31.

Either that, or set the ephemeris type to Automatic; if there are no precise orbits, it will look for rapid, then broadcast, and use whatever it finds first to process baselines.

@rover83

According to the IGS, Precise GLONASS orbits are available "about" the same time as Precise GPS Orbits.

http://www.igs.org/products

?ÿOf course not all CORS are GLONASS capable, AND the presence of "other" GNSS data in "your" observation files could possibly be an issue as well.

I don't use TBC, so I probably don't know what I'm talking about (again).

Loyal

@loyal

That's what I remember, if the GPS final orbits are ready than usually the GLO orbits are too.

TBC does define "precise" as anything other than broadcast, so I believe the "predicted half" ultra-rapid is technically not precise, and will not give results if the project settings are on Precise. The "observed half" ultra-rapid, and the rapid orbits, are still considered precise by TBC.

Of course, there are no ultra-rapid/rapid orbits provided for GLO, so most of the time the broadcast orbits are what get used for processing, along with whatever is available for GPS. It's rare to have projects which require processing with the final orbits. Clients rarely want us to wait two weeks to begin processing a project, especially considering how much better both the broadcast and the rapid orbits are than in the past.

Not 100% sure, but I believe you need to import broadcast ephemerides for both Glonass and GPS when importing rinex. If using .T02 or .To4, the ephemeris data is included in the binary file. And, as mentioned above, if using the precise you must have both constellations in the precise as well. I think older versions of TBC required the broadcast ephemerides, but not 100% sure about the newer versions of TBC.?ÿ

That said, I usually use only GPS when post processing, seems to be a bit cleaner and less noisy. But I will admit I haven't tried multi constellation post processing in quite a while. In the past I felt that including glonass in the post-processing degraded the results slightly.?ÿ

I tried processing with GPS and GLONASS broadcast ephemeris files that came with the CORS download, but the result was the same.?ÿ

The CODE MGEX ephemeris that I mentioned above is a multi-constellation ephemeris (GPS+GLO+GAL+BEI) that works with multi-constellation data for the units I use (R10s). This particular situation only happens to me when processing long CORS sessions.?ÿ

@rover83 I also attempted to process with the ephemeris type set to automatic, and the result remains the same. As an experiment I'll try downloading separate GPS and GLO final orbitals, but logically it shouldn't change the outcome given the nature of MGEX products.

@loyal completely agree with not all CORS being equal in terms of what they can see in the sky. In this particular case I know that both stations are logging GPS+GLO signals. Just to be safe I'll try testing this given by using only GLO ephemeris to force it to use GLONASS and therefore prove that the stations are seeing GLO.

Consider that TBC may be getting a better solution with just GPS versus a poorer solution with both and it is smart enough not to waste your time with the poorer results.

I seem to recall that one of the earlier Leica post processors would give an L1 only solution when it was better than an L1/L2?ÿ solution. And I did force some L1 only solutions with Ashtech Solutions by removing the dongle and found it better than L1/L2 solutions back in the day of fewer satellites.

Also consider that different ephemeris may not overlap the same with long observations.

Paul in PA

@paul-in-pa the more I'm thinking about it, the more I'm inclined to agree with you.

As I've stated before this only happens to me dealing with long CORS sessions (in this case 30 GPS birds over 20 hours). I know the final ephemeris I'm using fits the bill of what's needed in that realm (I've used it for various types of multi-constellation work- GPS+GLO, GPS+GLO+GAL, and GPS+GLO+GAL+BEI... works every time), and the data itself is good (I'm bouncing between 3-4 stations and getting good numbers when choosing random days to process)... so it just came down to the WHY in this particular case. Of course Trimble doesn't tell you a lot of stuff that's happening under the hood, so you very well may be correct.

EDIT: just checked again and the ephemeris file does cover the entire length of the observations being processed.

@steinhoff

I know with Ashtech Solutions you sometimes had to include the next days ephemeris if you were using rapids.

Paul in PA

@paul-in-pa

TBC can be the same way. Forgot about that on my previous reply...

Looking at the start/stop times in the report, my guess is that the stop time is close enough to the boundary between day 214 and 215 to require the precise data for 215.

A look at the CDDIS FTP site shows no final GLO orbits (IGL files) for day 215 / week 21170...

That could be the problem right there. Clear processing, select the unprocessed baselines, and change the stop time to a couple hours earlier and reprocess. Or wait another day or two for the final GLO orbits to be posted. The MGEX downloads are supposed to contain GLO, but if no IGL files are on the servers it's a good bet that they are not available yet, thus not included.

@rover83 Iƒ??ll sample same data thatƒ??s a month older and report back.

@rover83 the plot thickens. I downloaded CORS data for Julian day 183, and downloaded igs and igl files for week 2112, days 2-4 (Julian day 182-184) in lieu of MGEX ephemeris.?ÿ

Same result- baseline processor used GPS only. Interestingly enough... if you donƒ??t let TBC process GPS and only GLO, the baseline processor fails. Iƒ??ll attach some additional files shortly for back checking.?ÿ