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.