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

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 <martin.braun@ettus.com
> <mailto: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>
> > <mailto: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 <mailto:Discuss-gnuradio@gnu.org>
> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> >
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org <mailto: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