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>: > >> 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 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
