[teqc] New site flag when splicing Leica .m00 files

[Matt King]

Hi Lou

Apologies for the delay in getting back to you. Re the Leica MDB files
and new MARKER flags

teqc -lei mdb +diag +mds file.m00
<various records>
Leica MDB frame 0x9cae @ 0o00300734 = 0x000181dc = 00098780   type= 0x82
= 130
! Notice ! Leica MDB 130:   survey ends @ 2008 Mar 25 02:00:00.000 GPS
time
2008-03-25 01:00:00  2008-03-25 01:59:30     98794  file.m00 

So, yes, it seems like the leica is doing something a little strange and
putting a new marker at the end of every 1h file.

I would support a new option to ignore site occupation changes (event
flags 2 and 3) as you suggest. But I will also follow this up with
Leica.

Cheers
Matt


>-----Original Message-----
>From: teqc-bounces at ls.unavco.org 
>[mailto:teqc-bounces at ls.unavco.org] On Behalf Of Lou Estey
>Sent: 07 March 2008 16:49
>To: teqc at unavco.org
>Subject: Re: [teqc] New site flag when splicing Leica .m00 files
>
>hi Matt,
>
>> 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]
>> 303-381-7456)
>> 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 request.
>
>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.
>
>R13:
>> 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.)
>
>cheers,
>--lou
>_______________________________________________
>teqc mailing list
>teqc at ls.unavco.org
>http://ls.unavco.org/mailman/listinfo/teqc
>