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 <[email protected]
> 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 pulsesas shown, the effect of
> the unknown arbitrary phase is cancelled. The argument of the final output
> pulse can be shownto 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 <[email protected]>
> wrote:
>
>> Hi Marcus,
>>
>> Thank you for your inputs.
>>
>> On 13 March 2018 at 22:22, Müller, Marcus (CEL) <[email protected]> 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
>>> > [email protected]
>>> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
>>
>
_______________________________________________
Discuss-gnuradio mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
