[teqc] teqc spliced 1sec RINEX bug ... ?

Lou Estey lou at unavco.org
Tue Nov 2 08:45:27 MDT 2010

Dear Ant,

First guess (without seeing the actual input files):

Sounds like some sort of splicing bug ... period, i.e. not dependent
on 30-sec or 1-sec input RINEX, and probably whatever is causing
this is related to something specific about your 1-sec RINEX besides
the sample interval.  Next thing we should see is if I can replicate
this behaviour, so if you can send me (not the list) a couple of
your 1-sec RINEX, I'd be happy to take a look.

A few comments (mainly for other users) about the options being
used here:

-E -- if the input really has Galileo/GIOVE data and you want it
all eliminated in the output RINEX, ok; otherwise '-E' does nothing

+relax -- do not use this unless you think you have to; this is only
meant to be used to get by certain pseudo-RINEX input and certainly
isn't 100% reliable (Dr. Sibthorpe's input files might really need
this ...)

-C2 -- this is the default setting anyway, and is only meaningful
when translating from non-RINEX to RINEX (so it does nothing here)

-O.dec 1s -- if the input is 1-sec data, you shouldn't use this; if
you merely want to make sure that the INTERVAL line is present and
correctly populated in the output, use '-O.int 1' instead

-n_GPS 64 -- why not '-n_GPS 32', which is the default??  (since
there are no valid GPS SV PRN from 33-64)

-L2C_L2 (or +L2C_L2) -- these are translation options only,
so have no effect for RINEX-to-RINEX filtering (like RINEX splicing)


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

On 11/2/2010 8:13 AM, Sibthorpe, Ant (335H) wrote:
> Hi,
> Using the newest version of teqc:
>> > executable: teqc
>> > version: teqc 2010Oct21
>> > build: Linux 2.4.21-27.ELsmp|Opteron|gcc -static|Linux x86_64|=+
> we operationally splice 30sec files with something like the following
> command:
>> > teqc -E +relax +out out.08o -igs -C2 -O.obs L1L2C1P1P2 -O.dec 1s
> -L2C_L2 -n_GPS 64 -st 2008-11-18_21:00:00 -e 2008-11-20_03:00:00 -phc *.08o
> Recently, we tried the same thing with 1sec input files, but at the end
> of the file we got the following lines which cause our RINEX reader to
> choke:
>> > 112088204.78248 87341445.08448 21329686.0404 21329686.1384 21329689.3254
>> > 1
>> >other post-header comments skipped COMMENT
>> > 1
>> >other post-header comments skipped COMMENT
>> > 1
>> >other post-header comments skipped COMMENT
> If we turn off –phc, the file finishes with the first line above, and
> all is well. But with –phc, it seems that it is not outputting valid
> RINEX. If we edit the single integer lines to read “ 4 1 “ then it works
> fine. We can’t work out why this only happens with 1sec input. Is there
> some other flag we need?
> Assistance gratefully received.
> Thanks.
> Ant
> ------------------------------------------------
> Dr. Ant Sibthorpe
> Senior Technologist, NASA JPL
> M/S 238-600, 4800 Oak Grove Drive
> Pasadena, CA 91109
> Tel: +1 (818) 393 7411
> _______________________________________________
> teqc mailing list
> teqc at ls.unavco.org
> http://ls.unavco.org/mailman/listinfo/teqc

More information about the teqc mailing list