When collecting a static RINEX file with a Reach RS2 is there a way to adjust the collection interval? The file type that works best on NGS OPUS (at least for now) is a dual frequency, GPS only at 30 second (15 sec is ok) update rate, RINEX 2.11 file. I know that I can parse the RINEX file in PC software but I would rather not have to go through that step. A 1Hz, RINEX 2.11 file does work but files are unnecessarily large.
Not in Reachview, but you can with RTKlib afterwards.
Christian, I’ve played with rtklib and teqc to decimate the epoch interval and didn’t experience great results from OPUS, which is the static post processing system for the US.
It seemed to work fairly well with AusPos and I really like the results from AusPos better anyway.
What post processing service do you use and do you decimate the data before you compute the static solution?
Thanks
Emlid needs to put an time collection interval input in ReachView. Also, it should be collecting on even seconds. It seems that this is an imperative for the data to be processed on NGS OPUS correctly otherwise any processing on OPUS will be suspect and produce undesirable results.
2 Likes
Hey everyone,
Let me conclude this topic.
Reach receivers don’t collect the data on the even seconds which makes our measurements more precise. However, you can turn the time to the integer with RTKConv as described in this thread. Still, we haven’t come across any issues with processing in OPUS while using files that are not even on seconds.
You can check out Tatiana’s more detailed answer in this thread along with the most common cases for the unsatisfying results with OPUS:
Regarding the collection interval, we’ll consider adding it to the future versions of the ReachView app.
1 Like