I generate the signal from a file (10230000 samples/s) to a file. My sampling clock drifts significantly :S
- 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'll try the method you say ;) 2014-10-07 14:13 GMT+02:00 Marcus Müller <marcus.muel...@ettus.com>: > Ok, you'll have to explain why you'd need throttle, as this is almost > never the case, especially not when a) working in a simulation or b) > working with "real" hardware, as that usually enforces a sampling rate. > If you know the physical sampling rate, counting samples *must* work, > unless your sampling clock drifts significantly, or you have *really* fast > moving satellites for which relativity is a concern at such low frequencies. > > Anyway, as an advisor told me once, if you want something done > mathematically right, do it mathematically right (that was on the subject > on simulating delay for radar targets): > Transform your signal to frequency domain, multiply it with a complex sine > of the frequency representing your time shift, and transform it back to > time domain. This allows you (within numerical precision of the complex > float and the length of your FFT) to have arbitrary accurate shifts, to > dynamically update the frequency (depending on how you generate the complex > sinusoid) and costs only moderately many ressources (OK, at roughly 10MS/s, > this might still be relevant). > > Greetings, > Marcus > > On 07.10.2014 12:48, Carlos Alberto Ruiz Naranjo wrote: > > I am having problems with the clock. > I need to track the real time of the signal. I have tried to get it with a > sample counter and a throttle (to maintain the rate), but it doesn't work. > The clock is faster or slower than the current signal time. > > Any idea? ;) > > 2014-09-23 20:13 GMT+02:00 Tom Rondeau <t...@trondeau.com> > <t...@trondeau.com>: > > > On Tue, Sep 23, 2014 at 9:25 AM, Carlos Alberto Ruiz Naranjo > <carlosruiznara...@gmail.com> wrote: > > > - SIGNAL: 10230000 samples/s > > - CLOCK: Counter that increments +0.001 when passing 10230 samples. > > - SATELLITE ORBIT: Calculate the satellite orbit and delay. > > > > > > Ok. My problem with this is that we're trying to get away from using > streaming data ports for control like this. Changing the state of a block > should be left to stream tags or messages. > > For your application, it might make sense if each data input to the block > matches to a very quickly-changing delay difference. In that case, though, > I would suggest that you keep an OOT module with your own implementation of > the delay block that does this for you. > > Tom > > > > > > _______________________________________________ > Discuss-gnuradio mailing > listDiscuss-gnuradio@gnu.orghttps://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
