Hey everyone,
Let me sum up what we know about this issue now.
We’ve been in touch with the Wingtra support. At the moment, it seems like the software requires the GPS L2P data to correctly process the logs. Other than that, I’m afraid we can’t be of much help with the third-party software algorithms.
Reach RS2 doesn’t record GPS L2P but tracks GPS L2C signal. Usually, the multi-frequency data Reach RS2 records is enough for the majority of the software. For example, I could post-process the logs with the RTKLib QT apps with an almost 96% fix solution.
As I have described previously, the general quality of the multi-frequency data from Reach RS2 is okay. I’ll post the screenshots below.
L1 recordings (stand for GPS/QZSS L1C/A, GLONASS L1OF, Galileo E1-B/C):
L2 recordings (stand for GPS L2C, GLONASS L2OF, BeiDou B1I):
L7 recordings (stand for Galileo E5b, BeiDou B2I) :
Also, the data quality from the drone is somewhat the same. I’ve made the comparison on the satellites in my previous post.
However, the drone records only GPS+GLONASS data. Enabling other satellite systems like Galileo and Beidou would help collect more data which usually results in better post-processing results.
Currently, to help overcome the issues, I can recommend the following as I’ve also described in this thread:
-
planning your survey so that there are enough satellites in view which are capable of transmitting L2-data. Certain predicting tools can be useful for that, like GNSS planning tool or GNSS radar
-
enabling as many satellite systems as possible because this helps collect more data for use in further calculations. Our default recommendation is all GNSS (GPS, GLONASS, Galileo, Beidou, and QZSS) enabled at 1 Hz for the base and 5 Hz for the rover.
Andreas, it’d be extremely interesting to see the results of your tests on comparison among the CORS/VRS, RS2 and another receiver. Hopefully, they will help us understand more about the reasons for the post-processing failures.