Fractional delay in fractional resampler block

Hello,

I have in my project a sample rate of 10.23 million samples per second
and
I need to delay the signal ±1ns. With GNURadio block delay I can delay
the
signal 97.75ns (1 / 10,230,000 -> + - one sample).

Could I use the fractional resampler block to enter a variable
fractional delay?
Has anyone implemented a fractional delay block?

Thank you.

well, yes, you could, but that sounds ugly:

  1. a sample rate of 1e9Hz implies --for complex float-- a memory
    consumption of 1e9*8B~=8GB per second…
  2. unwieldy fractional resampling, because 10.23e6 and 1e9 don’t have a
    very large common divisor; you’ll be interpolating by a factor of 100000
    just to decimate by 1023… That is effectively just very very many
    samples in-between.
  3. you’re sampling at 10.23MS/s, but you want to do something with a
    temporal resolution of 10 times that rate; that’s a phase shift, for
    sure, but I’m afraid that it sounds like you’re trying to harm Nyquist
    in some way or another.

When were talking on how to simulate delay introduced by radar range in
GNU Radio, a wise[1] elder[2] told me to do time shifting in frequency
domain:

The idea is that a time shift corresponds to frequency shift in
frequency domain, so you can, within the spectral precision defined by
the length of your DFT, have arbitrary shifts by doing [time
signal]->[DFT]->[multiply with complex sine]->[IDFT] . Note that, due to
the circular nature of the DFT, this will distort the first samples of
the output.

Greetings,
Marcus

[1] one might consider him wise
[2] not really an elder


Discuss-gnuradio mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Hi Carlos,
yes, your formular looks correct, scalar multiplication aside.

Regarding your problem:
It’s not a problem, it’s a feature :slight_smile:
you’re using window functions in your FFT, that’s what’s changing your
signal.
The FFT is but an implementation of the DFT (discrete fourier
transform), which is, considering the input as element of a
n_fft-dimensional vector space, is but a base change, and thus has an
inverse – the IDFT (incarnated by the IFFT).

what you see is something like the norm of the square of the window
function; use “rectangular” to avoid this.

Greetings,
Marcus


Discuss-gnuradio mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


Discuss-gnuradio mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


Discuss-gnuradio mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Hello Carlos,

I don’t really think that what you built really reflects what you’re
trying to achieve: I thought you needed a really small delay in time
domain, and a sampling rate conversion from 10MHz to 10.23MHz.

Why are you doing a delay in frequency domain? That will simply be a
frequency shift in time domain, which you could easily realize (and with
much smaller computational error) by multiplying with a complex sine in
time domain.

I don’t really understand what you mean with “small variable delay in
the receiver”: Do you mean your system is not somehow synchronized?

Best regards,
Marcus Müller

Hi Carlos,
I just realized that maybe the core problem here is that I don’t really
understand what you’re trying to do –
could you explain what this system will be used for, and why you need
that particular sampling rate etc?

Best regards,
Marcus