Dear Raza,

the correlators are typically fixed to some offsets with respect to the clock period (in this case, the chip clock). They're automatically shifted when the NCO frequency is altered. Even if you make the correlators adjustable, they're still relative to the clock period, i.e., their offset is a function of time.

The offset from the DLL is used to control the NCO frequency, i.e., increase or decrease its frequency (and thereby period, as it's the inverse of the frequency).

Hope this helps. Best regards,

Johannes

Hello,

Thank you so much for your reply.

for example, I have a prompt local BOC PRN code, and I want to make early and late PRN codes to correlate them with the incoming satellite signal. then how can I make these early and late versions? Do I need to shift the prompt code manually? for example, by shifting prompt 1 chip to right is the late version, and by shifting prompt 1 chip to left is the early version?

Thank you

A usual GNSS software receiver implementation should already have early prompt and late sequence generation. If you have only prompt BOC PRN code you can produce other sequences by rotating them (shift number of samples equal to 1/2 of chip, from end of sequence to start of sequence and vice versa) to get your desired code sequence.

Similar to early and late you can create very early and very late codes...

Salam,

Thank you so much for your reply.

So I just need to make early and late by rotating the prompt BOC PRN code.

and for the next iteration, based on the output of the DLL discriminator, will the clock frequency get updated? (increased/decreased).

And the prompt code for the next iteration will be generated on the new clock frequency?

Thank you

Raza Javed

Wa'Alaikum As Salam,

Yes, the output of discriminator updates the frequency. As the dll output is noisy, you have to filter it before applying to the NCO. In order to remove steady state error there is an integrator block also included in the filter or in NCO.

Also the two tracking loop can very well function independently, i.e. PLL updating carrier frequency and DLL updating code frequency, PLL assisted DLL are more useful to update code frequency.

Thank you so much for your prompt response.

I really appreciate your help.

Thank you

Raza Javed

Hello,

I have a question relating to this, that once we filter out the output of DLL discriminator using 2nd order DLL filter, is there any specific function that NCO uses to generate a new clock frequency from that value we are getting from DLL filter?

I have read some functions in a book (Understanding GPS/GNSS by Kaplan & Hegarty) but these are a little bit confusing.

Thank you

Priyanka

The explanation of NCO in kaplan is confusing.

The NCO is capable of producing (theoretically) any frequency within its range, although its granularity may be compromised, i.e. to produce 1 MHz clock, it will produce 1 million clock signals in a second, but every clock signal may not be 1 microsecond apart, although this variation is kept to a minimum and it is a function of NCO clock.

For this NCO keeps track of very large fractional part of the time period, and counts it on every NCO clock it receives, and whenever the time period completes, it produces a clock signal.

To understand it more clearly, lets suppose that the system clock is 10MHz and NCO has to produce 1022934.5678Hz clock. The NCO will keep an accumulator to hold 'completed clock period' value, where on every clock it will add 0.10229345678 (which is fout/fclk) to the accumulator, and on every time the accumulator has a value > 1, it produces an output clock and truncate the accumulator value. So for the first second it produces 1022934 clocks but in the 2nd sec it will produce 1022935 clock signals and so on. and in 10000 seconds it will produce 10229345678 clock signals, thus effectively creating the required clock.

Thank you so much for your reply and that's very helpful information. But I just wanted to know that How code NCO uses the DLL filter output to generate a new clock frequency?

For Example: In the start of the tracking algorithm (without any DLL discriminator error), the code NCO clock frequency is 1.023 MHz (the code chip rate of Galileo E1 signal).

Now suppose we got some error from DLL discriminator due to mismatch in local and incoming PRN codes.

After filtering the DLL discriminator error, the value will go to code NCO.

Now, how the code NCO will use this value to change it's previous clock frequency (1.023 MHz) to some new clock frequency to change the prompt code, so that they can match with the incoming PRN code?

I mean, is there any mathematical relationship where this value will be used and we will get the new clock frequency?

Thank you

You may have seen the mathematical equation of DLL discriminators. The output of discriminator is the error in frequency of code NCO. If you have noticed they all are based on early minus late (eml) criteria.

So if the (local and received) codes are matching, prompt correlator produces a high value and early and late correlaors has equal values. In this case the DLL discriminators provide a zero error, and the NCO will not change its frequency. however if there is a mismatch in codes, the early and late correlator values will not be same and there difference is non-zero. This error value is filtered and added to the NCO previous frequency value.

If you follow it closely, you will find that the construction of complete delay lock loop (and also PLL) is same as any other control loop.

Thank you so much for your answer.

Can you also clarify my one more doubt regarding NCO. How is the phase accumulator and frequency control word(FCW) which is the input to the NCO works?

As in, what is frequency control word, is it the value that comes out of the loop filter? And if yes, then how the value converted into bits by phase accumulator which in turn gives the phase and frequency using the look-up table?

Regards,

Priyanka

The frequency control word (FCW) is implementation specific. I could answer more specifically about it if you could refer to text from where you have read it.

Also note that there are two NCOs. One for PLL and one for DLL. Their architecture is exactly same but they may differ slightly in their implementation, like the precision value, etc. So please also refer which NCO you are talking about.

Also phase accumulator could be the part of integrator block (refer to my answer 8 days prior to today).

Thank you so much for your reply.

The reference where I read it is https://en.wikipedia.org/wiki/Numerically_controlled_oscillator

and it was for code NCO.

I actually read few more papers and links and now I am thinking if this frequency control word (FCW) is only used if we are implementing carrier and code NCO on some hardware like FPGA. When using in software FCW is not in bits but it is used as it is from the loop filter. Please enlighten me if I am right here or not.

Regards,

Priyanka

if you are doing the post processing in matlab and following kai borre book, you will have its matlab code. Now you just need to relate text you referred to the matlab implementation and that is almost direct. But keep in mind that these texts are written in reference to the real-time receiver not the post processing receiver and that can make some difference.

FCW is the output of the filter, you can represent it in binary or decimal or float, so you may forget its type.

PCW is usally not used in tracking, but used in acquisition in real-time receiver, so you may also just leave it.

Phase accumulator is a integrator which converts the frequency into phase (phase is integral of frequency and frequency is differential of phase). This integral is very easy to implement in matlab but have a very fine details in real time receiver, and it is like phase = phase + freq

phase truncation is done as the phase is limited to 0 to 360 degrees (or 0 to 2 pi radians) but simple integration can give very large phase value, so we truncate it when it goes above 360 degree (or 2pi)

LUT is conversion of phase into output of generator. Again its very easy in matlab as we have here the cos and sine function implemented while in a real time receiver it is implemented through lookup table. So LUT is nothing but the sin and cos function implementation.

Salam,

I have one question. As we know that in Galileo E1 signal, we also have BOC along with PRN codes. So when we the code frequency of local PRN gets changed due to DLL discriminator error, do we also need to generate the BOC with this new code frequency? OR we use to old one (1.023MHz)?

thank you

Raza Javed

The change in code,carrier and BOC (if it is there) is due to the doppler effect or clock error. In both cases Local generator has to shift accordingly. But the change in doppler in code or carrier or BOC is respective to their frequencies; i.e.

f = f0{(c+vr)/(c+vs)}; where vr is the velocity of receiver and vs is the velocity of source. You may notice that the doppler factor will be same for every type of frequency, and the final required frequency will be a factor of the original frequency.

To understand it more clearly; let the {(c+vr)/(c+vs)} = 1.000001 (this is 1 ppm change) so the LO carrier frequency required will be 1,575,421,575.42 Hz that has 1,575.42 Hz doppler. But the code frequency required will be 1,023,001.023 Hz that has only 1.023 Hz doppler. And BOC frequencies has 1.023 and 6.138 Hz dopplers according to their fundamental frequencies.

With these different doppler frequencies, they will be coherent to each other. As with these dopplers the ratio between them will be constant.

So in short, you have to take care of doppler in every frequency.

Thank you so much for your reply.

I have one more doubt.

I have 4ms of data that I recorded using GNURadio and USRP front end. My sampling frequency is 5MHz, so in 4ms I collected 20000 samples that I used for acquisition.

Now as we know that tracking contains loops in it, so for every loop iteration we use the same 4ms of data OR we need to use next 4ms (next 20000 samples) and so on?

And how we decide, how many iterations of this loop we need to correctly wipe off carrier and PRN code?

Thank you

Raza Javed

To track, you do each iteration on the next set. Usually you don't need much iteration to correctly estimate the code and carrier frequencies etc. But you need a large amount of data, so that you will be able to decode navigation message that contains important information for the navigation processing. Like in order to get the complete ephemeris for a satellite, you need 30 sec of correct data for GPS, for which you do atleast 37 sec of data collection and tracking.

Usually, when we start getting data (navigation message) we assume that code and carrier loops are doing good :)

