UBX to rinex conversion issue is only observed when file are converted with RTKLib.
Issue is: when converting RS2 UBX file to rinex using RTKLib, some L2 carrier phase is dropped during the conversion process.
When using EZSurv rinex converter, there is no issue.
A RS2 UBX file and it’s equivalent rinex file, when converted to rinex using EZSurv are similar (L2 carrier phase remains available for all satellites when conversion is made with EZSurv).
That being said, it seems there is an issue with RTKLib converter (issue is only with L2 carrier phase).
PDF file attached shows 3 graphs
L2 carrier phase signal as recorded by RS2 in native UBX format
L2 carrier phase signal for same file, file converted to rinex with EZSurv
L2 carrier phase signal for same file, file converted to rinex with RTKLib (drops of L2 carrier phase are observed on almost all satellites in view)
I have also shared the file (RS2 UBX).
Hope the “Scan obs types” setting can solve that issue. Please advise if you have a solution to that issue.
The header of the file looks like this:
G 8 C1C L1C D1C S1C C2L L2L D2L S2L SYS / # / OBS TYPES
R 8 C1C L1C D1C S1C C2C L2C D2C S2C SYS / # / OBS TYPES
E 8 C1C L1C D1C S1C C7Q L7Q D7Q S7Q SYS / # / OBS TYPES
C 8 C2I L2I D2I S2I C7I L7I D7I S7I SYS / # / OBS TYPES
To my knowledge, the L2L is the carrier phase.
For RTKConv, this is what the manual says on the scan obs types:
For RINEX 3, you had better check
Scan Obs Typesʺ to obtain effective OBS TYPES in input files. In this case, the input files are scanned to
obtain available OBS TYPE list as the first conversion path and then RTKCONV outputs RINEX as the
second conversion path. If ʺScan Obs Typesʺ unchecked, the OBS TYPES in output RINEX files are
determined by the default OBS TYPES set depending on the input format and the ʺSignal Maskʺ
settings described below.
Can you upload a Rinex file converted with EZsurv ?
@tatiana.andreeva, just to make sure, as this is a long thread by now, with multiple issue: the one you are looking into is the break-up issue, not the seemingly missing L2-carrier phase?
We’re looking into the following issues discussed in this thread:
Missing epochs in raw data recorded by Reach RS2
Missing L2 for some satellites in RINEX files recorded by Reach and in RINEX files converted from UBX in RTKLib
May I ask you to clarify if these carriers are only missing in the RINEX files recorded by Reach and in the RINEX files converted from UBX in RTKConv? Do I understand correctly that when UBX is converted in EZSurv all L2-carriers are presented?
That is how I understand it. However, seeing that there is a L2L obs type in the file I myself have converted with RTKconv, it might be more complex?
This is speculation of the worst kind, but maybe it is a combination of wrong conversion settings in RTKconv, and lack of support for the L2L signals in EZsurv (maybe expecting L2X?)?
adds up to issue 1: missing L2 carrier phase in raw file (for some satellites)
The 2 previous issues are recording issue for RS2 (not related to post-processing software).
These 2 issues were observed using the UBX format.
Issue 2 is not a drop of L2 carrier data, but the L2 carrier phase is not recorded at all for some satellites. Christian mentioned that older satellites do not have L2C… Weirdly, the satellites with no L2 carrier phase are the ones with no L2C. L2 carrier phase should be present for all satellites in view,
last problem is related to RTKConv. When using RTKConv, some L2 carrier phase is dropped. This issue adds up to issue 1 and 2 above. In UBX file there is missing epochs and missing L2 carrier phase, when you convert the file with RTKConv, you lose even more L2 carrier phase.
Why can we say the issue adds up ?
when a file is converted to RINEX with RTKConv we can see
drop of epochs (same as the one we see in UBX file)
missing L2 carrier for some satellites (same as the one we see in UBX file)
if file was converted by RTKConv, we also see less L2 carrier (some drops L2 drops, partial drops, drops could however be important). This last issue can also be RTKConv not being set properly.
I do not use RTKConv, I have UBX files that I can compare with its rinex made by RTKConv.
What I can say is the UBX file has more L2 data than the rinex file converted by RTKConv.
If I convert UBX with EZSurv converter : UBX and RINEX have the same amount of data.
I am glad you are working on it, and hope a solution will be available soon.
Been looking to simply put all that you’ve posted together in the above writeup for Emlid to understand what the issue is but I’ve been on trek for some weeks now. Decided to make more tests upon my return and provide them with some substantial evidence but voila, someone has finally expressed the little experience I had with RS2s raw data before I went on trek. Thanks @Effigis_OnPOZ
We’ve conducted multiple tests and may confirm that Reach RS2 may lose some epochs in raw data. We’re now working on the solution, as I mentioned above.
2. Missing L2 carrier phase in raw data recorded by RS
I examined all the data you shared here and over email once again and can conclude the following:
According to the data you shared, there is no L2 recorded for the G14, G20, and G21 satellites in RS2 raw data.
It seems that the CORS station you mentioned can track L2P signal, that’s why it provides L2 observations. As for Reach RS2, it can track L2C only that is not transmitted by these satellites.
That’s why I assume there should be no issues with logging L2 carrier phase in raw UBX data.
Please let me know your thoughts regarding this case.
3. Converting UBX to RINEX in RTKLib issue
We expect to release the fix to this issue as soon as possible.
Yep, I saw, but it is in Rinex 2.10. I need one in Rinex 3.03.
Maybe EZsurv suffers from the same issue as NRCAN ?
Quote from NRCAN, after contacting them:
GPS observations in your Rinex3 file contain C2L signal. The (L) modulation of pseudo range C2 is not supported by our service. That is why the processing of GPS data could not be done.
It is planned to support this and other modulations once specific code biases become available.
Here is the list of currently supported signals:
Thank you for this reminder!
I check with engineering and they confirmed that we only use L2C, since RS2 does not provide L2P.
So if older satellites do not have L2C it is normal we cannot use these older satellites for L2 (given L2P is not recorded for these older satellites).
If a receiver can record the entire signal, EZSurv will use it all.
If a receiver records part of the signal, EZSurv will use what’s available.
“L2” and “D2” in the EZsurv converted obs-types does not seem comply with the Rinex std?