Galileo tracking carr_error_filt_hz = carrier_doppler_hz?

[ghost]

Within a dump mat file created by the tracking configuration for Tracking_1B.implementation=Galileo_E1_DLL_PLL_VEML_Tracking and Tracking_E6.implementation=Galileo_E6_DLL_PLL_Tracking:
is tracking carr_error_filt_hz = carrier_doppler_hz to be expected (y/n/depends)?

They appear to be two distinct arrays:
trk[2]['carr_error_filt_hz'] is trk[2]['carrier_doppler_hz']
False

gnss-sdr version 0.0.18.git-next-59d70eb33

[ghost]

This issue was closed prematurely and then reopened.

[fgallardo]

Hi,

I think one is the error signal from phase discriminator of the PLL and the other, the input to the NCO (i.e. the smoothed error signal that comes out of the filter)

Error signal from the phase discriminator of the PLL -> carr_error_hz
Output of the Loop filter -> carr_error_filt_hz

Both blocks are on the right part of this diagram:
https://raw.githubusercontent.com/gnss-sdr/gnss-sdr/next/src/algorithms/libs/volk_gnsssdr_module/volk_gnsssdr/docs/images/VOLK_GNSSSDR_Usage_Example.png

BTW, I guess you already checked, but you can find how these are computed in the LoC 538 and 540 below.

carr_error_hz

gnss-sdr/src/algorithms/tracking/gnuradio_blocks/glonass_l1_ca_dll_pll_tracking_cc.cc

Line 538 in 2c69d2f

carr_error_hz = pll_cloop_two_quadrant_atan(d_correlator_outs[1]) / TWO_PI; // prompt output

carr_error_filt_hz

gnss-sdr/src/algorithms/tracking/gnuradio_blocks/glonass_l1_ca_dll_pll_tracking_cc.cc

Line 540 in 2c69d2f

carr_error_filt_hz = d_carrier_loop_filter.get_carrier_nco(static_cast<float>(carr_error_hz));

Indeed you can see how it uses the carr_error_filt_hz signal to make the new estimate of the carrier frequency in LoC 542.

gnss-sdr/src/algorithms/tracking/gnuradio_blocks/glonass_l1_ca_dll_pll_tracking_cc.cc

Line 542 in 2c69d2f

d_carrier_frequency_hz += carr_error_filt_hz;

[ghost]

The mat file contains three quantities:
(1) carr_error_hz: Raw carrier error (unfiltered) at the PLL output, in Hz.
(2) carrier_error_filt_hz: Carrier error at the output of the PLL filter, in Hz.
(3) carrier_doppler_hz: Doppler shift, in Hz

I understand the relationship between (1) and (2) as referenced
above but not the relationship between (2) and (3). I plan to look into this further after January 10, 2024. I will update this comment with my findings.

[fgallardo]

Ups, so sorry, I think I did not read your question carefully.

If I understand your question, it is about the relationship between the output of the filter of the PLL loop and the new Doppler estimate, no?

Then, I would say, and I'm a hoping that I am getting your point right:

The value of the estimates of the Doppler at tracking stage starts with the estimate from the ACQ block, LoC 651, as it should be:

https://github.com/gnss-sdr/gnss-sdr/blob/main/src/algorithms/tracking/gnuradio_blocks/dll_pll_veml_tracking.cc#L651

And then. it gets updated in run_dll_pll() to the value of the filtered frequency error, in LoC 1107
https://github.com/gnss-sdr/gnss-sdr/blob/main/src/algorithms/tracking/gnuradio_blocks/dll_pll_veml_tracking.cc#L1107

At that moment in time, it should be the same. I assume.

Does it help somehow? Are you seeing any type of strange behaviour?

Thanks!
Fran

[ghost]

Given this advice, the quantities in question behave exactly as expected. However, I now raise the question as to how they can ever be different if  'd_carrier_doppler_hz = d_carr_error_filt_hz' (line # 1107) is executed when tracking begins (triggering  the start of a dump file). I will examine the code more carefully but you have provided a good starting point. Thanks for this. Rick

…

On 2024-01-02 00:41, Fran wrote: Ups, so sorry, I think I did not read your question carefully. If I understand your question, it is about the relationship between the output of the filter of the PLL loop and the new Doppler estimate, no? Then, I would say, and I'm a hoping that I am getting your point right: The value of the estimates of the Doppler at tracking stage starts with the estimate from the ACQ block, LoC 651, as it should be: https://github.com/gnss-sdr/gnss-sdr/blob/main/src/algorithms/tracking/gnuradio_blocks/dll_pll_veml_tracking.cc#L651 And then. it gets updated in run_dll_pll() to the value of the filtered frequency error, in LoC 1107 https://github.com/gnss-sdr/gnss-sdr/blob/main/src/algorithms/tracking/gnuradio_blocks/dll_pll_veml_tracking.cc#1107 At that moment in time, it should be the same. I assume. Does it help somehow? Are you seeing any type of strange behaviour? Thanks! Fran — Reply to this email directly, view it on GitHub <#734 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/A2BCHJ3XCDMC5JOYWRMPNW3YMPB4TAVCNFSM6AAAAAA5NGO2ZSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNZTG42DAMZVG4>. You are receiving this because you modified the open/close state.Message ID: ***@***.***>