discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] Signal start (timing acquisition) in DVB-T2


From: Achilleas Anastasopoulos
Subject: Re: [Discuss-gnuradio] Signal start (timing acquisition) in DVB-T2
Date: Thu, 22 Mar 2018 14:54:21 -0400

Hi Anshul,

regarding frequency correction (although I do not know the details of DVB) my understanding is that there is a repeated training sequence, let's say it is repeated N times.
If this is true, then the output of the MF (matched to one of the training chunk) will give N peaks, each of which will be something like
r_k = exp(j 2 pi df T k) + noise
where T is the duration of each training chunk.
If you post-process this signal as
y_k = r_k r_{k-1}^*  ~=   exp(j 2 pi df T) + noise   
which can be used for frequency estimation of df.

Achilleas




On Thu, Mar 22, 2018 at 12:49 PM, Anshul Thakur <address@hidden> wrote:
Hi Marcus,

So I did an implementation using a similar logic as in gr-cdma (courtesy Achilleas) after smoothening the input. Once the correlation rose above a threshold, I essentially started taking 1K point FFTs and correlated the power distribution with the Carrier Distribution Sequence as specified in the standard [1].  By doing this, I am able to find the peak position and likewise, a more refined window of where the P1 symbol would be starting. 

Now, for the frequency offset correction part, I am confused as to what it should be. The standard says:

The argument of the 'correlator' outputs contains information about the fine frequency offset, but also the unknown

arbitrary phase (with respect to the transmitter) of the down-shifter oscillator. By multiplying the two correlator pulses
as shown, the effect of the unknown arbitrary phase is cancelled. The argument of the final output pulse can be shown
to be proportional to the 'fine' component of the frequency offset.

Mathematically, if each of my correlations in either branches had a constant frequency offset of 'theta', then multiplying the two would have given me (2*theta) while the random phase fluctuations are expected to have cancelled. In that case, should I be dividing the argument by 2 to get to my frequency offset?

Also, should I take the argument of the index at which peak was detected as my frequency-offset, or should it be an average of something? Actually, I've tried using the phase value at the peak directly, but it does not lead to a meaningful P1 pre-signaling signal after DBPSK demodulation [2].

[1] DVBT2 Implementation Guidelines, Section 10.2.2.6 P1 Validation
[2] DVBT2 Standard ETSI EN 302 755 V1.4.1, Section 9.8.2.2

Warm regards,
Anshul Thakur

On 15 March 2018 at 22:29, Anshul Thakur <address@hidden> wrote:
Hi Marcus,

Thank you for your inputs.

On 13 March 2018 at 22:22, Müller, Marcus (CEL) <address@hidden> wrote:
Hi Anshul,

do you normalize your correlation by the received signal power in that
same window?

No. I wasn't normalizing the correlations. I'm using the image attached as reference design. 
I guess I got a little excited to see the peaks in Matlab that I did not even consider the energy of the signal as a possible normalization denominator.  :D



 
How's your frequency correction doing? If you don't have frequency
detection at that point, your signal might get decorrelated.

The preamble detection step itself is supposed to find a coarse frequency-offset which must be
further refined by correlation with the Carrier-Distribution-Sequence(cds) in the next step. So, no, currently, there is no frequency correction as per se.
 

You can solve both by employing a fixed delay correlation of your
receive signal; IIRC, P1 is roughly split into three parts: A middle
part that repeats in the front and at the end of the symbol. Let's say
that repeated part in the front is N samples long. Take these N,
correlate with the N that follow, divide by the power of these samples.

Correct. I was not dividing by the power. I did that and the slopes have become more smooth except occasional blips over a single sample.
I am correcting for these occasional blips by comparing my current value with the running average a small previous window (5 samples currently), the reasoning being - 
If the signal is rising fairly consistently, the current value will be greater than the average of what came in the short term past. 
By doing so, I am able to get a coarse window of prospective sample ranges where the signal might be starting.

I will now try to filter them further by correlating with the CDS and revert back if I run into more trouble. Many thanks!
 

You'll not only get a value that should be independent from absolute
receive signal strength (as long as fading is not faster than ¼ of the
P1 length), and as a bonus, the correlation coefficient's phase allows
for a relatively robust frequency offset estimate. You can use that
estimate to correct your receive signal and get a better detection
result :) 
Best regards,
Marcus

On Tue, 2018-03-13 at 20:38 +0530, Anshul Thakur wrote:
> Hello all,
>
> I am trying to implement a DVB-T2 receiver's P1 symbol detection block using C++ in GNURadio. From a non-real time code in MATLAB, I can see that the correlation peaks during the P1 symbols are almost 50 to 100 times larger than the rest of the time. This rise is not steep in consecutive samples.
>
> However, I am having trouble in implementing this as a kind of stream-algorithm that operates on blocks of data (like a real receiver would) rather than the entire thing (in GNU Radio, that is). The problem is thus:
>
> I want to detect when the signal correlation reaches its peak-plateau region. While the overall trend in correlations does rise, the consecutive values may fluctuate in both positive and negative directions due to noise/fading effects. I've tried a few rudimentary approaches:
>
> 1. Average the correlations over some period and see if the current average is greater than some sample at an offset in the history by a threshold value to term it as rising. While it can give some degree of rise, it is not very good at peak detection.
>
> 2. Keep a history of consecutive slopes in my block and use a small average. The fluctuations should die down and give some value near to 0. This doesn't seem to happen. The results are not satisfactory. Also, the consecutive slopes are also not that spectacular to contrast with the average case.
>
> Possibly, I need to use some smoothening and differentiator filter. Can you point to a sample implementation of a similar kind? Or give some more ideas I could experiment with?
>
>
> Warm regards,
> Anshul
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio




reply via email to

[Prev in Thread] Current Thread [Next in Thread]