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

[Carlos Alberto Ruiz Naranjo]

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

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.

If you're talking about drift between the clock on your receiver and the real world, that's normal and you have to find ways to deal with it.

- Jeff

On 10/08/2014 07:33 AM, 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
<mailto: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@hiddencom>
     > <mailto:address@hiddencom <mailto:address@hiddencom>>>:
    >
    >     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 <mailto:address@hiddenorg>
     > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
     >


    _______________________________________________
    Discuss-gnuradio mailing list
    address@hidden <mailto:address@hiddenorg>
    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