[teqc] translation of Ashtech R files one week off

Lou Estey lou at unavco.org
Fri Jan 21 10:03:41 MST 2005


[ Update for list:

Oliver tried the current Linux x86 executable (same result) and
sent me the two R-files. ]

> It works the same.
> Mine was
> robinson{9}: teqc +id
> executable:  teqc
> version:     teqc  2002Mar14
> build:       Linux 2.0.36|Pentium II|gcc|Linux|486/DX+
> system time: 2005 Jan 21 16:40:17 UTC    GPS week= 1306
> contact:     Lou Estey (email: lou at unavco.ucar.edu ; tel: [+001] 303-497-8036)
> email forum: teqc at unavco.ucar.edu  
> http://www.unavco.ucar.edu/html_mail/teqc/teqc.html
> [...]
> It works if I enforce it with week option, but this means I need to use 
> another tool like doy (gamit) to get gps week first.

This is my recommendation: For automated translation, do a
metadata check (using +meta or +mds) first:

[808] teqc +mds Rhouea04.340
! Notice ! GPS week initially set= 1299
week: 1300
[809] teqc +mds Rhoueb04.340
! Notice ! GPS week initially set= 1300
2004-12-05 08:00:30  2004-12-05 16:00:30    266218  Rhoueb04.340

As you can see, +mds terminates as expected with Rhoueb04.340
(we get the start/end date and time), whereas +mds terminates
with "week: ####" with Rhouea04.340.  This means, given the
non-deterministic nature of the ordering of records in an R-file
and some other formats and the fact that teqc is a nominal one-pass
filter, teqc finds a week value (e.g. in a navigation message) which
suggests 1299 for the start of data in Rhouea04.340, but at some
point teqc figures out the inconsistency and terminates with the value
that it thinks should be the correct starting week.  If that happens,
re-run with the supplied value after "week:" using the -week option,
e.g.:

[810] teqc -week 1300 +mds Rhouea04.340
! Notice ! GPS week in Ashtech SNV record = 1299; (default) GPS week = 1300
2004-12-05 00:00:30  2004-12-05 08:00:30    293866  Rhouea04.340

Likewise, when this occurs you need '-week ####' for the
translation step as well.

This stdout termination with "week: ####" only occurs when
using a metadata check (i.e. +meta or +mds).  We do this first
for every file that we archive here at UNAVCO; the internal logic
in teqc for this step is fairly well tuned; it is rarely wrong.

I'll look to see if there is a possible fix for this case
so that file Rhouea04.340 would translate (or extract the
metadata) correctly without needing '-week 1300', but given the
past record of this type of problem, I'm not too hopeful.

hth,
--lou







More information about the teqc mailing list