[teqc] TPS conversion problem

Lou Estey lou at unavco.org
Thu Nov 4 11:47:37 MDT 2010

from a knowledgeable and concerned power-user:
> I can see why you would not want the number to be arbitrarily large, but
> why not something reasonable by default? At least for these danged
> "modern receivers"? It seems to me that the experience of Rui (and
> others, apparently) shows that for this class of receivers the default
> value is not reasonable. Since the numbers of these receivers is
> growing, why not either raise the default value to something that works
> in these cases, or allow teqc to automatically raise the default when it
> realizes it is getting data from one of these beasts?
> I guess I don't care too much about the getting the most out of the qc,
> but I do care about the translating all the data. If teqc requires me to
> experiment with receiver-specific settings in the blind (or ask you,
> what settings are needed for receiver X?) or else have it randomly lose
> data, then it is not being a very useful tool for the #1 task: making
> RINEX files.
> Do you have a web page somewhere that lists known receiver-specific teqc
> settings required for proper operation for various receivers? It would
> be highly useful. My guess is that most everyone ends up finding these
> out the hard way, or by asking you after they can't figure out why they
> are not getting what they expect.

This what I sent to Rui (off-line), who asked essentially the same thing:

 > If you want to, go ahead [and use '-max_rx_SVs 50']. If fact, you can go all
 > the way up to the current maximum of 64.  But if anything else goes wrong
 > after doing so, don't contact me! :)

 > I am trying to tell everyone that using the best possible real value
 > for a specific receiver is the safest thing to do.

Look, everyone, data (whether 'binary' raw or 'ASCII' RINEX) is just a big pile
of 1's and 0's (*). Somewhere in there is a field of N bits which is specifying how
many SVs are being tracked for the current epoch.  For simplicity, let's say
that field is one specific byte, therefore 8 bits -- which is a common case. Now,
when everything is right with the world, only the least significant bits are set
to indicate values like 10 SVs (00001010) or 12 SVs (00001100) or (now, with
more modern rxs) 20 SVs (00010100).  But then, someday something goes wrong and
a high bit gets set in this field, let's say bit 5 (the 6th bit), so now you
instead have 00101010 = '42', 00101100 = '44', or 00110100 = '52'.  This sort
of stuff really happens!  (Granted, it's rare, and getting rarer -- assuming
uncorrupted data transmission.)

So, if you want to translate without one of teqc's little safety parachutes,
please feel free to do so.  You are empowered to do so.  Option '-max_rx_SVs'
has been around for almost 15 years, so it's nothing new, and it's not a
secret.  Go for it.  But if you use unrealistic values, and no parachute opens
someday and things crash, don't come complaining to me. ;)

And does UNAVCO have a web page that lists known receiver-specific teqc
settings required for proper operation for various receivers?  No, and I
cannot imagine trying to maintain such a thing.  We have a hard enough time
with data from a _very_ limited set of all possible receivers that come in to
UNAVCO for archiving and/or conversion to RINEX which goes to our data export
ftp servers.  And both our archiving and conversion processes are 100% reliant
on teqc.

We don't even have enough information for this single specific problem.  All
major manufacturers that we use (or at least try to be aware of) were contacted
in early 2010 for this one detail, and we received a fairly complete list (up
through early 2010, anyway) from Trimble and Septentrio. (Trimble's list, however,
didn't include the new NetR9.)  We continue to try to get updated info about
this for other receivers, such as Topcons.  When we have better information,
it's put into teqc and then it's in the next version.  Simple as that.

cheers everyone,

p.s. I am now going off-line on this subject.

* My definition of a software engineer: someone who creates piles of 1's
and 0's that transform other piles of 1's and 0's into yet other piles of
1's and 0's -- all hopefully in a sensible way. :)

More information about the teqc mailing list