Hello All,
A little background first;
Sense the recent GPS week rollover I now have an issue with my static files from my Promark 500. I have updated the firmware in the receiver to the latest version available, it works like normal when connected to a base or Network. But I had to do a static session in a very wet tamarack swamp and found that the data has the wrong week in it. The only way to get this data to process was to use Spectra's Rinex converter and open the newly created files with text pad and manually change the dates.
So once I have the new Rinex files I sent the data to OPUS, and ran it through TBC to process. I am questioning the data from both programs now. TBC and OPUS differ by 5.3 feet.
So my question are this.
Is there a way to edit the date in the original ATOM file with out converting to Rinex, So I can just import directly into TBC?
Or Is it possible to change the date in the receiver before I start a static season?
Are there any other options aside from purchasing newer equipment?
Also why is there such a difference between TBC and OPUS when using the same data file?
Any help is greatly appreciated,
thanks,
Any chance one position is NAD83 and the other WGS/IGS ?
unfortunately not, I checked that also, The Wisconsin Network is set to NAD83/2011, And the Opus solution gives me both NAD83/2011 and IGS08, I made sure I am using the NAD83/2011 values. But oddly enough the IGS08 values fall closer the the TBC solution at 1.08'.
Thanks,
You updated the PM500 firmware to the post WNRO version: V6.8 already?
If so, and you are using the latest RINEX converter (4.7.2) then I am surprised that the generated RINEX has incorrect dates. I don't have a PM500 to test, but I have several PF500's and they seem to work just fine.
?ÿ
I don't think the week rollover is relevant here.?ÿ If you can get a solution that is in the ballpark, the week issue has been taken care of.
>>the IGS08 values fall closer the the TBC solution at 1.08'.
That tells me there is a datum selection in TBC that is picking IGS08.
The residual 1.08 may reflect how undependable the result is.?ÿ That's an ultra-rapid orbit solution with only 79% of the observations used - far from ideal.?ÿ I'm not familiar?ÿ with TBC, but I wonder if re-running both, now that rapid orbits should be available, and some thought as to choice of elevation mask angle and/or excluding questionable satellites, would give better agreement.
How tall is the vegetation??ÿ If you aren't fully above it then I'd think you need to do the GPS in the open field that Google Earth shows about 150 yards away, and traverse to the point in the bog.
Mark, "You updated the PM500 firmware to the post WNRO version: V6.8 already?" Yes I had to update for the GPS week roll over.
"If so, and you are using the latest RINEX converter (4.7.2) then I am surprised that the generated RINEX has incorrect dates. I don't have a PM500 to test, but I have several PF500's and they seem to work just fine." This may have bee the problem the Rinex Converter I used is 4.6.11, I will try the latest 4.7.2 and see if that work, Thank you,
Bill, I am planning to re run the OPUS data either today, or tomorrow, hopefully that helps.
Thanks!
So after rerunning everything and double checking programs, it turns out my Rinex converter was to old and i had to get the most current version, which fixed the Week Roll over problem.
But after rerunning with the new Rinex file, i get the exact same results from both TBC and OPUS(now rapid static instead of ultra rapid).
I have tried to check setting in TBC as best as I know how but it looks to have the correct setting selected.
So I believe I will have to traverse?ÿ into the corner, but will also re static the corner to compare.
Thank you for your help.
Send me your G file and I will take a look at it. 🙂
