ublox gnss receiver data
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
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@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@lists.febo.com
To unsubscribe send an email to time-nuts-leave@lists.febo.com
Hello Jorge
Correcting myself here:
The CGGTTS V2E spec says
"The dual-frequency CGGTTS for the different constellations will be based
on the ionosphere-free combinations of the following signals:
GPS and GLONASS: C1 or P1 & C2 or P2
Galileo: E1 & E5a
BeiDou: B1I & B2I
QZSS: C1 & C2"
and then further says this should be called "L3P" for GPS
even when C1+C2 is used.
Regards
Michael
On Sun, Sep 18, 2022 at 7:23 AM Luiz Paulo Damaceno via time-nuts
time-nuts@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@lists.febo.com
To unsubscribe send an email to time-nuts-leave@lists.febo.com
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@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@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
<
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@lists.febo.com
To unsubscribe send an email to time-nuts-leave@lists.febo.com
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe send an email to time-nuts-leave@lists.febo.com
On Sun, Sep 18, 2022 at 7:22 AM Luiz Paulo Damaceno via time-nuts
time-nuts@lists.febo.com wrote:
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?
Tim Everett's version of rtkconv combines multiple code observations
on a single frequency under 'X', as a work around for processing
problems in rtklib. If you want to keep the original codes then you
need to pass the -MULTICODE option. Further details are available here
https://rtklibexplorer.wordpress.com/2021/05/16/using-u-blox-receiver-options-in-rtklib/
On 17.09.22 04:48, Luiz Paulo Damaceno via time-nuts wrote:
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
Hi Luiz,
could you elaborate on why and how you're bypassing the TCXO? I'm
planning to utilize the ZED-F9T for mobile time transfer and have
already heard that its TCXO is the biggest cause of short-term
instability when moving the receiver.
Thanks and best regards,
Carsten
Hi Carsten,
I'm bypassing the TCXO because I want to make mobile time transfers with a
low cost receiver too. So, for that, I've just removed the TCXO with hot
air (with care with other components) and synthesized its frequency
(49.58MHz) with an SRS SG384 synthesizer. Any synthesizer that can provide
this frequency and at least -5dBm of amplitude may work well. The
synthesizer is benign fed by a 5071 Cs clock.
Kind regards,
Luiz
Em seg., 19 de set. de 2022 às 16:06, Carsten Andrich via time-nuts <
time-nuts@lists.febo.com> escreveu:
On 17.09.22 04:48, Luiz Paulo Damaceno via time-nuts wrote:
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
Hi Luiz,
could you elaborate on why and how you're bypassing the TCXO? I'm
planning to utilize the ZED-F9T for mobile time transfer and have
already heard that its TCXO is the biggest cause of short-term
instability when moving the receiver.
Thanks and best regards,
Carsten
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe send an email to time-nuts-leave@lists.febo.com