See also http://gnuradio.org/redmine/projects/gnuradio/wiki/FAQ#What-does-sample-rate-mean-in-GNU-Radio.
M On 10/08/2014 01:18 PM, Martin Braun wrote: > 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
