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.br...@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.muel...@ettus.com > > <mailto:marcus.muel...@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
