Re: [Discuss-gnuradio] gr_delay behaviour

I am now just using a simple gr_block to asynchronously skip some samples from time to time by calling consume_each(d_skip_size); return 0; I didn't define any forecast function and it seems to work fine but I am wondering what is the performance impact of not doing this. Shouldn't I basically so

Re: [Discuss-gnuradio] gr_delay behaviour

On Tue, Oct 23, 2012 at 5:07 AM, Johannes Schmitz wrote: > One short question. What happens if I call the set_delay method of the > gr_delay block during runtime. Will it throw away/add some samples > when the delay is changed? If you increase the delay, you will skip over a number of items in th

Re: [Discuss-gnuradio] gr_delay behaviour

gr_delay pads "delay" number of zeros at the beginning of the sequence. see qa_delay.py in gnuradio/gnuradio-core/src/python/gnuradio/gr I also wanted to throw away some samples at the beginning, I imported the collected data in MATLAB, then threw away some samples and got it back in gnuradio .

Re: [Discuss-gnuradio] gr_delay

On 03/11/2011 2:44 PM, Johnathan Corgan wrote: On Wed, Nov 2, 2011 at 19:20, Marcus D. Leech > wrote: OK, so here's a new attemp, with dynamic selection of taps for the FIR filter. It also appears to not work. Only filter taps that exist on startup a

Re: [Discuss-gnuradio] gr_delay

On Wed, Nov 2, 2011 at 19:20, Marcus D. Leech wrote: > OK, so here's a new attemp, with dynamic selection of taps for the FIR > filter. It also appears to not work. Only filter taps that exist on > startup are working properly. Gulp. > Won't be able to look at this 'till the weekend. John

Re: [Discuss-gnuradio] gr_delay

On 11/02/2011 09:48 PM, Johnathan Corgan wrote: On Wed, Nov 2, 2011 at 18:41, Marcus D. Leech > wrote: Also, I wonder whether it has anything to do with the fact that it's a gr_sync_block, and not a gr_sync_decimator. The FIR filters are all gr_sync_d

Re: [Discuss-gnuradio] gr_delay

On 11/02/2011 09:45 PM, Johnathan Corgan wrote: You could create an FIR filter with zero-valued taps up to the delay, and a single 1.0 tap at the end, then modify the taps as needed to adjust the delay. Johnathan Slick. -- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy

Re: [Discuss-gnuradio] gr_delay

On Wed, Nov 2, 2011 at 18:41, Marcus D. Leech wrote: > Also, I wonder whether it has anything to do with the fact that it's a > gr_sync_block, and not a gr_sync_decimator. The FIR filters are all > gr_sync_decimators, and perhaps the block executors treatment of them > and their history setti

Re: [Discuss-gnuradio] gr_delay

On Wed, Nov 2, 2011 at 18:39, Marcus D. Leech wrote: > I want it for two-element interferometry (the nearly-degenerate-case of a > phased array :-) ). I can already do fine phase adjustment just using > complex phase rotation, but coarse adjustment requires that delays be > inserted. I need

Re: [Discuss-gnuradio] gr_delay

On 11/02/2011 09:33 PM, Johnathan Corgan wrote: On Wed, Nov 2, 2011 at 17:19, Marcus D. Leech > wrote: Your assertion that "it does take effect eventually" appears to not be true in reality (at least in this little test graph) (attached). Looking at the

Re: [Discuss-gnuradio] gr_delay

On 11/02/2011 09:33 PM, Johnathan Corgan wrote: On Wed, Nov 2, 2011 at 17:19, Marcus D. Leech > wrote: Your assertion that "it does take effect eventually" appears to not be true in reality (at least in this little test graph) (attached). Looking at the

Re: [Discuss-gnuradio] gr_delay

On Wed, Nov 2, 2011 at 17:19, Marcus D. Leech wrote: > Your assertion that "it does take effect eventually" appears to not be > true in reality (at least in this little test graph) (attached). > > Looking at the code, there's an inline function, set_delay, that calls > set_history(). And the SW

Re: [Discuss-gnuradio] gr_delay

