[teqc] Re: Teqc + NetRs phase values

Brian Frohring Brian_Frohring at Trimble.com
Tue Dec 21 17:31:00 MST 2004


I'm sorry about the delays getting back to you regarding this issue.
The large phase values occur when clock steering is enabled in versions
of firmware prior to v1.11.  Operating the receiver with clock steering
disabled or using v1.11 firmware would be the recommended
configurations.  Since the v1.11 firmware is not on the web yet, I can
send this to you via e-mail if you like.

Please let Lou/me know if you have any problems recovering the data with
the large accumulated phase values.

Best regards,
Brian Frohring


 > -----Original Message-----
 > From: teqc-bounces at ls.unavco.org 
 > [mailto:teqc-bounces at ls.unavco.org] On Behalf Of Lou Estey
 > Sent: Saturday, December 18, 2004 8:35 AM
 > To: James Foster; Miranda.Chin at noaa.gov
 > Cc: Benjamin A. Brooks; teqc support
 > Subject: [teqc] Re: Teqc + NetRs phase values
 > James Foster wrote:
 > >     I have just started experiencing the problem noted in the Teqc 
 > > fixes page, that the NetRS with clock-steering can lead to 
 > an overflow 
 > > in phase. Do you have a version of teqc available with this fix 
 > > incorporated?
 > Miranda Chin wrote:
 >  > The 'teqc +qc' displayed error messages:
 >  >
 >  > teqc: 426087failure to read 
 > "-1331971177.40449-1037895714.3" on line 47  > of "ilsa3130.04o"
 >  >    (invalid LLI (Loss of Lock Indicator): should be 0-7) 
 > ... exiting
 >  >
 >  > It appears the L1/L2 observables are greater than F14.3 
 > can hold. In  > fact, these are F15.3.
 >  > The observables were generated from a Trimble NETRS receiver.
 >  >
 >  > Have you run into a similar problem? If yes, how do you handle it?
 > hi James, Miranda,
 > We've known about this problem with NetRS phase values at 
 > least since the spring when testing the NetRS for PBO.  
 > Basically, the phase values can have very large whole-cycle 
 > ambiguity offsets.  Trimble has a new NetRS firmware -- at 
 > least for PBO testing -- which eliminates the problem.  
 > (Brian Frohring or someone else at Trimble might want to 
 > comment further.)
 > With regards to teqc: Yes, there is a fix in place to 
 > eliminate this problem -- assuming that you would be using 
 > teqc to translate NetRS raw data (.dat or RT17) into RINEX.  
 > If you are talking about reading a messed up RINEX file, 
 > then no, there is nothing that can be done except 
 > re-translate the original raw data into corrected RINEX.
 > Just let me know which build of teqc you are currently using (e.g.
 > execute `teqc +id | grep build` and send me that result).
 > 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