You call another_block->nitems_read(number) with number being the number of the input stream (ie. 0 for the first, 1 for the second and so on). Remember, GNU Radio is C++, and blocks are built as classes.
Greetings, Marcus On 08.10.2014 15:24, 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? > > 2014-10-08 15:10 GMT+02:00 Carlos Alberto Ruiz Naranjo < > 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>: >> >>> 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
