[time-nuts] Re: ublox gnss receiver data

[Luiz Paulo Damaceno]

Hi Michael,

Concerning the rtklib designations I will contact rtklib developer. And
also NRCAN people.

You're wright, only C2L and L2C is available. Actually, I don't know any
uBlox receiver that handles L2P or even L1P code.

About r2cggtts. When renaming C2X and L2X to C2C and L2C respectively it
works well: generates an C1 and C2 raw clock data. But no MSIO (measured
ionosphere delay) data.

About L1P. Yes. I do that with Polarx3tr receiver. It has only L1C /L2C /
L2P. With bias c1p1 r2cggtts generates L3P data correctly.

About MDIO and MSIO being valid, I mean when we have L3P for GPS, the MDIO
and MSIO values are the same. But when C/A only data, I cannot generate
MSIO data. Only MDIO, that I guess it comes from Klobuchar's model.

The strange fact is that GLONASS and BeiDou is generating L3P data having
only CA code. Or in that systems we haven't this differentiation of the
codes?

I also trying to discover why only e1b data is being generated at r2cggtts
for Galileo, concerning that I also have E1 signal available.

Kind regards,

Luiz

Em sáb., 17 de set. de 2022 20:19, Michael Wouters via time-nuts <
time-nuts at lists.febo.com> escreveu:

> 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
> _______________________________________________
> time-nuts mailing list -- time-nuts at lists.febo.com
> To unsubscribe send an email to time-nuts-leave at lists.febo.com
>