On a job-site I deployed 3 RS2’s in a static configuration, however 1 of them simply won’t process in RTKpost (QT nor demo.5 b33c) or in EzSurv. Not even as a Single Solution.
It does process when submitted to NRCAN.
I can’t see anything obivous wrong. As can be seen below, there are some cycle-slips, but not in an amount that should cause no solution at all?!
SNR also seems fine.
Files (ubx and rinex+2 different base-files for repro) here:
Hi Christian,
Thanks for sharing the logs! I’ll look into them and get back to you.
Hi Christian,
As I can see, the time intervals of the base and rover logs don’t fully match. When I chose the Time Start and Time End of the base log (06:22 - 11:04) and used the base .nav file, the data was processed fine in our version of RTKLib. Please find the .pos files attached.
Yep, can’t shut off 3 bases at the sime time 
But this just results in shorter obs-time, not a complete failure to process.
I can see that RTKpost QT does process it, but why doesn’t the normal RTKPost or EzSurv?
When I do these post processing, I would have 20-30 different baselines (rover/base pairs) that are all network-adjusted together, so I really need the files from the RS2 to be processable by 3rd party applications.
In this instance, I had 2 other bases I could use, but imagine having this problem, if it was your only base, and it couldn’t be processed.
Hi Christian,
I couldn’t notice anything unusual in these RINEX logs. The satellite signal quality seems good enough for the Fix solution calculation. Also, the logs can be processed fine in our version of RTKLib, so I got no hints of what might go wrong.
I can hardly check why the process might fail in the 3rd-party post-processing software. If you processed the full logs before, I’d suggest checking whether using only the overlapping time period for the base and rover can help.
This topic was automatically closed 100 days after the last reply. New replies are no longer allowed.
