[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Marcus Müller
Subject: Re: [Discuss-gnuradio] Delay block controlled by input
Date: Wed, 08 Oct 2014 13:40:07 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0

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.


[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.


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

    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.
    > 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
    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
    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
    to (as long as that doesn't lead to things like overflows), and
    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 :(


Discuss-gnuradio mailing list

Discuss-gnuradio mailing list


Discuss-gnuradio mailing list

reply via email to

[Prev in Thread] Current Thread [Next in Thread]