Can anyone tell me or point me to information on the time frames for getting OPUS solutions back?
Does it vary by location?
Yesterday I collected 5 hours of data ending around 5pm. I uploaded it around 9 PM and got a solution back in ten minutes. Other times I collect a file during the day (sometimes ending the file early in the day like around noon) and it wont upload that night. I get the following error 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
6029 After the single baseline analysis, fewer than 3 useable
6029 reference stations remain. Aborting.
6029
Sometimes it will go through the next morning and sometimes I have to wait until the next night.
We move around a lot and I just can't seem to figure out the timing on this stuff.
What I really would like to know is if there is a certain time that if I close my file before then I can for sure get a solution that night?
OPUS time frames,You're Kidding Right ?
Weekdays are busier than weekends.
Sometimes weekends are reserved for maintenance.
Sometimes the nearest CORS data just does not get there, or is bad. Bad data can sometimes be improved at NGS, but it is not always automatic. Missing data also sometimes takes human intervention.
Don't go past UTC midnight unless you are prepared to wait an extra day, or break your files up by day.
Rapid orbit is usually available by midday the next day.
The sun does not always cooperate.
some days the satellites do not always cooperate.
Your observations may not be as good as you think.
Some days the dog eats the NGS's homework.
And some days it just does not matter.
And some days you just get what you pay for.
Paul in PA
OPUS time frames,You're Kidding Right ?
Thanks.
No not kidding.
I know they have hiccups from time to time and I know when they get high demand things are slowed down, I was just wondering if there was a cut off time like UTC midnight like you mentioned.
OPUS time frames,You're Kidding Right ?
UTC midnight is a problem on the next day because OPUS will not use the rapid orbit for one day with the ultra-rapid for the next day. If you submit very early local time the next day you may get an ultra-rapid/ultra-rapid solution. After that you best wait.
After that it can be a crapshoot.
I would say error messages have a 50% chance of being right, the computer is just giving you it's best guess.
Paul in PA
In my experience, the only thing to look out for is UTC date changeover. If you're on east coast times, the changeover is at 8pm, currently.
Sometimes there are comms problems between the base and NGS so it may take longer for the data to be available for a certain base, but I've never had a situation where I haven't gotten something back. The only question is how quickly.
You can also try auspos, which I used when OPUS was down for days last fall.
> Can anyone tell me or point me to information on the time frames for getting OPUS solutions back?
>
> Does it vary by location?
>
> Yesterday I collected 5 hours of data ending around 5pm. I uploaded it around 9 PM and got a solution back in ten minutes. Other times I collect a file during the day (sometimes ending the file early in the day like around noon) and it wont upload that night. I get the following error 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
> 6029 After the single baseline analysis, fewer than 3 useable
> 6029 reference stations remain. Aborting.
> 6029
>
> Sometimes it will go through the next morning and sometimes I have to wait until the next night.
>
> We move around a lot and I just can't seem to figure out the timing on this stuff.
>
> What I really would like to know is if there is a certain time that if I close my file before then I can for sure get a solution that night?
>
>
> What I really would like to know is if there is a certain time that if I close my file before then I can for sure get a solution that night?
Well, I don't know. I've gotten them in 5 minutes and then 5 days. Typically, if I don't get it within an hour, I re-submit and it tells me if it's still in the que.
Also, have you really beta tested the difference between rapid and ultra rapid orbits? If you haven't, you should! We note up to 0.15' difference between ultra rapid and rapid. We also note, typically, 0.02' between rapid and precise.
In other words, getting one that night, especially if you're working on large networks and using OPUS to connect instead of other methods, can and will muck up a network where you can't tell if it's you or memorex that's wrong. Wait till the next day or at least resubmit the file the next day for a rapid orbit.
> >
> >
> > What I really would like to know is if there is a certain time that if I close my file before then I can for sure get a solution that night?
>
> Well, I don't know. I've gotten them in 5 minutes and then 5 days. Typically, if I don't get it within an hour, I re-submit and it tells me if it's still in the que.
>
> Also, have you really beta tested the difference between rapid and ultra rapid orbits? If you haven't, you should! We note up to 0.15' difference between ultra rapid and rapid. We also note, typically, 0.02' between rapid and precise.
>
> In other words, getting one that night, especially if you're working on large networks and using OPUS to connect instead of other methods, can and will muck up a network where you can't tell if it's you or memorex that's wrong. Wait till the next day or at least resubmit the file the next day for a rapid orbit.
Thanks for the info.
We are just trying to plan out trips to the field to collect static data for OPUS and when we can return to do our stakeouts. A .15' difference for what we are doing makes no difference but it is good to know.
> > >
> > >
> > > What I really would like to know is if there is a certain time that if I close my file before then I can for sure get a solution that night?
> >
> > Well, I don't know. I've gotten them in 5 minutes and then 5 days. Typically, if I don't get it within an hour, I re-submit and it tells me if it's still in the que.
> >
> > Also, have you really beta tested the difference between rapid and ultra rapid orbits? If you haven't, you should! We note up to 0.15' difference between ultra rapid and rapid. We also note, typically, 0.02' between rapid and precise.
> >
> > In other words, getting one that night, especially if you're working on large networks and using OPUS to connect instead of other methods, can and will muck up a network where you can't tell if it's you or memorex that's wrong. Wait till the next day or at least resubmit the file the next day for a rapid orbit.
>
> Thanks for the info.
>
> We are just trying to plan out trips to the field to collect static data for OPUS and when we can return to do our stakeouts. A .15' difference for what we are doing makes no difference but it is good to know.
I agree, in part, that 0.15' makes no difference in the relative accuracy of your network. However, there are times where this is too much or makes you scratch your head.
My scenario ALWAYS seems to be "Here is a well we want staked". So we go and connect to NAD83 via OPUS and tie everything down and stake the well. Then, next month "Here go stake another well 5 miles away" so we go and connect to NAD83 via OPUS over there. THEN it's "We need a pipeline run between the two" and one base station just won't get that far or it's infield surveying or something else. For the reasons that I NEVER know how big my network may possibly be (some end up being 10's of miles) we can't really set up a network and stay in a "relevant range" so we use the above method. We check VERY well using this method EXCEPT where we took OPUS solutions for one day and didn't know the differences between the ephemeris' and end up either fixing huge areas of points or just knowing that at least a tenth is floating in there.
For the McMillimeters in the group, I know, it's overkill. However, as one of my survey mentor's once said "If you start with %(!t, you can only spread mustard on it cause it won't get any better." and "Adjustments make good points bad and bad points worse." For this reason, I try to make the points as ultra tight as possible so that WHEN I have to run between them, I know WHAT the answer SHOULD be rather than questioning what the hell I did two years before when I set that unit/field/project up.
Ultra rapid vs Rapid
Out of curiousity I resubmitted the file today and compared the rapid vs ultra rapid solution.
There was a difference of .009' on the horizontal and .04' on the vertical.
The difference between the OPUS solution and my original WAAS position was 5.279' on the horizontal and 2.285' on the vertical.
Ultra rapid vs Rapid
WAAS is better than that. You're probably comparing NAD83 to WAAS coordinates. WAAS is in ITRF, not NAD83. The difference is several feet.
> Out of curiousity I resubmitted the file today and compared the rapid vs ultra rapid solution.
>
> There was a difference of .009' on the horizontal and .04' on the vertical.
>
> The difference between the OPUS solution and my original WAAS position was 5.279' on the horizontal and 2.285' on the vertical.
WAAS
> WAAS is better than that. You're probably comparing NAD83 to WAAS coordinates. WAAS is in ITRF, not NAD83. The difference is several feet.
>
> > Out of curiousity I resubmitted the file today and compared the rapid vs ultra rapid solution.
> >
> > There was a difference of .009' on the horizontal and .04' on the vertical.
> >
> > The difference between the OPUS solution and my original WAAS position was 5.279' on the horizontal and 2.285' on the vertical.
Can you explain this to me? I am working in state plane coordinates. What I am comparing is the state plane coordinates from the data collector of my WAAS position to the state plane coordinates from OPUS.
If the WAAS is ITRF doesn't the data collector know that when it converts to state plane coordinates?
WAAS
Any data collector that I have used is not that smart.
WAAS
State Plane is a coordinate system. UTM is a coordinate system.
NAD83 is a datum. ITRF is a datum.
You can have SPC/NAD83 coordinates and SPC/ITRF coordinates. Same SPC State/Zone/Units, but several feet apart due to the difference in datums.
I doubt the data collector will handle this automatically. It can't automatically determine which datum the incoming GPS data is using.
> > WAAS is better than that. You're probably comparing NAD83 to WAAS coordinates. WAAS is in ITRF, not NAD83. The difference is several feet.
> >
> > > Out of curiousity I resubmitted the file today and compared the rapid vs ultra rapid solution.
> > >
> > > There was a difference of .009' on the horizontal and .04' on the vertical.
> > >
> > > The difference between the OPUS solution and my original WAAS position was 5.279' on the horizontal and 2.285' on the vertical.
>
> Can you explain this to me? I am working in state plane coordinates. What I am comparing is the state plane coordinates from the data collector of my WAAS position to the state plane coordinates from OPUS.
>
> If the WAAS is ITRF doesn't the data collector know that when it converts to state plane coordinates?
WAAS
Thanks for the replies. I was aware that they were datums.
I guess what I was trying to say is if I specify NAD83 SPC in my data collector it is doing conversions to give me those positions.
I know the the data collector can not know every datum of the incoming GPS data but the main SBAS in the US is WAAS. You would think it would properly account for this but I very well could be wrong.
Ultra rapid vs Rapid
I don't know what software you're using but if you apply an ITRF - NAD83 transformation to your WAAS data it should tighten it up quite a bit.
WAAS
Trimble Access has a datum shift built in - instead of US State Plane 1983 use State Plane 1983 (ITRF to NAD83)
Ultra rapid vs Rapid
> Out of curiousity I resubmitted the file today and compared the rapid vs ultra rapid solution.
>
> There was a difference of .009' on the horizontal and .04' on the vertical.
>
> The difference between the OPUS solution and my original WAAS position was 5.279' on the horizontal and 2.285' on the vertical.
The cool thing about this testing is now you have probably hundreds of old solutions that you can resubmit and really check ultra rapid vs. rapid or precise. Resubmit a bunch of the others.
Yes, sometimes they hit flat and sometimes, they don't. The WAAS coordinates were an autonomous "here" position and should be different from NAD83 by as much as 10 feet.
Ultra rapid vs Rapid
WAAS is the opposite of "autonomous". WAAS uses corrections determined at a network of base stations (usually at FAA ATC facilities). Autonomous means "no corrections", just using the broadcast ephemeris.
Ultra rapid vs Rapid
> WAAS is the opposite of "autonomous". WAAS uses corrections determined at a network of base stations (usually at FAA ATC facilities). Autonomous means "no corrections", just using the broadcast ephemeris.
Correct. I do not use the "here" function when setting up my base. I do a RT differential and collect about 15-30 minutes of WAAS data, save that point, then use it to start my base.
I will look into the ITRF - NAD83 conversion.
My WAAS positions are usually within 6' or so of the OPUS solution. This ~5' was actually on the higher end of the differences. I will double check but I don't really recall them being shifted the same way as one would expect if it was a datum issue. For example on this one I think the WAAS position was NW of the OPUS position and the last one I did the WAAS was SE of the OPUS.
I will double check though.
