Re: [Discuss-gnuradio] Computationally Efficient Fractional Delay

[Richard Bell]

An easy way to get fractional delay is to use the polyphase timing recovery block. Set the loop bandwidth to 0, the number of filters to the fractional delay step size you want, i.e. 32 filters gives you a fractional delay step size of 1/32, the taps to your shaping filter over sampled by the filter amount*sps. Assuming you have experience with polyphase stuff already, this stuff might make sense to you. I use this setup to get easy fractional delay in my transceiver.

Any polyphase filter has the ability to get you what you want, so long as it gives you access to the proper hooks. Those hooks are available with the polyphase timing recovery block, that's why I use it.

Rich

On Fri, Jul 17, 2015 at 10:27 AM, Paul Garver <address@hidden> wrote:

Is there a computationally efficient fractional delay block in GR? My application is to measure group delay in a B200 for a TDoA system as well as precise ranging. I have a flow graph which simulates transmitting an RRC-shaped BPSK PN sequence and then cross-correlating with a matched filter. This works perfectly well but I’d like to modify it to test time delay estimation with fractional sample delays. There was a previous thread [1] on this topic but it was never resolved.  I have one of the proposed solutions working (see attached flow graph, delay_test) by doing a phase adjustment in the frequency domain. However, to do fractional delays requires very large FFTs.  Even at 32ksps, it is slow. I’m looking at generating this for 25 MSPS to get more precise timing. It also appears the rotator needs an integer delay value or the output is incorrect.

Is the fractional resampler a better tool for the job?  I’ve attached a sample flow graph, frac_delay_test.grc.  Adjusting the phase offset doesn’t seem to work in my experiments, although the example_timing.py script in gr-digital/examples seems to do precisely this.

I also thought about the new corr_est_cc block, but I think with the length of the filters this could be a problem since it constructions a large filter bank.

Thanks for the help.

[1] https://lists.gnu.org/archive/html/discuss-gnuradio/2014-11/msg00139.html

_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio