[time-nuts] Re: ublox gnss receiver data

Michael Wouters michaeljwouters at gmail.com
Sat Sep 17 23:15:07 UTC 2022


Hello Jorge

According to the ZEDF9-T interface description Appendix B, the two GPS
L2 signals are L2C(L) and L2C(M)
The corresponding RINEX 3.04 codes are C2L and C2S.
You would have to ask the RTKLib author why they are designated C2X in
the output.
[my recollection is that only one of them is present in the ublox
output anyway - C2L?]

As to why NRCAN ignores C2X and L2X you would have to ask the NRCAN PPP people.

I don't have a current copy of the r2cggtts source at hand but my
guess is that it simply does not parse for the C2X and L2X signal
names.
The recognized names are defined at the very top of the program in
V8.0 and the matched strings a bit further down.

Regarding your Q4, as you say, L3P has to be formed using P code and
phase observations at L1 and L2.
You can use C/A at L1 in conjunction with the bias file if you don't
have P code at L1 (as I remember).
I think there is some information in the r2cggtts docs about this.
As you say, if you don't have L2 P code measurements available, then
strictly speaking, you can't calculate L3P.
As a practical matter, receivers are only calibrated by the BIPM (and
Group1 laboratories) for GPS C1C, C1P and C2P delays.

I am not  sure what you mean by MSIO and MDIO being 'valid'.

Best regards
Michael


On Sun, Sep 18, 2022 at 7:23 AM Luiz Paulo Damaceno via time-nuts
<time-nuts at lists.febo.com> wrote:
>
> Hi all!
>
> I'm testing ublox's ZED-F9T GNSS receiver for time transfer applications
> and i've observed few things at data processing. This receiver is being
> feed with external 49.58 MHz coming from a synthesizer that is locked to
> Symmetricom's 5071A cesium frequency standard since we've removed its TCXO
> to make the time transfer tests.
>
> For the tests, I've processed .ubx raw data, then RINEX 3.04 data with
> RTKCONV present at RTKLib software. After that,  I was able to see the
> following RINEX observation types:
>
> G    4 C1C L1C C2X L2X                                      SYS / # / OBS
> TYPES
> R    4 C1C L1C C2C L2C                                      SYS / # / OBS
> TYPES
> E    4 C1X L1X C7X L7X                                      SYS / # / OBS
> TYPES
> C    4 C2I L2I C7I L7I                                      SYS / # / OBS
> TYPES
>
> The main question is: why L2 data for GPS is classified by "X" for code and
> phase?
> I've tried to process it with NRCAN's PPP software, but only had success
> when changed "C2X" and "L2X" to C2C and L2C.
>
> Now... Other things that I cannot explain and occurred:
>
> 1 - For the case that i've not changed X for C, i cannot process CGGTTS
> data for L2C frequency for GPS constellation. Only L1C clock data.
> 2 - For GLONASS and BeiDou constellation, without any changings in the
> observation types I can see L3P clock data, with coherent MDIO and MSIO
> values I guess...
> 3 - After changing GPS observation types for C2C and L2C, I have two files:
> L1C clock data and L2C clock data.
> 4 - After changing GPS observation types for C2P and L2C, i was able to
> have CGGTTS L3P data for GPS Constellation, but i guess that data is not
> valid because the receiver is not receiving "P" code in any frequency, even
> if use biasC1P1 file, the data shouldn't be real, right? So... Why is MDIO
> and MSIO also valid?
> 5 - I can see only GALILEO's E5b data, and L1 data seems to be not
> available.
>
> I've uploaded a few files to you to see some results in those files. I'm
> using the r2cggtts program and the input files are "rinex_nav_mix" and
> "rinex_obs".
>
> Link for the files: Google Drive
> <https://drive.google.com/drive/folders/115TAVbOOMkpxXbt4JLnR94nODbRFEgys>
>
> For the files, -rp2 means that i've changed original observation data
> (258_ubx.obs) from L2X to L2P type, also C2X to C2P type. For that, my
> question is: why GLONASS and BeiDou, even having an "P" code on the
> receiver, are able to generate L3P data? Rember: I've only changed X to P
> observation type for GPS constellation, everything else remains untouched.
>
> If you have links and other sources with works related to this I will
> appreciate it! Thanks.
>
> Best regards,
>
> Luiz
> _______________________________________________
> time-nuts mailing list -- time-nuts at lists.febo.com
> To unsubscribe send an email to time-nuts-leave at lists.febo.com




More information about the Time-nuts_lists.febo.com mailing list