A couple of days ago I ran a static session about 1 hour 40 minutes long, the last 20 minutes of which crossed over into the next UTC day. When I try to process this in TBC against 24-hour CORS files from both days, the session gets divided into 2 baselines, one in each UTC day. The baseline using the final 20 minutes processes nicely, but the 80-minute session from the prior day fails with no indication of a reason. I suppose I can RINEX and split the file into discrete sessions for each day, but I'd rather not if I don't have to.
Have any of you run into this before, and if so how did you solve the problem?
Two weeks ago I started at UTC 23:02 on 5/12 and ran a 2:08 session past UTC midnight. When I got in the office I split out 0:57 and sent to OPUS-RS and was totally shocked to get a solution. As to the long file OPUS would abort it with a litany of excuses. Usually it is the other way around, OPUS first OPUS-RS later.
On 5/13 the IGS site still only had the u18 ephemeris for 5/12 and nothing for 5/13. I did find newer ephemeris on the NGS ftp site. Everything aborted on 5/13 including the file I had a 5/12 RS solution for.
It was noon on 5/14 that I finally got an OPUS solution and my other OPUS-RS solution using the ultrarapid ephemeris.
By that time OPUS should have had the rapid available. At 5/14 UTC 18:10 I finally got a rapid solution. It was just odd circumstances and not explainable but patience usually pays off.
I believe it is just the OPUS defaults on what ephemeris to use and it may not be flexible enough. It is my understanding that the U18 is an 18 hour rapid Rapid file and the last 6 and the next day's 24 are predicted. If the Rapid orbit delivery is delayed OPUS may just panic.
In my software it is happy to use a U18 but sometimes balks at a Rapid for one day and only predicted for the second. Your software may have similar preferences. Then again sometimes you have to go get the best orbit yourself. Does TBC look at more than one orbit source?
BTW, I would not use two 24 hour CORS files I would get a ufcors multi hour file that runs past midnight.
Paul in PA
I said that there was no indication of the reason for failure, but I was wrong -- the error message shows up as a tooltip and states "Insufficient code measurements available 1% of the time at the rover receiver." I think that's an unlikely cause of the failure -- all the other data from that equipment and that session is good, as is other data from other sessions at the same site -- but that's what TBC is reporting.
Paul in PA, post: 374383, member: 236 wrote: BTW, I would not use two 24 hour CORS files I would get a ufcors multi hour file that runs past midnight.
I'll give that a try and see if it works. I use the 24-hour files because I have other receivers running during the same day, one of the sites I'm monitoring is itself an NGS CORS, and one of the CGPS stations is a BARD site.
1% of the time sounds like the OPUS abort message that says "your file ends before it begins" check the dates and times.
Look in the two 24 hour RINEX files and see if there is a duplication of observations at UTC midnight, if so delete one.
Keep the 24 hours for your other work and download or create a shorter file just for this project. Does TBC have a tool to merge files?
Also from time to time a project past UTC midnight requires me to get ephemeris for 2 different days. If you wait for the precise ephemeris that is 7 days long. GPS week midnight can be a different problem even if your software is happy the rest of the week.
Paul in PA
