Hey everyone,
Let me sum up the information we have.
Reach receivers are capable of tracking the L2C signal only. This information is available in the Reach RS2 specification.
I have been double-checking the data from successful and unsuccessful processing for a while now. As I have mentioned before, the difference between them is the number of visible satellites capable of transmitting the L2C signal. I’ve attached the comparison of the logs.
On the left, you can see the log that the software couldn’t process. It includes 7 satellites capable of broadcasting L2C data: G10, G12, G15, G17, G24, G25, G32. Please note that G10 and G32 are very difficult to use for calculation as they have the lowest SNR and are not recorded for the whole time of the survey.
On the right, you can see the log that was successfully processed. It includes 8 satellites that are capable of broadcasting L2C data: G05, G12, G15, G24, G29, G31, G32. It might be difficult to use the L2C data from G15 and G31 for calculations because of their low SNR and the time of visibility.
Usually, this data should be enough for processing. I have post-processed the drone’s data Arnaud shared with around 98% fixed solution using RTKLib QT apps. I’ll attach the screenshot below.
As we have stated already, Reach receivers don’t track the L2P signal and on the latest firmware versions there are no issues with any L2-data losses. I am afraid there’s not much we can do about software algorithms used by third-party software.
Also, as I understood from the conversation with the Applanix support, the software is capable of processing the logs containing the data from different satellite systems. As I can see, the drone’s data contains observations on the GPS and GLONASS satellites only so multi-frequency data on other systems can’t be used in the position calculations.
It’s important to have as many satellite systems enabled as possible. It provides more data for the position calculation: the more satellite systems are visible, the more data from different satellites is used in the computation. It leads to better post-processing results.
At the moment, I can suggest the following ways to provide the software with enough data as Arnaud has described above as well:
-
to carefully choose the time of the survey depending on when the maximum number of L2C-capable satellites is visible. You can use various tools for GNSS predictions, for example, this one or the GNSS view app that @Africawaterdoc suggested previously
-
to enable all possible constellation systems both on the rover and the base. Our default recommendation is all GNSS (GPS, GLONASS, GALILEO, QZSS, and BEIDOU) enabled at 5 Hz for the rover and at 1 Hz for the base
Hopefully, this will help in achieving successful post-processing results.