Now the clock runs fine (with gr::block::nitems_read). But I have another problem: I have a rate of 10.23 million samples per second and I need to delay the signal +-1ns. With the modified block delay (controlled by an input) I can delay the signal 97.75ns (1 / 10,230,000 -> + - one sample).
Could I use the fractional resampler block to enter a variable fractional delay? 1ns? What is the exact meaning of the parameter mu? http://gnuradio.org/doc/doxygen-3.6/classgr_1_1filter_1_1mmse__fir__interpolator__ff.html I do not understand it :S 2014-10-08 15:35 GMT+02:00 Martin Braun <[email protected]>: > 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 > > <[email protected] <mailto:[email protected]>>: > > > > 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 > > <[email protected] <mailto:[email protected]>>: > > > > 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 > > <[email protected] <mailto:[email protected]>>: > > > > 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 <[email protected] > > <mailto:[email protected]>>: > > > > > >> 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 > > <[email protected] <mailto:[email protected]> > > >>> <mailto:[email protected] > > <mailto:[email protected]>>>: > > >>> > > >>> 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 > > <[email protected] <mailto:[email protected]> > > >>> <mailto:[email protected] > > <mailto:[email protected]>> > > >>> > <mailto:[email protected] > > <mailto:[email protected]> > > <mailto:[email protected] > > <mailto:[email protected]> > > >>>>>> : > > >>> > > > >>> > 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 > > >>> > [email protected] > > <mailto:[email protected]> > > <mailto:[email protected] > > <mailto:[email protected]>> > > >>> > > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > >>> > > > >>> > > >>> > > >>> _______________________________________________ > > >>> Discuss-gnuradio mailing list > > >>> [email protected] > > <mailto:[email protected]> > > <mailto:[email protected] > > <mailto:[email protected]>> > > >>> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > >>> > > >>> > > >>> > > >>> > > >>> _______________________________________________ > > >>> Discuss-gnuradio mailing list > > >>> [email protected] <mailto: > [email protected]> > > >>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > >>> > > >>> > > >> _______________________________________________ > > >> Discuss-gnuradio mailing list > > >> [email protected] <mailto:[email protected] > > > > >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > >> > > > > > > > > > > > > > > _______________________________________________ > > Discuss-gnuradio mailing list > > [email protected] > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > > > > _______________________________________________ > Discuss-gnuradio mailing list > [email protected] > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >
_______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
