# Delay block controlled by input

Hello,

I have modified GNURadio delay block. It is a controlled delay from an
input at
runtime.

I would like to know your opinion; if the block is well designed.

On Tue, Sep 23, 2014 at 2:38 AM, Carlos Alberto Ruiz Naranjo <
[email protected]> wrote:

delay_impl.h - Pastebin.com

What’s the use case for this? Specifically, how often do you need to
update
the delay and what’s the control mechanism? I ask because it feels like
a
message port would be more appropriate here than a streaming input.

Tom

It simulates the signal delay of a satellite.

It is updated every millisecond.
The control mechanism is a block which calculates the satellite orbit
every
millisecond and measures the distance.

2014-09-23 14:54 GMT+02:00 Tom R. [email protected]:

[email protected]

[email protected]

[email protected]

[email protected]

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

Sorry, I have explained bad: S
I have the signal saved in a file and 10230000 samples are one second
(in
the real world).

In the first graph I have two clocks (counters samples). When passing
102300
samples it increase 0.01 seconds.
In the first watch this time controls the position of the satellite and
his
delay in this time. It allows to know what signal time is passing in the
delay block.

But I have a problem: clock 2 (a test clock) and clock 1 haven’t the
same
time; it has a drift.

Then, I must use clock 2 (
count the samples in the delay block output, not input). But it creates
a
loop.

2014-10-08 12:07 GMT+02:00 Marcus Müller [email protected]:

Hello Carlos,
On 08.10.2014 09:10, Carlos Alberto Ruiz Naranjo wrote:

I generate the signal from a file (10230000 samples/s) to a file. My
sampling clock drifts significantly :S
No. Unless I misunderstood you, you have a big misconception:
“sampling clock” is not the rate at which your samples pass through
your processing chain (ie. GNU Radio). It is the time base at which they
are measured, or simulated to, mathematically.
The device/software that actually captures the samples and saves them
has a fixed clock. If that clock changes too much a) compensate that in
software, if possible or b) get a better device.
This is digital signal processing. Real world time has no meaning
here, everything is measured relative to the interval between two
sampling times. You can process the signal as fast or slow as you want
to (as long as that doesn’t lead to things like overflows), and nothing
in the processing chain should care.

• Picture one: Counter Clock 2 is correct but Counter Clock 1 no.
Then I should use the second configuration, but it is not allowed because I
have a loop, right?
I don’t understand your graph, sorry

Greetings,
Marcus

If you don’t have hardware involved, you have no ‘clock’. And as such,
it can’t drift.

M

Yes, it is not a real time clock. This “clock” tracks the current time
of
the signal in GNURadio. clock2 and clock1 have a drift because the
number of
counted samples are different.

For example, if it pass 10230000 samples the delay block is entering the
delay in signal time = 1 second.
1 second in the real world (later I replay the signal with a USRP).

2014-10-08 13:18 GMT+02:00 Martin B. [email protected]:

In that case, just use nitems_read() [1] in your delay block to
inherently calculate “simulated time”.

However, I’m a bit curious about the effects of using delay to do this:
Because, as long as the satellite is approaching you, you’re
occasionally dropping samples, whereas you’re inserting zeros while it
moves away from the observer. Unless your 10.23MHz signal contains only
a oversampled signal you care about and then decimated after delay [2]
this potentially really differs from what you’d be seeing in a real

Greetings,
Marcus

[1]
[2] in which case that kind of has a doppler-y touch to it…

If you’re comparing real time (system clock) to your sample stream,
you’ll get jitter, not drift, using a throttle. Throttle maintains a
sample rate over time, but operates on blocks, and also is running under
a non-realtime operating system.

real world, that’s normal and you have to find ways to deal with it.

• Jeff

Delay Block is controlled by Satellite Orbit and Satellite Orbit by
“simulated clock”. The output of Satellite Orbit is the delay (samples).
Can I know the nitems_read of Delay Block from other block (Satellite
Orbit)?

Maybe a solution is to introduce Orbit Satellite in Delay block, but
this
is really inefficient to do tests. And a problem if I want to change the
Delay block for your solution (FFT).

Really the delay is in the non-modulated signal.

Jeff, it is a “simulated clock”. And it doesn’t run with throttle
because the
samples in the output of Delay block are different that the samples in
the
input.

2014-10-08 13:43 GMT+02:00 Jeff L. [email protected]:

Hi,

On 08.10.2014 14:38, Carlos Alberto Ruiz Naranjo wrote:

Delay Block is controlled by Satellite Orbit and Satellite Orbit by
“simulated clock”. The output of Satellite Orbit is the delay (samples).
Can I know the nitems_read of Delay Block from other block (Satellite
Orbit)?
Yes. It’s a public function, as you can see in the documentation I

Maybe a solution is to introduce Orbit Satellite in Delay block, but this
is really inefficient to do tests.
Good point, but you should be able to test your “calculate transmission
delay from an integer” functionality externally; also, there’s no reason
to have something like a class “delay_calculator”, with methods you call
from your modified delay block. You can test that very easily isolated.
And a problem if I want to change the
Delay block for your solution (FFT).
Well, yes, if you change approaches, the old approach will no longer
apply. That’s a design decision you’ll have to make.

Really the delay is in the non-modulated signal.
I don’t understand this sentence, sorry.

Greetings,
Marcus

OK !! Thank you very much for the tips. Next week I will use it in my PC
of
the lab.

The delay is in the data, not in the modulated signal. And I insert the
average between the previous and the next sample.

Greetings

2014-10-08 14:53 GMT+02:00 Marcus Müller [email protected]:

And a question. In:

uint64_t

How I know wich_input?

2014-10-08 15:08 GMT+02:00 Carlos Alberto Ruiz Naranjo <
[email protected]>:

Really the question is:

How can I call