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
