I set up my Zephyr Geodetic and 5700 receiver to collect fast static and let it sit for a couple hours - actually have done it 3 times now. I've got the v2.32 fw on the receiver so it collects correctly in UTC. I use the RINEX utility to create the 16o file and upload to OPUS with all the fields probably entered correctly and so far keep getting this message:
2005 NOTE: The IGS precise and IGS rapid orbits were not available
2005 at processing time. The IGS ultra-rapid orbit was/will be used to
2005 process the data.
2005
9011 OPUS could not process the data file that was submitted. The data was
9011 either very noisy or it was collected in kinematic mode.
9011
Anyone know if this is due to an IGS orbit problem (not likely 3 times in a row), an instrument problem, a Dave problem. Or what?
My set up is basically Zephyr on tribrach and legs over a point with known local coordinates, connected to the 5700. You don't use a 2nd receiver do you?
Thanks.
Replies
Thanks (mahalo from Hawaii). I was able to process with both OPUS and Trimble RTX and they returned nearly identical data (differing by 1½mm horizontally and vertically, small, but I still have a question about the antennae that I hope will answer it some time). They both gave me helpful info - Trimble processing helped identify the exact antennae and is very simple and quick to use. The only drawback was that I am so far unable to convert the El Ht given. It tried CorpsCon and VertCon with no luck because for some reason they are not recognizing my lat long - I spent a half hr plus looking through the manuals and entering the info in different formats before coming to the belief that they haven't built vertical info in for this location (big island hawaii). CorpsCon coudn't even convert the horizontal here from geodetic to spc, giving me an out of bounds error. I've got a question in to NGS about it to check because I was able to get info for any other place on the mainland.
So anyway, even though OPUS has a few more hoops to jump through, I like that it returned not only the NAD83-PA11 but also UTM and SPC with the adjusted ortho height as well.
Thanks so much for your help with this. These worked, and helped me out a lot at a time when I can really use this info.
Dave,
Can you send me the Lat., Long., and Ell. Ht. for the point that you are unable to convert to an Ortho Ht? I may have a solution but would like to try it out first. The logged GPS file would be ideal however I understand you not wanting to send data to an unknown person. Even an approximate LLH would work (need to know what realization the position is... (i.e. NAD83 2011, etc).
John
It is the NAD83 2011 using the Pacific tectonic plate (PA11).
Here are the raw .t01 file from the 5700 and the Trimble rtx report returned showing the ell ht = 86.825. I'm assuming it's based on GEOID12B.
Neither CorpsCon nor VertCon could give me ortho height from the ell ht for a particular datum at that location (I was looking for NAVD88).
OPUS did return an NAVD88 ortho height of 67.294, which *could be* good.
Thanks for your interest in this.
NGS recently sent me a message asking if I had recovered a certain monument as the results I sent matched that monuments location & elevation almost exactly. Yea, I was set up on it. They said it hadn't been recovered in 5 years but there it was, obvious & apparent in plain sight.
It did get it fixed using the methods above. As far as the fast static setting, it may be semantics with my old hardware. If I configure the 5700 receiver either through the configuration utility or by adjusting a survey style through the Survey Controller software (v10.71), I don't have a 'static' option under available survey types, just 'fast static' where I can adjust the minimum read times based on available satellites. I assumed (and you know how that goes...) that if I run a fast static configuration for more than 2 hours, it is a 'static' collection. Not completely sure about that. I have a few other questions that will bug me.
Cool that you were able to help NGS out and that they continue to be diligent with their PIDs. I've found a couple obvious ones in my work here just because they were nearby and always get a nerdish version of treasure hunters delight. I do hope to set up on one sometime and check in with these post processing techniques. I think that would help answer another hardware question that's bugging me about the old Zephyr I'm using.
Mahalo.
If you have more than 3 hrs of data, OPUS won't process. Try processing in normal mode.
Check your Julian date. Is it correct? If not, try this:
http://www.terrasurv.com/fixweek/FixWeek.zip
This only works with .dat files. You will have to download with Data Transfer (Trimble) to create them.
HI, John. I had actually done that on the first 2 static setups and it worked to fix the date. After no response from Trimble support on updating my firmware (they probably thought it was a 12 year old request and ignored it...), I found a way to get it updated to v2.32. The last setup I ran logged correctly per UTC.
Mahalo!
Dave,
Have you tried Trimble's RTX post-processing option? http://www.trimblertx.com/UploadForm.aspx
Mike
Very cool. This took a little of the guesswork out by recognizing my antennae correctly from the Trimble data file. I also got OPUS to work correctly from John's info above. See my comment below regarding the 2.
-
1
-
2
of 2 Next