Hi, On 08.10.2014 14:38, Carlos Alberto Ruiz Naranjo wrote: > 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)? Yes. It's a public function, as you can see in the documentation I linked. > > Maybe a solution is to introduce Orbit Satellite in Delay block, but this > is really inefficient to do tests. Good point, but you should be able to test your "calculate transmission delay from an integer" functionality externally; also, there's no reason to have something like a class "delay_calculator", with methods you call from your modified delay block. You can test that very easily isolated. > And a problem if I want to change the > Delay block for your solution (FFT). Well, yes, if you change approaches, the old approach will no longer apply. That's a design decision you'll have to make.
> > Really the delay is in the non-modulated signal. I don't understand this sentence, sorry. Greetings, Marcus > > > > 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
