[teqc] New site flag when splicing Leica .m00 files
lou at unavco.org
Fri Mar 7 09:48:58 MST 2008
> 1) It was just pointed out to me that some daily rinex files I've been
> making (from a combination of 1hr Leica .m00 files) have a new site flag
> at the join. Daily rinex files I make from trimble .dat files in exactly
> the same way do not have the flag. There's an example section at the
> change of hour below. This may be reflective of what is in the .m00 file
> (which I can make available) or a bug in teqc.
It's probably because of a record setting in the .m00 files -- teqc is
just responding to it. The record to check for is 0x82 == 130 (with
something like `teqc -lei mdb +diag +mds ...`); if a certain bit is unset
in 0x82, a new site occupation is determined to have been detected leading
to the event flag = 3.
A side note: there _is_ a "technical" bug with regards to event flag 3 and
teqc. The RINEX spec (at 2.11 anyway) says:
| | 3: new site occupation (end of kinem. data) | |
| | (at least MARKER NAME record follows) | |
and you'll notice that teqc doesn't put in a MARKER NAME line (thus "3 0"
instead of "3 1". This is where reality collides with theory -- or a
specification. Putting in said marker name assumes it's available, but
often it's not.
> If it's not a bug, then
> is there a way to get rid of this line using teqc (or just use sed/grep
> to remove it)? "-phc" obviously only removes comments, not post-header
> flags. A "-phf" command may be useful in this case.
> I get the same result for the most recent development version as from
> the 2007Jun25 version of teqc.
> version: teqc 2008Feb15
> build: Solaris 5.9|UltraSparc IIe|cc SC5.8|=+-|*Sparc
> system time: 2008 Mar 07 15:34:34 UTC GPS week= 1469
> contact: Lou Estey (email: lou at unavco.org ; tel: [+001]
> email forum: teqc at unavco.org http://ls.unavco.org/mailman/listinfo/teqc
Reading of Leica MDB record 0x82 (130) was added 2006Sep25 -- at user's
I'm not sure how to proceed. '-phc' actually removes just about everything,
but does preserve one comment that indicates where the splice point is, I'm
am not crazy about introducing yet another permutation.
It sounds to me that a new option to ignore site occupation changes (event
flags 2 and 3) is needed, which would apply here and any other format
where this situation occurs.
> 2) Also, I note a few differences between these two versions with
> GLONASS code obs (but not every sat). I figure these are related to
> previously flagged bad GLONASS frequencies (GLONASS: bad frequency #=
> 254 being rejected (min= -7, max= 24)).
> Here's a section of a file (converted with just C1 and P2 showing for
> clarity). 2008Feb15 output on the right.
> 19287635.916 19287638.603
> 19301190.123 19301192.811
R13 is one of the three now GLONASS SVs with negative frequency channel
numbers, and reading of the byte in question as a signed integer was supposedly
fixed on 23 Jan 2008 for the Leica MDB and Topcon TPS/Javad JPS formats.
So, yes, the older versions of teqc and the last one (2008Feb18) will
show different pseudorange values for R09, R13, and R17 (the only three
currently with negative frequency channel numbers), and I'd have to
suppose that only the most recent teqc version shows the correct pseudorange
values for these -- until shown otherwise. (A quick check would be to
do a qc: it should look better for R09, R13, and R17 using the newest
teqc RINEX translation.)
More information about the teqc