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

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 <martin.braun@ettus.com>:    

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 <marcus.mueller@ettus.com  <mailto:marcus.mueller@ettus.com>>:        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  Discuss-gnuradio@gnu.org  https://lists.gnu.org/mailman/listinfo/discuss-gnuradio    

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

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