|Subject:||Re: [Discuss-gnuradio] Delay block controlled by input|
|Date:||Wed, 08 Oct 2014 13:40:07 +0200|
|User-agent:||Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0|
In that case, just use nitems_read()  in your delay block to
inherently calculate "simulated time".|
However, I'm a bit curious about the effects of using delay to do this:
Because, as long as the satellite is approaching you, you're occasionally dropping samples, whereas you're inserting zeros while it moves away from the observer. Unless your 10.23MHz signal contains only a oversampled signal you care about and then decimated after delay  this potentially really differs from what you'd be seeing in a real world receiver.
 in which case that kind of has a doppler-y touch to it...
On 08.10.2014 13:33, 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 <address@hidden>: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 <address@hidden <mailto:address@hidden>>: 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 whichtheyare 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 thatinsoftware, 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 youwantto (as long as that doesn't lead to things like overflows), andnothingin 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 allowedbecause I> have a loop, right? I don't understand your graph, sorry :( Greetings, Marcus _______________________________________________ Discuss-gnuradio mailing list address@hidden https://lists.gnu.org/mailman/listinfo/discuss-gnuradio_______________________________________________ Discuss-gnuradio mailing list address@hidden https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
|[Prev in Thread]||Current Thread||[Next in Thread]|