[teqc] dumb clock questions

[Lou Estey]

Geoff,

>   I'll be happy with this too!  As you say Lou, teqc +smtt doesn't work 
> on rinex files, so it can't be run after-the-fact if the archive only 
> has teqc -smtt flavored rinex.   A question might be: how does this 
> affect gamit and bernese users? (which I think you asked already - but 
> didn't see any responses).

I'm pretty the "smooth time, ms-jumpy phase and pseudorange" RINEX works
OK in Bernese, though perhaps some expert could comment on whether certain
epochs bordering the ms-reset points get special treatment (perhaps even
rejection).

No idea about Gamit.  Bob K., Tom H.?

> Note to gipsy users - clockprep would still be run by default in scripts 
> like "point_rnx" etc., which is OK and in fact a good thing, because 
> occasionally you do get data that is *actually* time tagged .999000 sec 
> and .001000 sec (at least, I've seen this in Trimble 5700 data). [...]

... this being the recent finding from your earlier thread to the teqc list
(questioning whether `teqc +smtt` was doing the right thing when these were
showing up in 5700 data).  My question to either you or Jeff: _why_ is it
a good idea to run this type of RINEX through clockprep?  (i.e. `teqc +smtt`
type RINEX where epoch should nominally be on the second, but for whatever
reason the receiver occasionally samples +/-1 ms off the nominal epoch).
I guess I'm wondering if there is something I should be adding to teqc that
clockprep does in this case.

--lou