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

[Marcus Müller]

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 world receiver.

Greetings,
Marcus

[1] http://gnuradio.org/doc/doxygen/classgr_1_1block.html#a2279d1eb421203bc5b0f100a6d5dc263
[2] in which case that kind of has a doppler-y touch to it...

On 08.10.2014 13:33, Carlos Alberto Ruiz Naranjo wrote:

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 Braun <address@hidden>:

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

M

On 10/08/2014 12:29 PM, Carlos Alberto Ruiz Naranjo wrote:

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 increase0.01 seconds.
In the first watchthis time controls the position of the satellite and
hisdelay 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 <address@hidden
<mailto:address@hidden>>:

    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




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

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

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