Is there a solution that has been found for this issue? Emlid’s ReachView needs to better control the receiver to collect at different rates and on even seconds otherwise this receiver is not usable. RINEX collected data from a Reach RS2 processed in OPUS Static produces serious peal-to-peak errors and has a very low use of observations. Multiple processing of the same file in OPUS yields very poor results (>0.5 m) and is highly variable even when processing the same file. This should not be.
1 Like
Got this from Emlid awhile back. It’s message #43/51 of this thread.
It interpolates the GPS data to even seconds. Kind of like the Decimate program to trim down excess observations from RINEX files.
It has been called by several users, me included, that this is not normal data from other major GPS brands. If you set time interval to 1 second recording, then you get even second reading from topcon,sokkia, leica units.
Problem arises when you try to integrate the GPS data with other sensors that are recording in even seconds like bathymetry, drone, IMU data that are not linked real time.
@tatiana.andreeva , I really hope that you could fix this in hardware instead of doing it in software. I noticed that there is a slight difference between the 2 sets (even & decimal time stamps) when processed by OPUS.
Hey there,
I’d like to outline that we’ve tested RINEX from Reach with OPUS and haven’t noticed any effects produced by the time format which our Reach devices use to log the data. Still, there might be other factors that may worsen the solution. I’ll comment on each of them down below.
Log duration and amount of satellites used in computation
At the moment, OPUS handles only GPS satellites. The longer the session duration is, the better the results tend to be. Moreover, as Reach RS2 uses only L2C data, it’s better to plan the survey for the time when there are more L2C satellites in view.
Since Reach RS2 devices don’t track L2P data, they need more time to record more satisfactory data. That’s why we don’t recommend recording the log for the minimum required for processing time, as it just can be not enough for calculation.
According to my experience, it’s better to record the data for 4 hours, at least.
Data quality
This also can be a reason for OPUS to reject the solution. If the sky view is obstructed, or there is something in the environment that might create interference, the observation data might contain cycle slips or low SNR, which also might impact the solution. To provide more info on what may be wrong here, we need to examine the raw data files.
I’d also want to comment on the possibility of converting the data to integer seconds in RTKLIB I’ve shared earlier. It indeed allows getting the file with integer seconds. However, I recommend using raw data recorded on Reach directly with uneven time value for processing in OPUS. These observations are more precise than the ones you get after conversion to the file with even time. In this case, RTKLib interpolates the data, which may reduce accuracy.
May I ask you to share the files you used for processing with OPUS so that we can look into them? We can try to find out a reason for the issue you experience.
2 Likes
Tatiana,
I would be more than happy to share the files for you to look at. I am doing some testing adjusting the variables and processes that you (and Polina) have suggested. I do think there will be adjustments that Emlid can make to improve this process and my desire is to come away with everything working as best as it can. I will require that before I can recommend my user community using the Reach RS2.
I am impressed with the unit itself and as I have said before using it with Ntrip is a breeze. However, when I am using a Bluetooth NMEA connection to receiver and ESRI Collector, I do wish there was a way to use it with just my cell with another cell device to provide the internet connection. Just to let you know using ArcGIS Collector does not require a separate piece of software for mock locations like Lefebure. Nice!
Tatiana, since you closed the other thread we had going let me say on this one that even though you are getting files to work with OPUS it would be much better if in ReachView we could collect 15 or 30 sec epochs. There is no need to collect at 1 Hz for a static position and just uses memory for no reason. I am working through some of the suggestions that you all have given me so I will be in touch later today with files and more comments. So far, with all of the suggested changes I am still getting a large peak-to-peak error which will effect the overall RMS. Would you think adjusting the SNR filter in ReachView would improve things? Thank you for the quick responses.
Tatiana, I collected a RINEX 2.10 file collected at 1 Hz and GPS only. The results are using the ultra rapid ephemeris so I expect a little inaccuracies but not 3 - 7 cm as this file resulted in. The issue I think is revealed in the peak-to-peak error (see OPUS data sheet) which are over 7-10 cm for lat/long and over 38 cm in the height. This of course is not accuracy but only showing the positional variability in the data. I am testing this against a known surveyed point for accuracy comparisons. I can give you the data file if you can provide me with a way to upload it to you. This service does not allow files of that size.
raw_202007281429.obs OP1595957810527_ultrarapid.pdf (88.4 KB)
Hi Tim,
You can upload the raw log to any file transfer service and share a link here or PM it to me or Tatiana. We’ll look into them and come back with the feedback.
Tim, what are the rms values for the baselines to the CORS ? This is a good indicator of the actual accuracy of the position. This is shown in the “extended” version of the report. Large rms values in the baselines indicate bad observation areas (multi-path) at the station or even bad data at the CORS themselves.
I think all in all the OPUS results are adequate when I set ReachView to collect only GPS at 1 Hz but it would be nice to be able to collect this data with a 15 and 30 sec. update rate. I’ll need to wait a few days for Rapid and Precise ephemeris to have a clearer picture. The original files that I collected using all constellations was a bit disconcerting but thinking about this it can be controlled either during data collection or with RTKCont afterwards. I will continue to collect files and see how things go.
I don’t really use OPUS all that much. I usually PP all our project files. OPUS down through the years has become more strict in their data files submitted. OPUS likes clean data and is a very strict PP engine. I can usually PP data in the time it takes to submit and wait for a solution. It’s a good check though if you have a questionable position. You need to start looking at the rms values of the baselines in the OPUS extended report
The NGS is in the throes of changing their PP engine from Pages to another one so everything may change in the near future. I use to PP all of my data as well but having an OPUS solution in each project helps keep everyone honest when it comes to datums. I always look for an OPUS’d solution on at least one point in projects from other folks. Nothing like it. It changed the survey world when it came into being.
Hi Tim,
As Artem said, we’d love to analyze your data and share our thoughts on it. You can use the ways he suggested to upload them.
Thank you for the request! We’ll discuss the possibility of adding this with our team.
Any chance of specifying in the logging screen that we only want the RINEX to use GPS? I’d like to be able to use the file as a backup but have three constellations when actually using it for rtk. I know there is a was in rtklib but it would be just as easy if the creation of the rinex only saved gps.
Seth, you can do this in ReachView. Start ReachView, connect to the receiver, Go to RTK Settings and uncheck all of the constellations except GPS, Log a RINEX 2.10 or 2.11. You will collect a GPS only RINEX file.
I want to leave the three majors on and use the rinex as a backup option. Normally we would use NTRIP to get the known point but if something were to go wrong and we return from the flight, the rinex would aid us in georectifying the LiDAR data.
Hi Seth,
At the moment, we don’t have a possibility to log a separate RINEX log in GPS only with other constellations enabled during operation.
As you’ve mentioned, it is possible to trim out the GPS from raw data and RINEX in the RTKLib on the post-processing. It is only two clicks in the software and since it is a backup, it is not much of effort to do that.
Thank you for your feature request. It will be noted.
Artemis, do not believe that is correct. You can deselect the other constellations in the RTK setup and they will not be collected when static data collecting. If I am not correct please let me know. Thank you, Tim Smith
Hi Tim,
As far as I understand, Seth meant writing down the log containing only GPS data using the three constellations during RTK at the same time.
In the meantime, such possibility is not supported. If you deselect the constellations in RTK parameters tab, the RTK solution will be calculated only with the use of the ones you ticked. The raw data log will contain only the constellations which you selected too.
I misunderstanding… so to clarify, he is trying to collect a file for postprocessing with OPUS while at the same time doing RTK operations?. Would that be correct?