I recently received my Reach M2 with Swift Navigation (Harxon HXCGPS500 w/NGS Calibration) antenna and have been eagerly testing it for accuracy. I have a couple of NY HARN monuments in the area that I have been utilizing to test against OPUS results. Unfortunately, my 2+ hour observations are being spit back at me with the following message: Your data file is less than 2 hours long. Your file will be processed by OPUS-RS instead. when it is over 2 hours. And then I get the following message from OPUS-RS: “Your input dataset is too short. OPUS-RS will not attempt
6019 a solution with less than 7.2 minutes of data.” The file is over 2 hours long!
Then I converted the raw ubx file to Rinex and uploaded to OPUS again and the 2 hour file was accepted. However, then received following message: “OPUS could not process the data file that was submitted. The data was
9011 either very noisy or it was collected in kinematic mode”.
I have a lot of experience and success with OPUS using other receivers…just not the M2 …yet. Configuration is Static 1Hz and I start - Stop individual log files.
Anyone else have this issue? Check out the satellite plot from RTKLib. I have sent this issue in to Emlid but have not heard back yet so I figured I would post this here in case someone in case anyone has seen this very same issue.
Hi David, looking at sat plot you show I see that it had GLONASS and others in the file. OPUS is GPS only. I’d convert the UBX file using GPS only in 2.10 rinex version. The file you sent probably only had a few minutes of GPS data at the beginning of the observation and didn’t understand the other data constellations. Unless you’ve got really clean GPS data, OPUS will spit back at you. I had problems with my M2 first time to OPUS also. This was due to bad data at the closest CORS I selected. You can go here https://www.ngs.noaa.gov/UFCORS/
and select various stations and also see static plots of station data. Some CORS really stick out like a sore thumb. If I have time tomorrow, I’ll try and process your data
I agree with Bryen, OPUS requires GPS data only. You can convert your UBX data to RINEX 2.10 file with GPS observations only using RTKCONV. The procedure is described in our PPP guide.
Hello @tatiana.andreeva Still no dice. I stripped all but GPS observations out of Rinex file and still get the Error of “OPUS could not process the data file that was submitted. The data was
9011 either very noisy or it was collected in kinematic mode” .
I’ve checked the quality of the raw data you shared, and they seem to be quite good. So I’ve performed a try to process them in OPUS myself.
I uploaded the file to Static PPP, and it was rejected. After that, I tried Rapid-Static, and the file was processed fine. According to the OPUS report, 87% of observations were used in the computation. I assume it’s the reason why it can’t be processed with Static: there is not enough data for it.
According to OPUS support, approximately 90% of solutions use 70% or more of the observations, and approximately 30% of solutions use 90% or more of the observations. They also say that the longer the session duration is, the better the results tend to be.
Also, according to their stats from here, for Static PPP, it’s better to record log for more than 4 hours.
I converted your data to Rinex 2.11 and ran it through WinTeqc to check the data. It reported an error with R26 and invalid data on G23. I then excluded those two satellites when converting to Rinex again. This fixed the time duration issue but OPUS then reported the same 9011 error you had. I have sometimes found that if you wait for a few days, the same file will then process and give a solution. As an additional test I submitted the data to the CSRS-PPP site and it processed the data successfully and returned a position.
As mentioned by Jasonl there are some satellite data quality issues. This makes things more difficult for OPUS when you are working with minimum time period requirements AND you have a L2C-only receiver.
OPUS, like AUSPOS, is a GPS-only service and assumes all satellites are providing L2 data. An L2C-only receiver provides data for only about 2/3 of the constellation so it’s going to provide a weaker solution than a full L2 receiver. This makes a really good receiving environment seem like it’s partially obstructed. That said, an L2C-only receiver can work with OPUS, but going with the minimum time requirements isn’t the best idea. Longer time periods help as does mission planning to select times with more L2C satellites in view (with good geometry).
A service like the Canadian CSRS-PPP which also uses dual frequency Glonass might be the better choice if you need to limit the observation time. Of course, good old-fashion differential processing will get you the best accuracy in the shortest amount of time when there are CORS reasonably close like you have.
I couldn’t get OPUS to process several versions of your file in RINEX 2.11 to 3.04. Later I tried a 2.10 version with rapid static and it worked like Tatiana mentioned. You were obviously on a marker named WRIGHT. Differential processing with the nearest CORS provided a similar solution.
Thanks for the comprehensive reply @jbonde002 and also for replys from @jasonl@EBE111057@tatiana.andreeva . I totally forgot about the L2C only capability of this receiver and that totally explains my inability to achieve a static OPUS solution for a slightly over 2 hour solution. Those observations are just part of my precision testing of the M2 for my own peace of mind. For the past 9 months I have been utilizing a friends iGage iG3S GNSS receiver for testing OPUS Static occupations on 2+ hour occupations with zero issues…with the exception of sometimes waiting for the next day to process when the rapid ephemeris is available to achieve a successful solution. I was hoping that the M2 would achieve the same results for OPUS Static observations but it doesn’t look like that will be achievable since it is an L2C receiver and a complete oversight on my part…at least until the last 1/3 of the GPS constellation is modernized with L2C. I was hoping to utilize this for OPUS Projects which requires Static 2 hour + observations and not RS-OPUS observations. NGS is about 2 years out from integrating RS-OPUS solutions into OPUS Projects. Not the end of the world though as my primary purpose for purchasing this receiver was for GCP target acquisition for my drone orthomosaic projects and will be most appropriate for this. I have tested this on two of our NYHARN control monuments in this area and post processed those results with RTKLib against our NYCORS stations with promising results. I am going to start a new thread to share my setup and those results and provide the raw data for those wishing to try the data processing out and take the M2 “for a spin” without actually purchasing one. And at a total out of pocket expense for this Multi-Frequency GNSS setup at $700…well this receiver is still a doer! Thanks again for all of the reply’s.
Just want to point out that you still can use M2 for PPP but you’ll need to keep it a bit longer on a point: according to our tests, 4 hours in good conditions are usually fine.
