[teqc] correction made in teqc for decoding relative phase values from Javad JPS and Topcon TPS messages [*p]

Lou Estey lou at unavco.org
Mon Nov 7 12:16:36 MST 2016

On 07-Nov-16 09:52 AM, Lou Estey wrote:
> dear All,
> The next official version -- 2016Nov7 -- of teqc is on-line:
> http://www.unavco.org/software/data-processing/teqc/teqc.html#executables
> As usual, save a copy of your current executable in case there is some unexpected problem
> with the new executable.
> The main changes and fixes since 2016 Apr 1 are given in detail at
> http://www.unavco.org/software/data-processing/teqc/log/log.html#2016Nov07
> but here's a very brief summary about this release:

> - fixes a long-standing bug when decoding the relative phase values from Javad JPS and
> Topcon TPS messages [*p] (i.e. [1p], [2p], ...) Note: This particular issue will require
> a separate email for a full explanation.

One option for storing the phase values in Javad JPS or Topcon TPS formats is to use
4-byte integer relative phase values stored in the [*p] messages, i.e. [cp] for L1C/A,
[1p] for L1P(Y), [2p] for L2P(Y), and so on.

While going through changes that needed to be made for teqc for JNS firmware 3.6.0
and 3.7.0 with Javad, it was determined that teqc had never been correctly written
to properly reconstruct all the phase values when [*p] messages were being used.
In order to reconstruct the phase values from these messages, one needs a reference
pseudorange value, preferably stored in [rc], or [rx] in the newer JNS firmwares,
which stores the reference pseudorange in 4-byte integer.  However, one might instead
use the 8-byte floating point storage of the reference pseudorange [RC] (or [RX]
starting in JNS fw 3.7.0).  In such cases, the more complete reference pseudorange
needs to be converted into an [rc]-like integer before the relative phase values in
the [*p] messages can be properly turned into phase values.  It's the detail of
exactly how to get the [rc]-like integer value where the bug occurred.

This was corrected mid-September and is in version 2016Nov7.

If your phase values were stored using the [*p] messages, you will probably see
slight differences between about half of the phase values in RINEX between an older
teqc and this fixed version.  The differences, when present, should be about 0.016 L1
cycles and 0.013 L2 cycles, with the values from the new teqc being greater.

When processing RINEX using the new teqc, you shouldn't really see much of a change
in position, although (and I'm just guessing here) one might see a slight decrease in
the position RMS.

I should also point out that high-precision applications, like for reference stations,
probably should not be using the integer relative phase values stored in the [*p] messages.
For high-precision applications, using:

o [P*] messages, full phase values in 8-byte floating point, or
o [*P] messages, relative phase values in 4-byte floating point

would both provide more precise storage for phase values.

But if you are using the [*p] messages for phase, use the 2016Nov7 version of teqc.


Louis H. Estey, Ph.D.              office:  [+001] 303-381-7456
UNAVCO, 6350 Nautilus Drive           FAX:  [+001] 303-381-7451
Boulder, CO  80301-5554            e-mail:  lou  unavco.org
      WWW:  http://www.unavco.org   http://jules.unavco.org

"If the universe is the answer, what is the question?"
                                                -- Leon Lederman

More information about the teqc mailing list