This is a first for me. I logged some GPS data yesterday to tie two spikes and washers from the main project control point less than 2800 ft. away. None of the stations were particularly obstructed and I got more than twenty minutes of observations at 5-second epochs on each.
To process GPS data in GPSurvey, the vintage software I still use (because ordinarily it works perfectly well), I've been using the RinexDates software that Christ Lambrecht et al developed to backdate the RINEX files generated from the native Trimble DAT files. The backdated files (both OBS and NAV) now have a date in 2008 before the WAVE processor in GPSurvey and TGO blew a gasket and refused to continue on. I've been importing the backdated RINEX files to process the baselines.
Ordinarily this has worked splendidly, but the data from yesterday, not. I'm thinking it probably is something in the RINEX file that I generated from the DAT files since the DAT files will process fine when "Code" and "Float" are selected as the final solutions. The DAT files won't give a Fixed Integer solution because of the date issue, but the Float solutions actually look quite good: eight satellites, generally free of excessive cycle slips. RINEX from them should work, but doesn't.
Here's the ask: would anyone be willing to examine the RINEX files to see whether there is some obvious problem with them that I've missed that is preventing them from processing?
Send Them My Way
email in my profile
Also send me your nav files besides the obs files.
Paul in PA
teqc qc report
Hmmm. So the qc report that teqc generated from a pair of NAV and OBS files showed:
[pre]
*********************
QC of RINEX file(s) : 06550611.13o
input RnxNAV file(s) : 06550611.13n
*********************
4-character ID : (name = 1) (# = 1)
Receiver type : TRIMBLE 4600LS (# = 20060655) (fw = Nav 1.11 Sig 0.06)
Antenna type : 4600LS INTERNAL
Time of start of window : 2008 Mar 2 20:53:50.000
Time of end of window : 2008 Mar 2 23:01:25.002
Time line window length : 2.13 hour(s), ticked every 1.0 hour(s)
Observation interval : 5.0000 seconds
Total satellites w/ obs : 13
NAVSTAR GPS SVs w/o OBS : 2 3 4 5 7 8 9 10 12 15 17 18
19 21 24 26 27 28 29
NAVSTAR GPS SVs w/o NAV : 1 6 11 13 14 16 20 22 23 25 30 31
32
Rx tracking capability : 12 SVs
Poss. # of obs epochs : 1532
Epochs w/ observations : 1532
Epochs repeated : 0 (0.00%)
Complete observations : 0
Deleted observations : 11693
[/pre]
Basically, it's reporting that the observations are there, but were somehow not, that they were "Deleted". Have to run the same check on the RINEX files before backdating.
teqc qc report
Per the most recent entry in [msg=101542]this thread[/msg], Christof found a bug in RinexDates that triggered on March 1 and is working on a fix.
RinexDates 1.5
> Per the most recent entry in [msg=101542]this thread[/msg], Christof found a bug in RinexDates that triggered on March 1 and is working on a fix.
Yes, I missed that bit of information. John Minor sent me a link to the new version which works perfectly. Problem solved!
I can't begin to say how much of a help the RinexDates software has been.
Oakie Dokie, I Am Off To Bed
Not that I was staying up just for Kent. I've been listening to about 3 hours of Willie Nelson and his Johnny Cash duo just ended.
Paul in PA
Oakie Dokie, I Am Off To Bed
> Not that I was staying up just for Kent.
I appreciated the offer. As it turns out, the RINEX files would have shown that there was a problem that the new version of RinexDates solved. Whew!
Kent, I thought you have TBC and the capability of processing L1 baselines? Have you ran it through TBC yet to see if it's an issue with a ghost in the machine or the data itself??
> I thought you have TBC and the capability of processing L1 baselines?
I have TBC, but prefer to process baselines in GPSurvey.