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