Also BTW, 5MHz (actually it is MSps) is too low for E1 processing (I think).

thank you so much for your reply.

Right Sir, now I will collect data again on higher sampling rate. Is it enough to use 16 MSps or higher?

And is 5 MSps sufficient for GPS L1 signal processing?

And I have one more doubt, as we know that in Acquisition we check the correlation peak to conclude that our acquisition is correct. So how do we know that our tracking algorithm is running fine? As you said that it doesn't take too many iterations to estimate code and carrier frequency, So how do we know that our tracking program is now correctly estimating the code and carrier frequencies?

I studied in some books that on successful tracking, we start getting data bits on prompt channel of tracking loop. Is it like so?

Thank you

Raza Javed

16 MSps simultaneous I/Q sampling will capture 16 MHz band (only I signal sampling will capture 8MHz Band) , so BOC(6,1) will be captured in I/Q or I sampling both. Higher sampling will give good results at position level.

5MSps for BPSK(1) is good enough.

Keep in mind; Acquisition requires a non-linear decision process, while tracking is a linear process. Also it has to be done at a certain rate. Although in post processing setups, we have the facility to break these rules, but usually the post processing concept follows the real-time tracking.

The code tracking is based on Early-minus-Late value. These values are zero when either properly tracking or not tracking at all. The carrier tracking is based on phase values. Phase value can only be kept on zero if the system is tracking. Rarely it happens that both of the tracking errors are zero (approximately) but you are actually not tracking; it is called the false tracking. So when the outputs of both discriminators are very small (nearly zero) and you start getting navigational data (i.e. I of prompt is changing sign every 20ms or multiple of it) you can safely say that you are correctly tracking.

Thank you for your reply.

Actually, I was thinking that the output of prompt I channel should be in the form of (1 and -1) which is format of data bits.

But as you said, it's just the sign that we should focus on.

It means if the sign of my I prompt channel is changing after every 20 ms, then my tracking is successful? the value at the I prompt channel doesn't really matter if my tracking is correct or not?

Thank you

Raza Javed

Yes, the output value is usually high and depends on several factors. It is the sign of Prompt in-phase arm that is converted to binary. +1 -> 1 and -1 -> 0.

Sign of I arm not necessarily changes at 20 ms but it can change in multiples of 20 ms depending on the navigation bit value.