[teqc] status of 4 known teqc bugs in version2016Nov7

Lou Estey lou at unavco.org
Mon Nov 21 10:24:58 MST 2016

On 18-Nov-16 03:07 PM, Lou Estey wrote:
> The 2016Nov7 version has been available for almost two week now (as well as the earlier beta
> version that was made available for the most popular builds in mid October).
> Has anyone encountered any problems?
> Next week, I'll summarize four bugs I know of, three of which were found and fixed this week.

Bug #1: You might encounter a segmentation or memory fault when reading Javad JPS or Topcon TPS data.

To date, we have only seen this problem with one site using a Javad Sigma receiver w/ fw 3.6.3,
and only for intermittent files from this one site and only for two teqc builds.  (I'll also note
that this site tend to be a little problematic keeping a daily sessions going in a consistent way.)
Of the 2016Nov7 builds tested here on the same JPS files from this site:

Windows 32-bit using MingW-32: several problem files
Windows 64-bit using MingW-64: no problems
Mac OS X gcc 4.3:              no problems
Mac OS X gcc 4.2:              no problems
Linux 32-bit:                  no problems
Linux 64-bit:                  no problems
Solaris Sparc 64-bit:          no problems
Solaris x86 64-bit:            2 problem files

After discovering this (which we only noticed for JPS files from this site after Nov 7), a code
change was done on Nov 16 which works for all tested builds.


Bug #2: If reading Javad JPS or Topcon TPS using relative carrier phase messages, i.e. [*p] =
[cp], [1p], [2p], ... or [*P] = [CP], [1P], [2P], ..., then the phase values in cycles will not be
"complete" unless RINEX C1 is specified as a co-observable.  The bug is applicable to all builds.

The easier way to explain this is that if you had JPS/TPS data using relative carrier phase
messages, then doing these two runs:

teqc -O.obs l1+l2 datafile
teqc -O.obs l1+l2+c1 datafile

... will show different results for RINEX L1 an L2.  If you are translating to RINEX in the most
complete way, or using teqc's default set of observables, you will not encounter this at all
because RINEX C1 will be included.

This was fixed on Nov 17.


Bug #3: If reading Javad JPS or Topcon TPS using the 4-byte integer relative carrier phase messages
[*p] = [cp], [1p], [2p], ... and using [RC] (or newer JPS [RX] in fx 3.7) as the reference, then
you will end up with wrong phase values when using the Linux 32- or 64-bit builds.

The reason for this bug is rather bizarre.  The recommended approach from Javad for the above
situation involved using the trunc() function -- which works exactly as expected in all other
builds.  The Linux 32- and 64-bit teqc builds are currently using gcc 3.2.2 and 3.2.3, respectively,
and for whatever reason the trunc() function is returning a value of 25.0 and -1.0, respectively,
no matter the value of the argument of the trunc() function.  (This was so crazy I had two
other developers in our group look at this with me.)

A workaround for Linux 32- and 64-bit builds using the ceil() and floor() functions introduced
on Nov 17.


Bug #4: It is possible, in some situations, that using '-O.sum' an a raw data file and outputting
the result to stdout, stderr, or a non-RINEX file will result in few observables counted than if
translating the file to RINEX obs and then using '-O.sum' on the RINEX obs file.

So far, I have only seen this problem on one data file for one data format: the Ashtech stream format.
Also this one data file was collected during a period when the receiver was not exactly acting
normally and I know the "missing" observable count is due to the lack of observable counts during
this abnormal period.  To demonstrate the problem:

[3793] teqc +quiet -week 1069 -ash s -O.sum . ash_problem.str
          L1    L2    C1    P1    P2    S1    S2
         ----  ----  ----  ----  ----  ----  ----
    G03   733   733   731   718   722   733   733
    G21   644   644   643   636   639   644   644
    G15   426   426   427   425   426   426   426
    G29   483   483   484   482   483   483   483

[3794] teqc +quiet -week 1069 -ash s ash_problem.str > tmp.obs; teqc +quiet -O.sum . tmp.obs
          L1    L2    C1    P1    P2    S1    S2
         ----  ----  ----  ----  ----  ----  ----
    G03   939   939   937   922   924   939   939
    G21   708   708   706   700   703   708   708
    G15   490   490   490   489   490   490   490
    G29   547   547   548   546   547   547   547

I also know that this behaviour is due to some subtle change in logic when I introduced dynamic
record buffering for this particular format; if I revert the code to static buffering for the
Ashtech stream format, the problem goes away.  But the exact cause with dynamic record buffering
is alluding me.


Of these four bugs, the only one that is severe (if it occurs at all), is the first one.
So if you are trying to read Javad JPS or Topcon TPS data and teqc crashes, let me know
and I'll set you up with an interim version.


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