Hi All,
I have a signal that I've collected with a USRP over the air. This is a bursty QSPK signal, and I am trying to perform frequency, phase, and timing recovery on it.
I am able to detect the CFO correct for that, and for burst phase recovery, I use the following formula:
phEst = 1/4 * angle( sum( x_freqCorrected ).^4 );
phCorr = exp(-j*phEst);
x_phaseRecovered = phCorr * x_freqCorrected;
I'm fairly confident that frequency and phase recovery is working decently because I can see the QPSK constellation.
Finally, I would like to do timing recovery. I saw several algorithms online, and am wondering if my approach would work? My signal at its current state (stored in the x_phaseRecovered vector) is a 2 samples/per/symbol QPSK signal. I was thinking about interpolating the signal up to get more samples per symbol. Lets say I interpolate by a factor of 4, so I now have 8 samples per symbol. Now, I find the lag that has the maximum power as follows:
xi --> the interpolated phase recovered signal.
samps_per_sym = 8;
bestTau = 1;
maxSigPow = -9999;
for tau=[1:samps_per_sym]
sig = xi(tau:samps_per_sym:end);
sigPow = sum(sig.^2);
if(sigPow > maxSigPow)
bestTau = tau;
maxSigPow = sigPow;
end
end
Finally, I'd like to do interpolation around the bestTau point. Lets assume for the moment that bestTau is not at the edges ... i.e. bestTau = [2 ... 7]
Now, I'd like to use the peak interpolation formula as mentioned in this link: http://www.dsprelated.com/dspbooks/sasp/Quadratic_Interpolation_Spectral_Peaks.html
Is this a valid approach for timing recovery? I attempted to use the interpolation equations, but the output constellation diagram of the timing recovery looked bad. I suspect it is because the equations are designed for real numbers, and I have a complex signal?
Thanks in advance!
burst timing recovery for QPSK signal
Started by ●June 18, 2014
Reply by ●June 18, 20142014-06-18
1. Most of the times, CFO is corrected after the timing recovery as it is fairly independent of moderate CFOs. Otherwise CFO can be jointly estimated with the timing. How did you correct the CFO without any timing? 2. For timing recovery, power maximization method is not necessarily translates into the best timing phase. Most of the times, it does but for many types of channels, it does not. Look at Gardner's 2 famous papers on timing recovery. 3. Are you writing the signal received through USRP in a file for offline processing? If yes, how did you manage the file processing at the USRP source and USRP sink? _____________________________ Posted through www.DSPRelated.com
Reply by ●June 19, 20142014-06-19
On Wed, 18 Jun 2014 14:36:04 -0700 (PDT), dsp student <Kiran.Karra@gmail.com> wrote:>Hi All, >I have a signal that I've collected with a USRP over the air. This is a bu= >rsty QSPK signal, and I am trying to perform frequency, phase, and timing r= >ecovery on it. > >I am able to detect the CFO correct for that, and for burst phase recovery,= > I use the following formula: > >phEst =3D 1/4 * angle( sum( x_freqCorrected ).^4 ); >phCorr =3D exp(-j*phEst); >x_phaseRecovered =3D phCorr * x_freqCorrected; > >I'm fairly confident that frequency and phase recovery is working decently = >because I can see the QPSK constellation.That's a good sign.>Finally, I would like to do timing recovery. I saw several algorithms onli= >ne, and am wondering if my approach would work? My signal at its current s= >tate (stored in the x_phaseRecovered vector) is a 2 samples/per/symbol QPSK= > signal. I was thinking about interpolating the signal up to get more samp= >les per symbol. Lets say I interpolate by a factor of 4, so I now have 8 s= >amples per symbol. Now, I find the lag that has the maximum power as follo= >ws: > >xi --> the interpolated phase recovered signal. >samps_per_sym =3D 8; >bestTau =3D 1; >maxSigPow =3D -9999; >for tau=3D[1:samps_per_sym] > sig =3D xi(tau:samps_per_sym:end); > sigPow =3D sum(sig.^2); > =20 > if(sigPow > maxSigPow) > bestTau =3D tau; > maxSigPow =3D sigPow; > end >end > >Finally, I'd like to do interpolation around the bestTau point. Lets assum= >e for the moment that bestTau is not at the edges ... i.e. bestTau =3D [2 .= >.. 7] > >Now, I'd like to use the peak interpolation formula as mentioned in this li= >nk: http://www.dsprelated.com/dspbooks/sasp/Quadratic_Interpolation_Spectra= >l_Peaks.html >Is this a valid approach for timing recovery? I attempted to use the interp= >olation equations, but the output constellation diagram of the timing recov= >ery looked bad. I suspect it is because the equations are designed for rea= >l numbers, and I have a complex signal?As has been mentioned, usually timing is recovered first, as that makes recovery of frequency and phase much simpler. Two samples per symbol is not much to work with, but can be made to work. Look at traditional timing recovery systems (loops with a Timing Error Detector), and use the loop to steer an interpolating filter (e.g., a Farrow Filter, LaGrange interpolator, or polyphase filter.) If you're clever, you may even be able to use the polyphase filter for both interpolation and pulse shaping, if that hasn't already been done by the time you get the signal. Filtering or interpolation equations made for real signals can be applied to complex signals by using it on both the I and Q channels identically. Eric Jacobsen Anchor Hill Communications http://www.anchorhill.com
Reply by ●June 19, 20142014-06-19
Hi All, Thank you again for your responses. 1.) I did frequency recovery as follows: I know the signal is QPSK. I took the received burst, took the FFT of the signal^4 and saw a peak at my CFO. The frequencies are scaled because I took the signal^4, but I then scale it back. I then simply multiplied the received vector by a complex exponential of the negative of the detected CFO. I'm fairly confident this is working because the constellation plot of the received burst before I did the correction was a circle, and I can see QPSK blob's after doing this processing. 2.) With regards to the USRP, yes I dumped some data to a file. In my GRC flowgraph, I have a "USRP Source" block connected to a "File Sink" block. If you have more questions on this let me know and I can try to clarify. 3.) Thanks for your suggestion of applying interpolation equations for real signals to complex signals. I'll look at Gardner's timing algorithm. I am somewhat familiar with it, but I didn't know if it would be good for bursty signals versus continuous signals? I was under the general understanding that loop based methods were good for continuous signals but they take a bit of time to "settle", and in a bursty environment you need to have all your synchronization done from the 1st sample? This could definitely be incorrect, if you guys or anybody has any comments on this I'd definitely appreciate it.
Reply by ●June 19, 20142014-06-19
On Thu, 19 Jun 2014 05:53:10 -0700 (PDT), dsp student <Kiran.Karra@gmail.com> wrote:>Hi All, >Thank you again for your responses. > >1.) I did frequency recovery as follows: I know the signal is QPSK. I took= > the received burst, took the FFT of the signal^4 and saw a peak at my CFO.= > The frequencies are scaled because I took the signal^4, but I then scale = >it back. I then simply multiplied the received vector by a complex exponen= >tial of the negative of the detected CFO. I'm fairly confident this is wor= >king because the constellation plot of the received burst before I did the = >correction was a circle, and I can see QPSK blob's after doing this process= >ing.That's a good indication that it's working, but this technique is not efficient, especially at low SNR. It works, and it sounds like you've demonstrated that you have it working, but there are better ways.>2.) With regards to the USRP, yes I dumped some data to a file. In my GRC = >flowgraph, I have a "USRP Source" block connected to a "File Sink" block. = >If you have more questions on this let me know and I can try to clarify. > >3.) Thanks for your suggestion of applying interpolation equations for real= > signals to complex signals. > >I'll look at Gardner's timing algorithm. I am somewhat familiar with it, b= >ut I didn't know if it would be good for bursty signals versus continuous s= >ignals? I was under the general understanding that loop based methods were= > good for continuous signals but they take a bit of time to "settle", and i= >n a bursty environment you need to have all your synchronization done from = >the 1st sample? This could definitely be incorrect, if you guys or anybody= > has any comments on this I'd definitely appreciate it.It depends on how long the burst is, sort of. If the burst is long enough that a good initial timing estimation doesn't hold for the length of the burst, then you need to track the timing with a loop or some other method. A loop is often used since it's fairly simple, works well, and can be started in a locked condition from a good initial estimate. Is there a preamble on the burst? There is typicall a preamble at the beginning of the burst specifically to facilitate initial timing (and phase and frequency) estimation. Alternatively, since you have all of the samples collected already, you can also do iterative techniques to home in on the proper timing, but that's not as efficient as more typical methods. Eric Jacobsen Anchor Hill Communications http://www.anchorhill.com
Reply by ●June 23, 20142014-06-23
Hi Eric, Thanks for the suggestions again. Yes, there is a preamble so that is a good point that the preamble time can be used to acquire lock. I am thinking that the preamble itself can also be used to undo the channel for each burst using some sort of adaptive filter.
Reply by ●June 23, 20142014-06-23
On Mon, 23 Jun 2014 09:02:04 -0700 (PDT), dsp student <Kiran.Karra@gmail.com> wrote:>Hi Eric, >Thanks for the suggestions again. Yes, there is a preamble so that is a goo= >d point that the preamble time can be used to acquire lock. I am thinking = >that the preamble itself can also be used to undo the channel for each burs= >t using some sort of adaptive filter. >Yes, preambles are often used to facilitate channel estimation, but the preamble needs to have a white-ish spectrum (i.e., be reasonably flat within the band) in order to provide good channel estimation. Sometimes preambles that are optimized for synchronization do not make good channel estimation preambles. Eric Jacobsen Anchor Hill Communications http://www.anchorhill.com
Reply by ●June 24, 20142014-06-24
The problem of using carrier recovery before timing - as what you are doing - is the following. The 4th power and FFT algorithm works only well after a certain SNR. Below that, there is a threshold problem (false peaks). Now when you don't recover the timing first, you might be lucky to sample the incoming waveform near the pulse peak but when you are not near the peak (which will be the case in most of your experimental runs), then even in an ideal channel, there will be large ISI from neighbouring symbols which will reduce the SNR. You will soon see the false locks. So, do the timing first. Preamble can be used for initial timing recovery. See Oerder and Meyr's paper for such an algorithm but you will require 4 samples per symbol. See its citations on Google Scholar and you will find some algorithms for 2 samples per symbol. _____________________________ Posted through www.DSPRelated.com
Reply by ●June 25, 20142014-06-25
Also, I have a particular question or two about file handling. Since I don't want to divert your original thread, can you email me at my username above @yahoo.com and I will ask you. Thanks. _____________________________ Posted through www.DSPRelated.com
Reply by ●June 30, 20142014-06-30
