[teqc] Problem with Rinex output for Topcon Receiver

Lou Estey lou at unavco.org
Fri Feb 13 09:39:19 MST 2009


> Jack Tisdale wrote:
> 
>> I'm experiencing a problem using teqc to convert from Topcon TPS/JPS 
>> format to Rinex. I've successfully used teqc to parse these files 
>> before, but for some reason, I've got a TPS file that teqc won't 
>> output the correct .nav files for. The nav file that teqc outputs only 
>> has data for two satellites, as opposed to the 7+ satellites in the 
>> observations file. There's nothing in the output of teqc that suggests 
>> it's finding a problem with the file.
>>
>> I've used the tps2rin tool on this TPS file and it outputs the correct 
>> ephemeris files.  If anybody wants to try to replicate the error, the 
>> tps file can be found at 
>> http://vehicle.me.berkeley.edu/~jtisdale/raw.jps Any help would be 
>> much appreciated.

Lou Estey wrote:
> For Unix/Linux/Cygwin users, here's something you can do:
> 
> [669] teqc -top tpsn raw.jps 2> /dev/null
> 
> dumps the RINEX GPS nav file with the two ephemerides that Jack notes, and
> 
> [670] teqc +diag -top tpsn raw.jps 2>&1 | more
> 
> shows the parsing of raw.jps (originally as stderr) and mixes that
> with the generation of the RINEX GPS nav as the [GE] TPS/JPS
> messages are encountered -- so you can see which two [GE] messages
> teqc is happy with.  Then:
> 
> [670] teqc +diag -top tps +mds raw.jps 2>&1 | grep "\"GE\"$" | wc -l
> 30
> 
> shows that there are 30 [GE] messages total in raw.jps -- a bunch
> at near the beginning and a bunch towards the end, and there aren't
> any checksum errors:
> 
> [674] teqc +diag -top tps +mds raw.jps 2>&1 | grep checksum | wc -l
> 0

This is actually a very good question that Jack raises, and here's
the complete story -- and a question for everyone at end:

There are a total of 30 [GE] messages in the file, 15 towards the
beginning and 15 towards the end.  The 15 at the end are tagged by
teqc as duplicates of the first 15 (based on PRN and ToE values
only) and discarded.  So 2 of the 15 are output.  What happened to
the other 13?

The answer goes back to a code changes (see
http://facility.unavco.org/software/teqc/log.html ) --

-------
2008 July 24: nav_filtering() was modified so that if a start time
has not been specified (i.e. -st) then a navigation message is accepted
if its time-of-clock (ToC) is within 1 hour earlier of the start of
observation data (== default start time) once an initial observation
epoch has been read
-------
2006 Nov 27: a filter to skip ephemerides with a "time of clock" epoch
earlier than a windowed start time when reading binary data was added
to nav_filtering() — to prevent early calls to nav_native_to_RINEX_out() —
which is analogous to what has been in nav_out() (reading of input
RINEX NAV files) for years
-------

i.e. the 2008 July 24 change was just to relax the restriction of
the 2006 Nov 27 code by 1 hour.

Now why the heck is this restriction in there in the first place?
Well, two reasons:

1) We have seen that certain receivers/firmware sometimes offload
very old ephemerides.  For example -- and I'm not picking on Trimble
here; I just happen to remember this case very well -- the early
firmware for the NetRS that we are using in PBO would remember and
output ephemerides from the last time it was powered up and tracking
GPS SVs.  So, a unit would be tested here in Boulder, then eventually
get shipped and installed, often months later, and the first ephemerides
that the unit would output would often be from its earlier test
period.  This and other cases like it are annoying when you are
creating daily RINEX and users of that RINEX expect the ephemerides
in that file to be for day X and not 90 or so days earlier.

2) We are asked to make daily RINEX from data files that are many
months long (some even on the order of a year long).  The time
windowing in teqc was originally just for the obs epochs (for
phase, pseudorange, doppler, SNR observations -- what's in a RINEX
obs file), and not for navigation messages.  So, we would start in
making daily RINEX, obs and nav, from these long data files using
teqc's windowing and noticed that the RINEX nav files being created
were the sum of all nav messages in the file up to the point
of the end of the obs window, e.g.

RINEX nav for day 1: nav messages for day 1
RINEX nav for day 2: nav messages for days 1+2
RINEX nav for day 3: nav messages for days 1+2+3
...
RINEX nav for day N: nav messages for days 1+2+...+N

which is obviously the same problem as 1) above, i.e. for the later
RINEX nav files the bulk of the nav messages in them is not what
users expect.

The solution was to tie teqc's windowing also into the ToC/ToE
of the nav messages, and then to time filter out these early nav messages
from the RINEX nav output.  It was found that the first attempt of
2006 Nov 27 was too restrictive, so this was relaxed a bit by
1 hour with a change made on 2008 July 24. (more on this at the end.)

