1

enter image description hereI have done my receiver design with QPSK modulation. I am trying to communication between two systems at L band. My data rate is 1 Mbps. As my data rate is high I have allocated 64 bit for timing recovery.

Timing recovery has farrow interpolation filter followed by Gardner timing recovery, loop filter (2nd order) and interpolation control for the farrow interpolation filter. I am doing 2 samples/symbol analysis.

What I am assuming is the fractional value to the interpolation filter will stabilize once 64 bit allocated for timing recovery is over. But what I observe is the fractional value varies even after the 64 bit allocated is over because of which my data sometimes is wrong.

  1. can the fractional input to the interpolation filter vary?
  2. if yes why is the data sometime is wrong even if it is just direct board to board communication?
mark
  • 65
  • 3
  • Please give more details about the 64 bit sequence. Are these known values? Have you mapped them to appropriate constellation (BPSK/QPSK) ? Did you try eliminating carrier frequency/phase offset before attempting timing recovery? – jithin Mar 09 '20 at 07:23
  • it is 01010101...... for I and Q data. well i am trying DQPSK so i am not using carrier reecovery. – mark Mar 09 '20 at 08:51
  • @mark that's the worst possible preamble! – Marcus Müller Mar 09 '20 at 12:07
  • @MarcusMüller For consideration of timing recovery alone, I would say that is the best preamble. If needed for packet synchronization, I would agree it is a bad choice. – Dan Boschen Mar 09 '20 at 12:24
  • 1
    @DanBoschen I had to read mark's comment twice; I first thought that was a bitstream, in which case it'd have always been the same QPSK symbol (the one mapped to bits 01), and that would have indeed not have been a good sequence. But you're right, this ensures transitions, so it's great for timing recovery. – Marcus Müller Mar 09 '20 at 13:34
  • What is that a graph of? Please caption your figures! – TimWescott Mar 13 '20 at 23:13

1 Answers1

1

As far as the recovery time and results for the timing recovery, this is a loop implementation and you would need to review the complete loop for stability and gain parameters to balance loop bandwidth & convergence time, stability and noise performance.

Even with direct board to board communication you will have a static timing offset as the receiver needs to determine the optimum point in which to sample the recovered data in each symbol.

Step response testing of the timing error at your loop filter input and output can be insightful; the input to the loop filter will likely be quite noisy but you can filter your observation (as long as the filter bandwidth is much wider than your expected loop bandwidth this will be valid) to be able to see how it responds to a step change in time offset. Even better is if you have an accurate simulation model of your receiver so that you can observe the time offset more directly, and to observe what occurs as you change loop gain parameters.

Also through simulation and with testing on your hardware I would recommend creating an eye-diagram to better understand the core problems you may be having with data recovery. With this you can best observe the predicted sampling location for making a data decision versus the ideal.

Dan Boschen
  • 50,942
  • 2
  • 57
  • 135
  • Thanks a lot for a very quick response. So my timing recovery should recover in the 64 bits allocated. after that it should be stable for the rest of the frame? So if changing after 64 bits then i have to see the loop filter. is that right? step response testing means giving step signal to only the loop filter? what inference can i get – mark Mar 10 '20 at 03:55
  • My concern is if you haven’t designed it as a control loop then the loop bandwidth may not be properly set in which case it could be much too slow (not converging in time) or possibly unstable. There is no way to know this from what you wrote, but if you do what I suggested and post those results we may be able help further. – Dan Boschen Mar 10 '20 at 11:20
  • Hi Dan, I have attached image . I am giving step response to the loop filter and output is shown in the image. loop bandwidth is 0.002. – mark Mar 11 '20 at 06:28
  • 0.002 is extremely slow (I think)- what units is that in? – Dan Boschen Mar 12 '20 at 02:04
  • .002 of the symbol rate. i have also tried 0.02 also but still fractional value to the interpolation filter is not constant after 64 bit preamble is over. is the step response OK? – mark Mar 12 '20 at 04:43
  • 1
    I can’t make sense out of your step response but 1/500th is the symbol rate is much to slow—— it would take approximately 1000 symbols or more to converge! I think 1/20th to 1/50th should be adequate. – Dan Boschen Mar 12 '20 at 04:47
  • Hi Dan, How many symbols for 1/20th 40 symbols?? I have also observed that the convergence is faster but the error i described is still there? but my question is should the fractional value to the interpolation filter remain constant after 64 bit preamble? should i also tweak DDS gain and Phase detector gain for better performance? also uploaded mu( fractional value to the interpolation filter) image to get better picture – mark Mar 12 '20 at 11:59
  • 1
    It would be helpful if you could label your axis and would be helpful to label your x axis in units of symbols. I don’t understand why you would have such a big step after it seems to converge in the top plot. This will be much more detailed than we can really proceed with here (into the the weeds of the design details and we will end up putting a lot more comments here than the system likes)- but I suggest making a super long preamble just for testing of that settling time and also developing an actual system model of your loop to see the intact of all those gain parameters. – Dan Boschen Mar 12 '20 at 12:13
  • But with tighter loop bandwidth yes you would expect much less noise (more filtering) but a much slower response. – Dan Boschen Mar 12 '20 at 12:14
  • As for settling time you can use the rule of thumb that is directly applicable to a first order system and close enough for yours: the 10% to 90% rise/fall time in seconds for a step response will be 0.35/BW where BW is the loop bandwidth in Hz. You can convert that to your units to get a sense of settling time in terms of symbols – Dan Boschen Mar 12 '20 at 12:17
  • Hi Dan, anyway i will tell you that x axis is no of symbols (which is upsampled by 16) starts at 3000 and ends at 15000 so no of symbols is (12000/16=750). y axis is mu(10bit) so after 750 symbols there is a drop after reaching maximum. so even i have long preamble i get it once in a while – mark Mar 13 '20 at 05:12
  • I see so it is basically the symbol boundary I take it? So yes this is very slow and seems consistent with your 0.002 loop bandwidth. (certainly much too slow for a 64 bit timing acquisition pattern. – Dan Boschen Mar 13 '20 at 05:17
  • Hi Dan, I tried increasing loop bandwidth to 0.05. The mu varies a lot .I have also attached the file.The mu behaves differently based on the start value ( should i keep mu always zero at start of frame). So What do u suggest - Mark – mark Mar 13 '20 at 06:10
  • Hi Mark this is likely a lot more detailed than can be simply answered here. Email me at boschen@loglin.com – Dan Boschen Mar 13 '20 at 14:43
  • 0

    Dan Boschen, how exactly do you set the correct loop filter parameters? I have yet to see any PLL text actually tell how to predict the correct loop bandwidth beyond essentially saying "try it".

     – FourierFlux Mar 13 '20 at 21:46
  • @FourierFlux I did provide a more detailed answer here if this helps answer your question: https://dsp.stackexchange.com/questions/31170/loop-bandwidth-for-symbol-timing-recovery/31186#31186 – Dan Boschen Mar 14 '20 at 01:11
  • Thanks, but how do you measure SNR of the bandwidth? It's not clear what the signal you are measuring is. – FourierFlux Mar 14 '20 at 01:24