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

[Carlos Alberto Ruiz Naranjo]

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