Has anyone gotten a good result using opus on 02-Jan??ÿI get:
??After the single baseline analysis, fewer than 3 useable?ÿreference stations remain. Aborting.??
I am having the same issue.?ÿ
OPUS RS 1 hour session.
I’m in DuPage Co. IL. No-go just now, 8:30 CST.
Where did you log?
I noticed a high ‘red’ failure in RS. I guess it’s a log jam.
I believe that OPUS is down for all observations collected in 2020.
I can't even process 4 hour files from CORS sites. I have gotten a few solution back on really - really clean data; however they have peak-to-peak ranges of 5+ meters and less than 10% obs used. So of no value.
I believe that NGS is working on a solution.
Mark
What happened, someone forget to change file names from .19o to .20o ?
Kinda related.?ÿ In NYC there are thousands of parking meters that wont take credit cards...why? Because the software installed in them refuses to accept any date after December 31, 2019...it like Y2K...2o years late.
?ÿ
?ÿ
Kinda related.?ÿ In NYC there are thousands of parking meters that wont take credit cards...why? Because the software installed in them refuses to accept any date after December 31, 2019...it like Y2K...2o years late.
?ÿ
?ÿ
I love it!
We don't have parking meters where I live, and all of the retail business's around here still accept CASH, although MOST of them will accept Credit/Debit Cards (subject to minimum dollar amounts in some cases).
I get the whole "plastic" thing, but prefer cash whenever possible. Different strokes for different folks.
Loyal?ÿ
I went to the CORS RINEX ftp site and downloaded 2 1 hour files from a nearby CORS. I merged them into one file and submitted to OPUS as well as the legacy OPUS site and was told that OPUS was having a problem. The RINEX data looked good and the ftp site had orbit files available but I did not see any "N" files to download. Had I had an actual observation from today, I could have created "N" files for my CORS and processed it myself.
I would surmise that somebody responsible for the "N" files was asleep at the switch. That somebody may have missed that OPUS still used teqc somewhere in the process and did not update the now not supported teqc. I do know that I have to update my text editor to now accept those .02o files.
Paul in PA
FIXED. At least for OPUS-Static in production. It was a Y2K-type problem.?ÿ
Your Federal Government at?ÿ work.?ÿ NGS (and the Forest Service, NOAA, Fish & Wildlife and BLM) are now so woefully underfunded that they have to drop the hat on many basic services that should have 100% availability 24/7 given it's not rocket science.?ÿ Well, the GPS system is, but the US military owns and runs it so that works good.?ÿ I can imagine OPUS becomes a pay per use subscription in the near future; the user fees concept to cover operational costs.?ÿ My boat documentation, Radiotelephone license & dinghy registration used to be 0$ but now it's about $400/yr.?ÿ We shall see if OPUS remains a free service.
the user fees concept to cover operational costs.
Shhhhh... don't give anybody ideas.
If you are going to that much trouble (splicing files) why not just use UFCORS? It will do the splice for you and it will return matching NAV files.
The NAV files are not stored in the FTP site with the OBS data. For each Julian day, they are stored in the primary Julian date folder. So for example on J003 of 2020:
ftp://www.ngs.noaa.gov/cors/rinex/2020/003/brdc0030.20n.gz
holds a generic GPS NAV file and
ftp://www.ngs.noaa.gov/cors/rinex/2020/003/brdc0030.20g.gz
holds a generic GLO NAV file.
Since the NAV files are identical for all sites worldwide, there is no reason to keep multiple copies, these two daily files suffice for every CORS site.
I can verify that OPUS-Static is now working well.
I just ran ~50 24-hour files for the private CORS sites that I manage and there were no surprises.
The trends into 2020 match those from the end of 2019.
Here is a sample for PUC2 in St George Utah:
