OK !! Thank you very much for the tips. Next week I will use it in my PC of the lab. ;)
The delay is in the data, not in the modulated signal. And I insert the average between the previous and the next sample. Greetings 2014-10-08 14:53 GMT+02:00 Marcus Müller <marcus.muel...@ettus.com>: > 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
