A version of RTKLIB optimized for low cost GNSS receivers, especially u-blox receivers. It is based on RTKLIB 2.4.3 and is kept reasonably closely synced to that branch. This software is provided “AS IS” without any warranties of any kind so please be careful, especially if using it in any kind of real-time application.
There are multiple functions for resolving conflicting frequency indices. This proposes to add a common function sigindex() and uses it for RINEX and RTCM, and for a start the Unicore raw decoder (which seems a wip anyway). I have a wip change for septentrio too which works fine, but that needs other work. So now the same frequency index allocation can occur for data coming from a raw stream, as for a RTCM stream, and as for data converted to RINEX and reload - where this was not always the case before which was just a frustration. Also now these all use the same code priority options.
Some of the code paths were making static decisions or decisions applied to a larger set of observations, so not dynamic for each satellite observation. This proposal applies the resolution to each observation, so it can pack in an available signal for a frequency slot where that might not have occurred before. Now a signal for one satellite is not bumped into the extra-obs region just because another satellite has a higher priority signal for that frequency.
Limited testing on Unicore, as the only dataset found had just one epoch, but it did appear to improve the result with more signals reported. Could use some help with testing there, some more data sets. Did fix the std dev. too there; the prior patch was storing them to the wrong destination. Btw the Unicore converter found does not even appear to decode the Unicore format, just the novatel messages, and the signal mapping is still questionable? Do they even have a RINEX converter for their own format? If it were possible could an RTCM3 MSM7 stream be logged at the same time as a Unicore raw stream, so we can check for consistency.
There are multiple functions for resolving conflicting frequency indices. This proposes to add a common function sigindex() and uses it for RINEX and RTCM, and for a start the Unicore raw decoder (which seems a wip anyway). I have a wip change for septentrio too which works fine, but that needs other work. So now the same frequency index allocation can occur for data coming from a raw stream, as for a RTCM stream, and as for data converted to RINEX and reload - where this was not always the case before which was just a frustration. Also now these all use the same code priority options.
Some of the code paths were making static decisions or decisions applied to a larger set of observations, so not dynamic for each satellite observation. This proposal applies the resolution to each observation, so it can pack in an available signal for a frequency slot where that might not have occurred before. Now a signal for one satellite is not bumped into the extra-obs region just because another satellite has a higher priority signal for that frequency.
Limited testing on Unicore, as the only dataset found had just one epoch, but it did appear to improve the result with more signals reported. Could use some help with testing there, some more data sets. Did fix the std dev. too there; the prior patch was storing them to the wrong destination. Btw the Unicore converter found does not even appear to decode the Unicore format, just the novatel messages, and the signal mapping is still questionable? Do they even have a RINEX converter for their own format? If it were possible could an RTCM3 MSM7 stream be logged at the same time as a Unicore raw stream, so we can check for consistency.