Re: [Discuss-gnuradio] Delay block controlled by input

[Marcus Müller]

Ok, you'll have to explain why you'd need throttle, as this is almost never the case, especially not when a) working in a simulation or b) working with "real" hardware, as that usually enforces a sampling rate.
If you know the physical sampling rate, counting samples *must* work, unless your sampling clock drifts significantly, or you have *really* fast moving satellites for which relativity is a concern at such low frequencies.

Anyway, as an advisor told me once, if you want something done mathematically right, do it mathematically right (that was on the subject on simulating delay for radar targets):
Transform your signal to frequency domain, multiply it with a complex sine of the frequency representing your time shift, and transform it back to time domain. This allows you (within numerical precision of the complex float and the length of your FFT) to have arbitrary accurate shifts, to dynamically update the frequency (depending on how you generate the complex sinusoid) and costs only moderately many ressources (OK, at roughly 10MS/s, this might still be relevant).

Greetings,
Marcus

On 07.10.2014 12:48, Carlos Alberto Ruiz Naranjo wrote:

I am having problems with the clock.
I need to track the real time of the signal. I have tried to get it with a
sample counter and a throttle (to maintain the rate), but it doesn't work.
The clock is faster or slower than the current signal time.

Any idea? ;)

2014-09-23 20:13 GMT+02:00 Tom Rondeau <address@hidden>:

On Tue, Sep 23, 2014 at 9:25 AM, Carlos Alberto Ruiz Naranjo <
address@hidden> wrote:

- SIGNAL: 10230000 samples/s

- CLOCK: Counter that increments +0.001 when passing 10230 samples.

- SATELLITE ORBIT: Calculate the satellite orbit and delay.


​

Ok. My problem with this is that we're trying to get away from using
streaming data ports for control like this. Changing the state of a block
should be left to stream tags or messages.

For your application, it might make sense if each data input to the block
matches to a very quickly-changing delay difference. In that case, though,
I would suggest that you keep an OOT module with your own implementation of
the delay block that does this for you.

Tom

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