# Any way to compensate for fractional delay filter's weakness between taps?

A little background: I have an FPGA (running at 200MHz) that I am creating multipath events using buffers, all of that works. I take RF, mix down to IF, sample, make adjustments, out the DAC, and back up to RF. I use a windowed-sinc algorithm (like described here).

To do fractional delays, I compute the coefficients in a Java app and pass them to the FPGA. Each coefficient is a separate tap in the path on the FPGA, and then everything is summed up before outputting.

Like I mentioned, this all works, but I would like to make it work better. What I see is that for delays that work out to be closer to the middle of an FPGA clock "bin", I get the worst results. When the delay is closer to one of the edges of a bin I get better results.

As a test, I have 2462MHz for my RF, 2437MHz for my LO, and get an IF of 25MHz (just using pure tones out a signal generator). I have the tone going straight through on one tap, and I sum it with a fractional delay of itself. I looked at the output signal level on a spectrum analyzer for the first 15 completely out of phase points and plotted the results (in an ideal world they would cancel each other out). In this image the very first plot is actually where the second tap has a delay of 0 (completely in phase) to give a point of reference:

As you can see, the out of phase signals that fall near the beginning and end of a bin perform pretty well (and seem totally acceptable to me), the ones that fall near the center of a bin have the hardest time cancelling out. It might be acceptable (and as good as I can do), but I am curious if there is a way to perform better.

As an FYI, if I look at points within the first 2 periods of the RF signal (not just the 180 degree out of phase points) at 0.05ns increments, it looks very nice and smooth, the only thing that catches your eye is that there is a slight rise to the output, but that can be attributed to the fact that as I go along, I am getting closer to the center of a bin, and the results are getting worse.

• It's not clear to me what you're plotting there. What do you mean by the an "FPGA clock bin?" Do you mean you get the worst results when attempting to get a delay that is some multiple of 0.5 samples? What order of filter are you using, and how are you designing it? What type of arithmetic are you using in the FPGA? – Jason R Jul 18 '14 at 16:52
• @JasonR, The FPGA runs at 200MHz, so the discrete bins are 5ns apart. If I have an RF delay of say 1ns, the fractional delay filter will try to describe something that is in the first 20% of the bin, that it does a good job. If I need a delay of 2.5ns, it is trying to come up with a value that would fall in the middle of a bin, and that is the worst situation for the filter. Looking at the plot, the x-axis is showing the bin delay, so 1=5ns. I am good at 0 and 1, but .5 bins (~2.5ns) is where the filter is the worst. My filter works roughly the same for 3, 7, and 15 taps, no real change. – toozie21 Jul 18 '14 at 17:11
• @JasonR, I am basically using the Matlab code from the first link in the question in my Java app to come up with the coefficients. – toozie21 Jul 18 '14 at 17:12
• I am not following why you expect the signal summed with itself at a subsample delay to cancel out. Can you explain that? – John Jul 18 '14 at 17:26
• @John, Basically I am trying to prove out my process/algorithm. If I have a signal, and sum it with the same signal that is 180 degrees out of phase, the sum should be zero. That is what I am doing here, but in my case, my 200MHz FPGA can only handle discrete delays of 5ns. To get around that, I am doing this fractional delay filter approach. So if I want to have the main signal summed with that signal delayed by 0.2031ns, I should get a cancelled out signal. I am them putting 0.2031ns into my fractional delay filter to create the taps that emulate that delay. That help some? – toozie21 Jul 18 '14 at 17:31