[teqc] the three corrections to teqc's qc antenna position calculation in the next release

Lou Estey lou at unavco.org
Wed Mar 14 11:11:24 MDT 2018


dear Bernard,

On 14-Mar-18 06:50 AM, Bonhoure Bernard wrote:
> I don't know what is your objective for PVT accuracy (a few tens of meters or some meters or below?), but normally the Earth rotation effect (up to a few tens of meters on position) and the relativistic effect (typically a few tens of centimeters for nominal near-circular satellites) shall be taken into account in a base-line PVT. PVTs on reference receivers like IGS ones have a few meters accuracy now.

The objective is what will probably be released tomorrow, with about a 2.5-3 meter 1-signa in horizontal,
or about the same 1-sigma in 3d if one accounts for the +15.7 m (+/- a few decimeters) vertical offset
in teqc's result (i.e. subtract ~15.7 m from teqc's elevation to get to about the correct elevation) since
delays the ionosphere (and the troposphere) are not being accounted for at all (even approximately) in
teqc.  At least this level of accuracy is what should be realized if one uses around 24-hours of data.

To be try to be clear, once again, _all_ of the corrections I mentioned again yesterday have correctly been
in place in teqc's code since July of last year -- except for applying the relativistic eccentricity
correction to GLONASS and SBAS (which had to wait until rewriting orbit calculations for those SVs
based on the ICD numerical integration methodology).  However, due to two incredibly silly mistakes and
a non-optimal selection of which epochs to use for a position determination (all of which had nothing to
due with implementing these corrections), the benefits of these corrections were not being realized in
the final displayed results.  In the next release users should be able to finally see the improvement.

BTW, the 3d position shown in the qc results will now be based on at least one solution per bin in the
ASCII time plot, so with a width of 72 columns, that's 72 (or slightly more) epochs used for the average
position.  (All epochs are not used unless one uses the '+eep' option = do "every epoch's position".)
Previously, this was not the case: the selection of which epochs were used was a little haphazard, which
was one of the problems that has been fixed (and this problem was accidentally exacerbated for the 2018Jan11
release).

> For best signals like Galileo E1/E5a and GPS L1/L5, we can get a single point solution around 1m horizontal at 95% and even better in the future, using only code.
> 
> The relativistic eccentric correction is defined in Signal in Space ICDs. The User algorithms for satellite Ephemeris determination are also defined in respective SIS ICDs. For GPS (and Galileo etc...), the ephemeris parameters give you the position of satellite in the rotating Terrestrial frame at the given Epoch, this is why we need to correct for the rotation of the Earth during the signal transmission duration from satellite to receiver in order to calculate a correct transmission range i.e. in the same frame. This correction is sometimes called "Sagnac effect" but I do think the generic "Earth rotation correction" term is better.

Ok, got it: "Sagnac effect (or correction)" label is out and "Earth rotation correction" label is in.

> A good reference paper for the model of measurements and PVT algorithms is the appendix E of RTKLIB2.4.2 user manual attached. RTKLIB may also help you to validate the TEQC PVT. This appendix should allow you to fully implement a correct PVT in TEQC. Please refer to SIS ICDs for a correct implementation for each constellation algorithms. Note for example, that there are different constants (Mu, Earth rotation rate...) for constellations, I've already seen some mistakes in several PVT software for the Galileo Mu value for instance (different from GPS one).

I'll leave all that joy for whoever takes over teqc after I retire. :)

> Concerning the different time scales (this is one time scale for each constellation), I send you an ION GNSS 2015 paper "Four Constellation Early PVT" I wrote a few years ago, dealing with the subject and demonstrating and giving the multi-constellation PVT equations. My advice is not to use (at least today) the GPS time to UTC and others broadcast time differences to UTC, we can have an error from a few ns to even more than 10 ns for the Broadcast values. Broadcast GGTOs if present may also have that kind of error. We have also to take into account different transit times from antenna phase(s) center(s) to receiver signal measurement loops. Differences between those signal transit times, especially for ionospheric-free combinations and depending on physical antenna used, may be a few tens of nanoseconds because frequency and signals of the constellations are different. Our nominal approach is to estimate a receiver time bias for each constellation time (1 additional unknown for each additional constellation).

Interesting.  Thank you for the info.

> Best Regards,
> 
> Bernard
> 
> Bernard BONHOURE
> GNSS/GALILEO Navigation Senior Expert DSO/NT/SN
> CNES Centre Spatial de Toulouse - CNES Space Agency, Toulouse Center
> 18, avenue Edouard Belin - 31401 Toulouse Cedex 9
> Tel 33 5 61 28 14 62 Sec 33 5 61 27 32 17
> E-Mail bernard.bonhoure at cnes.fr

cheers,
--lou


More information about the teqc mailing list