On 11/02/2011 08:03 PM, Johnathan Corgan wrote: On Wed, Nov 2, 2011 at 16:43, Marcus D. Leech > wrote: To be clear, the problem appears to be with the block itself. GRC correctly adds the "set_delay" callback spooge. But calling that callback in the C++

Re: [Discuss-gnuradio] gr_delay

On Wed, Nov 2, 2011 at 16:43, Marcus D. Leech wrote: > > To be clear, the problem appears to be with the block itself. GRC > correctly adds the "set_delay" callback spooge. > > But calling that callback in the C++ code doesn't appear to affect the > delay. > Changing the delay via the callback

Re: [Discuss-gnuradio] gr_delay

On 11/02/2011 04:43 PM, Marcus D. Leech wrote: > On 11/02/2011 07:39 PM, Josh Blum wrote: >> >> On 11/02/2011 04:35 PM, Marcus D. Leech wrote: >>> It looks like setting the delay after block instantiation doesn't do >>> anything. I checked to see whether it was a GRC issue, or the block >>> itse

Re: [Discuss-gnuradio] gr_delay

On 11/02/2011 07:39 PM, Josh Blum wrote: On 11/02/2011 04:35 PM, Marcus D. Leech wrote: It looks like setting the delay after block instantiation doesn't do anything. I checked to see whether it was a GRC issue, or the block itself, and indeed, gr_delay doesn't do anything with a post-insta

Re: [Discuss-gnuradio] gr_delay

On 11/02/2011 04:35 PM, Marcus D. Leech wrote: > It looks like setting the delay after block instantiation doesn't do > anything. I checked to see whether it was a GRC issue, or the block > itself, > and indeed, gr_delay doesn't do anything with a post-instantiation > setting. trackered new i

Re: [Discuss-gnuradio] gr_delay behavior

Hi Martin, Thanks for the answer and my apologies for the guessing work. I reviewed my test code and it turns out that, as you say and as I was expecting, gr_delay works fine. A custom block I built is the one to blame for the misbehavior I'm seeing. I'll work on my custom block and eventually po

Re: [Discuss-gnuradio] gr_delay behavior

On Mon, Feb 22, 2010 at 10:42:08AM +0100, Carlos Aviles wrote: > gr_delay is intended to delay the input of the signal by n samples. > I've been doing some testing with that block and I have observed that > the delay is applied to the chunk of data that the block receives as > input (on my case tha

Re: [Discuss-gnuradio] gr_delay Is Not Working

Eric Blossom wrote: > > On Sun, Jun 10, 2007 at 12:00:49PM -0700, Eng. Firas wrote: >> >> Dear Eric, >> >> I think the new fix is not working also. I did not try it yet, but >> looking >> into the new code can tell us that the problem is still there as follows >> : >> old code : >> memcpy(optr

Re: [Discuss-gnuradio] gr_delay Is Not Working

On Sun, Jun 10, 2007 at 12:00:49PM -0700, Eng. Firas wrote: > > Dear Eric, > > I think the new fix is not working also. I did not try it yet, but looking > into the new code can tell us that the problem is still there as follows : > old code : > memcpy(optr, iptr + delay()*d_itemsize, noutput_ite

Re: [Discuss-gnuradio] gr_delay Is Not Working

Dear Eric, I think the new fix is not working also. I did not try it yet, but looking into the new code can tell us that the problem is still there as follows : old code : memcpy(optr, iptr + delay()*d_itemsize, noutput_items*d_itemsize); New code : memcpy(optr, iptr, noutput_items*d_itemsize);

Re: [Discuss-gnuradio] gr_delay Is Not Working

No, My last build was 2 months ago. Firas Eric Blossom wrote: > > On Sat, Jun 09, 2007 at 11:37:11PM -0700, Eng. Firas wrote: >> >> Hi, >> >> I tried to use gr_delay. It seems that it does not work at all. >> Does any body used it before and it worked out? >> >> Firas > > It was fixed in

Re: [Discuss-gnuradio] gr_delay Is Not Working

On Sat, Jun 09, 2007 at 11:37:11PM -0700, Eng. Firas wrote: > > Hi, > > I tried to use gr_delay. It seems that it does not work at all. > Does any body used it before and it worked out? > > Firas It was fixed in the trunk June 4th in changeset 5661. Are you building from the subversion trunk?