[teqc] dumb clock questions

[Lou Estey]

Geoff Blewitt wrote:

> Lou - see response below
>   - Geoff
> 
> Lou Estey wrote:
> 
>> Jeff Freymueller wrote:
>>
>>> Geoff's explanation (below) is basically correct. When clockprep 
>>> finds an offset in the observables, it is almost never exactly 1 
>>> millisecond because of the (physical) change in range between epochs. 
>>> In the case of this file, there will also be a component from the 
>>> clock drift rate, as it appears that this file (from the clockprep 
>>> output Andrew forwarded earlier) has 1 millisecond offsets about 
>>> every 50 epochs, or about 5 times an hour. That is a very high rate 
>>> of clock drift, but I have seen higher rates before. In this case, 
>>> the clock's drift rate is ~0.02 milliseconds per epoch (~6 km), so I 
>>> suspect that this effect dominates because clockprep calculates the 
>>> offset by averaging across all the satellites, and some satellites 
>>> will have range getting larger, others getting smaller so the average 
>>> is usually closer to zero than the range change in any one satellite.
>>
>>
>>
>> That being the case, doing a normal clockprep on a RINEX with ms-jumpy 
>> time
>> tags and smooth phase and pseudorange is _not_ the same as doing a new 
>> `teqc +smtt`
>> translation of the data which results in RINEX with smooth time tags 
>> and ms-jumpy phase
>> and pseudoranges.  `teqc +smtt` applies just an exact ms jump.
> 
> 
> Lou,
>    Sorry this wasn't explained:  clockprep *assumes* the clock is reset 
> by exactly 1 msec (unless clockprep is invoked with a special option, 
> which wasn't the case here).  So the jumpiness goes away.  I've verified 
> that in almost all cases, the resulting rinex file is exactly the same 
> as running 'teqc +smtt' (except for the problem that Jeff explained - 
> the phase should show the same discontinuity as the phase, in which case 
> clockprep has an option to handle it).
> 
> Geoff

Geoff,

Ah, I was misreading Jeff's description.  He was just saying that the
jump in phase or pseudorange between the two epochs for any SV at a rx
clock reset in not exactly 1 ms, because there's the motion of the SV
(and the antenna if it's moving as well).

This is what comes from hurriedly trying to plow through 3 weeks of email. ;)

So, I agree: `teqc +smtt` and clockprep should be doing the same thing,
which is creating RINEX with a smooth time tag and ms jumps in the phase
and pseudorange -- which was the intent of the new +smtt option.  BTW,
just so no one tries it, the +smtt option in teqc acting on a RINEX file
as input has _no_ effect, so `teqc +smtt` is only for translation from
the raw receiver data, whereas clockprep is for altering an existing
RINEX file.

cheers,
--lou