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