Now on to your JPS file, Jack.  The obs epochs are between:

[719] teqc -notice +mds raw.jps
2009-01-24 23:40:45  2009-01-24 23:56:15   6619093  raw.jps

thus (with the code as is right now) teqc will only output nav
messages with a ToC/ToE going back to 2009 Jan 24 22:40:45, i.e.
1 hour before the start of the first data epoch at 23:40:45.
(Small caveat: Since Jack is not probably not explicitly time
windowing, this auto-filter is only in effect _after_ the first
data epoch at 23:40:45 has been read.)

The 13 deleted nav messages turn out to be (in order, as
the [GE] TPS/JPS messages are read):

ToC= 2009 Jan 18 00:00:00 not in window= 2009 Jan 24 23:40:44.600 to 6075 Dec 31 23:59:59.999
ToC= 2009 Jan 24 22:00:00 not in window= 2009 Jan 24 23:40:44.600 to 6075 Dec 31 23:59:59.999
ToC= 2009 Jan 18 00:00:00 not in window= 2009 Jan 24 23:40:44.600 to 6075 Dec 31 23:59:59.999
ToC= 2009 Jan 18 00:00:00 not in window= 2009 Jan 24 23:40:44.600 to 6075 Dec 31 23:59:59.999
ToC= 2009 Jan 24 22:00:00 not in window= 2009 Jan 24 23:40:44.600 to 6075 Dec 31 23:59:59.999
ToC= 2009 Jan 18 00:00:00 not in window= 2009 Jan 24 23:40:44.600 to 6075 Dec 31 23:59:59.999
ToC= 2009 Jan 18 00:00:00 not in window= 2009 Jan 24 23:40:44.600 to 6075 Dec 31 23:59:59.999
ToC= 2009 Jan 18 00:00:00 not in window= 2009 Jan 24 23:40:44.600 to 6075 Dec 31 23:59:59.999
ToC= 2009 Jan 18 00:00:00 not in window= 2009 Jan 24 23:40:44.600 to 6075 Dec 31 23:59:59.999
ToC= 2009 Jan 24 22:00:00 not in window= 2009 Jan 24 23:40:44.600 to 6075 Dec 31 23:59:59.999
ToC= 2009 Jan 18 00:00:00 not in window= 2009 Jan 24 23:40:44.600 to 6075 Dec 31 23:59:59.999
ToC= 2009 Jan 18 00:00:00 not in window= 2009 Jan 24 23:40:44.600 to 6075 Dec 31 23:59:59.999
ToC= 2009 Jan 24 22:00:00 not in window= 2009 Jan 24 23:40:44.600 to 6075 Dec 31 23:59:59.999

Let's look at the ToC of the two nav messages that teqc did
output to RINEX nav:

2009 Jan 18 00:00:00 (for PRN 3)
2009 Jan 24 23:59:44 (for PRN 9)

The nav message for PRN 9 is clearly after 2009 Jan 24 22:40:44.

But, why did the nav message for PRN 3 get output?  Well, the [GE]
message for it occurred in the file before the first observation
epoch (and at that point the auto-window had a start time of
1980 Jan 6 00:00:00 -- the start of GPS time), so it slipped
though.  The code changes adding time windowing to exclude
old nav messages were casting a big net; a few small fish
are bound to escape once in a while.

Back to that 1 hour of slop, added on 2008 July 24.  Is that
enough?  Instead should the value have been a user option?
(Believe me, this is the sort of stuff I agonize over ...)
Well for Jack's small 15-min set of observations, we would
probably say we need to capture at least the 4 nav messages
for 2009 Jan 24 22:00:00.  This would be accomplished with
2 hours of slop from the first obs at 23:40:44.6.  What
about the 9 nav messages for 2009 Jan 18 00:00:00 that show
up after the first obs epoch?  (I would argue no.)  But the
problem with increasing the slop from 1 hour to 2 hours is
that daily RINEX nav made from teqc would then potentially
have another hour of nav messages from the previous day.

So, you, the users, tell me.  What's the optimal strategy?
It's also worth noting that (currently) the ToC times of GPS
nav messages are normally exactly at the 2 hour marks (00,
02, 04, ..., 22) or a few nav messages with ToC at 16 seconds
before those hours (e.g. 23:59:44).  So, the (not arbitrary!)
selection of 1 hour of slop made for the code on 2008 July 24
really does a nice job of excluding most nav messages from the
previous day when make daily RINEX nav files.

cheers,
--lou

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Louis H. Estey, Ph.D.              office:  [+001] 303-381-7456
UNAVCO, 6350 Nautilus Drive           FAX:  [+001] 303-381-7451
Boulder, CO  80301-5554            e-mail:  lou  unavco.org
    WWW:  http://www.unavco.org   http://jules.unavco.org

"If the universe is the answer, what is the question?"
                                                -- Leon Lederman
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


More information about the teqc mailing list