Hi: I am new to this community so I will try and give a little background here. I do a lot of commercial drone services and specialize in electrical utility inspection and mapping with drones. I have experience with optical, thermal, photogrammetry and LiDAR and have used the Emlid products for almost two years now. Mostly I use the Emlid Reach as a static receiver for PPK corrections of imagery and or LiDAR but I also use it quite often for obtaining OPUS solutions. I almost always record observations for a minimum of 4 hours and have been very pleased with the accuracy of the Emlid Reach RS2+ that I am currently using. However, during my last job, I recorded a 4 hour observation on a 2M fixed height tripod in an open sky area with large rolling hills and a clear southern sky down near Klamath falls Oregon. When I got home, I used Emlid Studio to convert the UBX data to RINEX with 1S interval for LiDAR and 30S and rounding for OPUS. We were able to PPK process the LiDAR data successfully but OPUS was aborting with the following error:
“9011 OPUS could not process the data file that was submitted. The data was
9011 either very noisy or it was collected in kinematic mode. Or OPUS software
9011 has issue during this time, please reupload later.”
I tried using EMLID Studio to trim the file some and after trimming almost an hour off I finally got an OPUS solution but the accuracy was horrible! I have attached the UBX file, converted RINEX and also the OPUS solution here: EMLID - Google Drive
Can you please help me to understand what might be wrong and what I can do to fix it?
I can take a look. I am guessing that it’s because the start time is not at an even second interval. then again, you said with rounding, so perhaps you have already tried this! Standby.
It is a bit weird. I was able to do single base PPK off of MDMT and P674 bot at 100%fix. Opus would be preferable but I would go with the MDMT results due to the short baseline. The vertical is identical when comparing between stations and the horizontal deltas are very low. See attached. Not sure what’s going on with OPUS over there. WigginsTech_raw_20230322182216_MDMTBase.pos (884 Bytes) WigginsTech_raw_20230322182216_P674base.pos (884 Bytes)
Scratch that regarding the XY deltas. I checked again and the results are quite different. It’s about .9’ different coming off of P674 versus MDMT. There was some space weather today affecting GNSS. I wonder if there was on the 22nd. Really bizarre! The base station availability is really not helping either. P663 doesn’t appear to be logging but you may be able to pull that data directly from UNAVCO.
One last comment here lol. I really like to log at the full rate (1hz) just in case I need more data for other services. Have you tried using NRCAN’s PPP service? If something fails there, we know it was situational at your base.
Thanks for all the detailed replies! Yes I agree with your assessment and confirmed the same issues with multiple CORS base stations including the ones that you tested. I am left with no other conclusion than the possibility that it was space weather. I saw in the news that the northern lights were visible near Mt Shasta on the 23rd so maybe solar activity was ramping up when we were making our observations? In any case, I think we will have to go back down there to try again. Also, good point regarding the 1 second interval setting. We usually set up our settings for 1 second interval but somehow with the software updates and or my new phone, the setting got changed to 5 second. Good catch… I don’t have experience with NRCAN’s PPP service but I will look into it…
NRCAN is legit! I would highly recommend using both OPUS and NRCAN if you are in the US. I would do no less than 4hrs of static logging at ~15sec interval for NRCAN if you are shooting for 1-2cm absolute accuracy. If 2-5 is acceptable, I find that 2hrs is sufficient.
I’ve got this set as my home page in my browser. This gives me information on the current state of the sun, solar flares, high electron count, etc. This effects all space vehicles, even military space vehicles with hardened electronics.
Sometimes it’s indeed quite difficult to figure out why OPUS either rejects the file or outputs such a low accuracy. I don’t see any issues with your log’s quality, and I’ve also checked that it was recorded in a clear sky view.
I don’t think that you need to re-record your data and go back to the survey site. I’ve converted your UBX log into the RINEX one and cut it into 30 second intervals to make it light for NRCan. I submitted it to NRCan and got centimeter accuracy:
@kirill.pavlyuchuk Thanks for the NRCAN report! I looked at it and it is significantly higher accuracy than OPUS. I think that the fact that NRCAN utilizes multiple constellations probably give it an edge over OPUS which relies solely on GPS. We will certainly be interested in testing it further…
I got OPUS to process your file. Converting the UBX file to RINEX with the recommended -TADJ=0.1 option and decimating the file to 30 second epochs (just for a smaller file size) didn’t work.
So what if OPUS really thinks the data are noisy? It could be because some GPS sats have no L2 data and it expects all to have it. Since there are still about 6 sats without L2C there will be times when you are tracking multiple GPS sats with L1 data, but no L2 data. It’s possible this looks like noise to OPUS.
I used GFZRNX software with the -no_prn option to remove sats 13, 19, 20, and 21. These don’t have L2C data. OPUS then processed the file just fine.
NAD83(2011) and ellipsoid height values from OPUS and CSRS PPP where I converted the ITRF2020 position to NAD83 with NGS’s HTDP program. Note I added the antenna height offset and antenna model before submitting to CSRS (and got the ITRF solution).
42 04 33.56368 121 28 14.62390 1334.573 OPUS
42 04 33.56375 121 28 14.62421 1334.564 CSRS and HTDP
