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 <garv...@gatech.edu> 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
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Reply via email to