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

Lennard Huisman L.Huisman at curtin.edu.au
Tue Oct 12 20:13:46 MDT 2010


Hi Lou,

Thank you for all the effort to make it possible to process the NetR9
data.

I have just finished converting 2.5 months of GPS/GLONASS/GIOVE
(L1L2L5C1C2P2C5S1S2S5) data of 2 NetR9 receivers to Rinex with the
interim build of teqc you sent me this weekend. I did not have any
problems!

Thanks again!
Lennard

> -----Original Message-----
> From: teqc-bounces at ls.unavco.org [mailto:teqc-bounces at ls.unavco.org]
On
> Behalf Of Lou Estey
> Sent: Wednesday, 13 October 2010 4:35 AM
> To: teqc
> Subject: Re: [teqc] G00 appearing in RINEX from Trimble NetR9 .T02
> files
> 
> 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:
> -n_GPS
> -n_GLONASS
> -n_SBAS
> -n_Galileo
> 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.
> 
> cheers,
> --lou
> 
> 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_GLONASS
> > -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
> >>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> _______________________________________________
> teqc mailing list
> teqc at ls.unavco.org
> http://ls.unavco.org/mailman/listinfo/teqc


More information about the teqc mailing list