On 10/08/2014 03:24 PM, Carlos Alberto Ruiz Naranjo wrote: > Really the question is: > > How can I call > gr::block::nitems_read ( unsigned int /which_input/ ) > > from a block to know the nitems_read of another block?
You call 'nitems_read()'? Not sure you should be calling it from other blocks, though. Cheers, M > > 2014-10-08 15:10 GMT+02:00 Carlos Alberto Ruiz Naranjo > <carlosruiznara...@gmail.com <mailto:carlosruiznara...@gmail.com>>: > > And a question. In: > > uint64_t > > <http://gnuradio.org/doc/doxygen/stdint_8h.html#aec6fcb673ff035718c238c8c9d544c47> > gr::block::nitems_read ( unsigned int /which_input/ ) > > > How I know wich_input? > > 2014-10-08 15:08 GMT+02:00 Carlos Alberto Ruiz Naranjo > <carlosruiznara...@gmail.com <mailto:carlosruiznara...@gmail.com>>: > > 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 <mailto: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 > <mailto: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> > >>> <mailto: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>> > >>> > <mailto: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> > <mailto: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> > <mailto: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 <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
