[teqc] G00 appearing in RINEX from Trimble NetR9 .T02 files

Lou Estey lou at unavco.org
Tue Oct 12 14:35:26 MDT 2010

hi Lennard and all other NetR9 users,

With updated Trimble documentation (and thanks to Brian Frohring
at Trimble for providing that), the reading of RT27 has been
updated to fully account for GIOVE data.  In addition, because the
NetR9 reports GIOVE-A as PRN 51 and GIOVE-B as PRN 52 in RT27
and in its on-board created RINEX, I've had to move away (alas)
from using my simple 32-bit flags stored in a single unsigned 4-byte
integer to bit flags in an array of unsigned 4-byte integers.
With the next release, that array will be set for 2 bytes, so
this will allow PRN/slot # values of 1-64.  (This also puts
the code in good shape for having the array be dynamically allocated
so that, in the future, if some constellation has values > 64, then
there need not even be a recompiling of the code to have it
work properly.  This is not yet the case, however, so the
new limit will be fixed in the next release at 64.)

Reminder to SBAS users: the SBAS PRN values in RINEX are offset by
subtracting 100, so the expected values in RINEX are, say, 20-38,
but these values have been and continue to be offset internally
in teqc by another 20, so use bits 0-18, that is SBAS worked
fine with just one unsigned 4-byte integer.  I.e. as before, to
delete SBAS PRN 134, continue to use '-S34' and so on.

Also, the limits of the options:
will be tightly coupled to the array size for these bit flags
in the next release, i.e. with this change you will not be able
to enter values greater than 64.


On 9/29/2010 8:13 AM, Lou Estey wrote:
> hi Lennard,
> The imagination and persistence of you users out there really
> amazes me. :)
> You did correctly interpret those messages -- it's just that you
> are trying to push the usage of some of these options way
> beyond what they were designed for.
> For the options:
> -n_GPS
> -n_SBAS
> -n_Galileo
> one should not use these beyond what would be realistic
> values, e.g. 32 for GPS. The reason for these options was
> to allow, in some cases, a more restricted upper bound to
> the constellation SV numbers (PRN or slot # for GLONASS), e.g.
> for periods of time when there was not GPS PRN#32. (Approx.
> dates of when there was PRN32 are 11 Dec 1992 - 28 Jan 1993 (SVN32),
> 1 Dec 2006 - 6 Dec 2006 (SVN23), and 27 Jun 2007 - present (SVN23) --
> except for other minor outages. Thus, as far as I know,
> PRN32 should not be showing up outside of these dates, and in
> such cases use of '-n_GPS 31' might be warranted.) If
> SV numbers actually start to exceed what's built into the
> teqc code, then the code will have to be updated.
> As for the options:
> +G/-G
> +R/-R
> +S/-S
> +E/-E
> any numbers used here absolutely cannot exceed 32. Period.
> (Don't even think about it.)
> Now, getting back to what you are trying to do, which is
> translate Trimble's .tgd files from a NetR9: Just ask for
> an interim updated build (i.e. sent me the build line from
> running `teqc +id`. The fixes in teqc added in late July
> based on the documentation updates from Trimble for reading
> their RT27 data structure appear to be working just fine
> for us and for the few users who have requested a interim
> build. Or you can wait until the next full release, which
> will probably be sometime soon in October.
> cheers,
> --lou
> On 9/29/2010 3:31 AM, Lennard Huisman wrote:
>> Hi Lou,
>> I am having the same problem as described in this topic.
>> The reason for the problem was explained before, but I was looking for a
>> work-around. I did find one, but also found a problem when looking for
>> the work-around.
>> First the work-around that works:
>> With runpkr00 I create a tgd file from my NetR9 .T02 file:
>> runpkr00 -g -d NetR9.T02 NetR9.tgd
>> Next with teqc I create my rinex files, which will contain G00 and blank
>> lines as explained in this topic before:
>> teqc +obs NetR9.10o +nav NetR9.10n,NetR9.10g NetR9.tgd
>> Using perl replace string 'G00' with 'S26' (SBAS 126 does not appear in
>> Australia :) ):
>> perl -p -e "s/G00/S26/g" NetR9.10o> NetR9.obs
>> Now I remove all (blank) lines from 'S26' and cearte a clean obseravtion
>> file:
>> teqc -S26 +obs NetR9.10o NetR9.obs
>> So far so good, however I wanted to use a non-existing PRN number like
>> G99, which from the teqc documentation I thought would be possible:
>> runpkr00 -g -d NetR9.T02 NetR9.tgd
>> teqc +obs NetR9.10o +nav NetR9.10n,NetR9.10g NetR9.tgd
>> perl -p -e "s/G00/G99/g" NetR9.10o> NetR9.obs
>> teqc -n_GPS 99 -G99 +obs NetR9.10o NetR9.obs
>> But I get the following message:
>> ! Warning ! setting NAVSTAR GPS limit to 99 SVs> current allowable
>> maximum = 32
>> (there may be unforseen consequences ...)
>> list2mask(): illegal limit for 32-bit mask= 99, offset= 0
>> teqc ... exiting
>> It seems -n_GPS 99 is accepted (the warning), but -G99 not (list2mask
>> message?). Did I misunderstand something?
>> Regards,
>> Lennard Huisman
>>> -----Original Message-----
>>> From: teqc-bounces at ls.unavco.org [mailto:teqc-bounces at ls.unavco.org]
>> On
>>> Behalf Of Lou Estey
>>> Sent: Tuesday, 15 June 2010 4:18 AM
>>> To: teqc
>>> Subject: Re: [teqc] G00 appearing in RINEX from Trimble NetR9 .T02
>>> files
>>> Simon (and any other NetR9 users),
>>> followup from 2 June:
>>>> Information from Trimble is pointing toward [specification changes
>> of
>>>> record 27 for NetR9]. Trimble is
>>>> in the process of reviewing an updated draft documentation on the
>>> change
>>>> for record 27, and then, hopefully, they'll send it along here so I
>>> can
>>>> see what needs to be changed in the teqc code.
>>> This is mostly under control with the new record 27 documentation from
>>> Trimble.
>>> The basic idea is that Trimble is now using some previously unused
>> bits
>>> to
>>> enable new byte sequences within the record for some new data elements
>>> (of which
>>> some are for engineering and others might be of use in some RINEX).
>>> That you
>>> were able to get anything reasonable at all from teqc, as previously
>>> written
>>> for the original record 27, was very fortuitous. I'm still awaiting
>>> clarification on a few minor points -- on parts that probably would
>>> not show up in normal NetR9 user data. And the new "record 32" (0x20)
>>> that
>>> was in your data file is encoding of Galileo/GIOVE ion/UTC model
>>> parameters.
>>> The mismatch of the antenna number string from what's in the .tgd/.mes
>>> files
>>> vs. the RINEX 2.11 direct from the NetR9 is still a mystery however.
>>> 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