Nothing posted since 5/28/17 for GPS week 1948. Is someone on vacation?
Are you looking at this? It's where I check, and yes, 1949 does seem to be a bit overdue.
https://igscb.jpl.nasa.gov/components/prods_cb.html
That site says "The final combinations are available at 12 days latency." That would be Thursday evening US time, or more realistically Friday morning, but it is more often mid-day Monday or even Tuesday.
I have found there to be little to no significant different between the rapid orbits and the final orbits for almost any conceivable work.
I guess it depends on how important speed is to you versus a possible tiny improvement. They do the final update because they think it's a little more accurate. Sometimes there is no change and other times it moves the solution as much as a cm or two.
I wait for the finals before submitting an OPUS Shared solution, because there is no hurry for those. NGS says they would accept Rapid orbits, which I don't understand. Don't they want the best possible?
The difference between a Rapid Orbit and Final Orbit solution is well below the precision of the solved position. NGS understands that other components vary in any OPUS solution, things like on any given day the actual position of a CORS can vary from any other day and from the currently accepted published position.
If you can truly understand and accept the facts of any Least Squares Solution you would not let it bother you.
Depending on when I get back from the field and into the office, I will sometimes accept an Ultra-Rapid solution given good numbers and never consider having to even wait for the Rapid Orbit. The main reason I wait and resubmit is not for the better orbit but for the data to be in place from the closer or often preferred CORS. Typically if I am dissatisfied with an OPUS-S solution I break it down for multiple OPUS-RS submissions. Often my meaned OPUS-RS positions only confirm that the OPUS-S was in fact better than I believed.
The Final Orbit requires compilation of quite a bit of data from all over the world and there are may reasons data transmission is delayed.
Paul in PA
I use ultra-rapid orbits all the time for static processing in TBC... sometimes the job can't be held up waiting for orbits. It's not at all uncommon for me to need to process an afternoon session first thing the following morning. I prefer to use the rapid orbits when possible but it doesn't make that much difference, especially on short to medium length baselines.
We use rapid orbits in our normal workflow~ as state above there is minimal improvement in using precise, but like Bill I wait for pre v use orbits to submit observations for OPUS-DB. I'm trying to make a concerted effort to support the development of the NGS database in my state
The website I linked above now (Tues 7:30 pm CDT) lists week 1949 precise orbits as available. It was updated some time in the last hour.
That's 17 days past the end of the week, not 12 as advertised, and about as late as I've ever seen except for when Monday was a holiday.
However, I didn't wait long enough for NGS to do their update and my week 1949 session came back with Rapid orbits.