dynamically changing delay in gr_delay (or history in any gr_block)

: · file

-- 
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org

	dynamically changing delay in gr_delay (or history in any gr_block) by Achilleas Anastasopoulos :: Rate this Message: Reply \| View Threaded \| Show Only this Message I made a simple example with a cosine and a delayed version of that going through a multiplier, and observing the output together with a slider that changes the delay dynamically. However i do not see any change (eg, elimination of the dc component when delay ~ pi/2). Looking at the code of the block gr_delay it shows that the delay can dynamically change and this results essentially in a call to set_history() in gr_block. Looking further into the set_history() method, it sets the private variable d_history. The question is: does the dynamic change of history have any effect in gr_block? What happens in the guts of the block when d_history changes? and why don't i see any effect in the example above? thanks Achilleas _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@... https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
	Re: dynamically changing delay in gr_delay (or history in any gr_block) by Marcus D. Leech :: Rate this Message: Reply \| View Threaded \| Show Only this Message On 15/11/2011 3:00 PM, Achilleas Anastasopoulos wrote: > I made a simple example with a cosine and a delayed version of that > going through > a multiplier, and observing the output together with a slider that > changes the delay dynamically. > However i do not see any change (eg, elimination of the dc component > when delay ~ pi/2). > > > Looking at the code of the block gr_delay it shows that the delay can > dynamically change > and this results essentially in a call to set_history() in gr_block. > Looking further into the set_history() method, it sets the private > variable d_history. > > The question is: does the dynamic change of history have any effect in gr_block? > What happens in the guts of the block when d_history changes? > and why don't i see any effect in the example above? > > thanks > Achilleas I ran into the exact same thing a couple of weeks ago. It has to do with the deep-structure of the schedule, and Jonathan Corgan had indicated he was going to look into it. The weird thing is that FIR filters do the same thing when you change the number of tapes (muck with d_history), but they actually work dynamically after you change them. _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@... https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
	Re: dynamically changing delay in gr_delay (or history in any gr_block) by Achilleas Anastasopoulos :: Rate this Message: Reply \| View Threaded \| Show Only this Message I actually tried using filters to implement the delay and they do NOT work as expected: I used "Interpolating FIR filter" with taps equal to (0,)delay+(1,) and i didn't see any difference as i was changing the delay parameter dynamically.... Achilleas On Tue, Nov 15, 2011 at 3:05 PM, Marcus D. Leech < mleech@...> wrote: > On 15/11/2011 3:00 PM, Achilleas Anastasopoulos wrote: >> >> I made a simple example with a cosine and a delayed version of that >> going through >> a multiplier, and observing the output together with a slider that >> changes the delay dynamically. >> However i do not see any change (eg, elimination of the dc component >> when delay ~ pi/2). >> >> >> Looking at the code of the block gr_delay it shows that the delay can >> dynamically change >> and this results essentially in a call to set_history() in gr_block. >> Looking further into the set_history() method, it sets the private >> variable d_history. >> >> The question is: does the dynamic change of history have any effect in >> gr_block? >> What happens in the guts of the block when d_history changes? >> and why don't i see any effect in the example above? >> >> thanks >> Achilleas > > I ran into the exact same thing a couple of weeks ago. It has to do with > the deep-structure of the schedule, and Jonathan Corgan had > indicated he was going to look into it. > > The weird thing is that FIR filters do the same thing when you change the > number of tapes (muck with d_history), but they actually > work* dynamically after you change them. > > > > -- _______________________________________________________ Achilleas Anastasopoulos Associate Professor EECS Department Voice : (734)615-4024 UNIVERSITY OF MICHIGAN Fax : (734)763-8041 Ann Arbor, MI 48109-2122 E-mail: anastas@... URL: http://www.eecs.umich.edu/~anastas/ _______________________________________________________ _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@... https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
	Re: dynamically changing delay in gr_delay (or history in any gr_block) by Marcus D. Leech :: Rate this Message: Reply \| View Threaded \| Show Only this Message On 11/15/2011 05:01 PM, Achilleas Anastasopoulos wrote: > I actually tried using filters to implement the delay and they do NOT > work as expected: > > I used "Interpolating FIR filter" with taps equal to (0,)*delay+(1,) > and i didn't see any difference as i was changing the delay parameter > dynamically.... > > > Achilleas > > The filtering still seems to work, but the delay (based on d_history) appears not to. >> > > -- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@... https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
	Re: dynamically changing delay in gr_delay (or history in any gr_block) by Achilleas Anastasopoulos :: Rate this Message: Reply \| View Threaded \| Show Only this Message Take a look at the attached grc file: As implemented, it does not work (changing the delay does not have an effect). If I introduce the "fictitious" filter (1,0,0,0,0,..) it works as expected. AM I doing something wrong in the first case? Achilleas On Tue, Nov 15, 2011 at 5:26 PM, Marcus D. Leech < mleech@...> wrote: > On 11/15/2011 05:01 PM, Achilleas Anastasopoulos wrote: >> >> I actually tried using filters to implement the delay and they do NOT >> work as expected: >> >> I used "Interpolating FIR filter" with taps equal to (0,)delay+(1,) >> and i didn't see any difference as i was changing the delay parameter >> dynamically.... >> >> >> Achilleas >> >> > The filtering still seems to work, but the delay (based on d_history) > appears not to. > > >>> >> >> > > > -- > Marcus Leech > Principal Investigator > Shirleys Bay Radio Astronomy Consortium > http://www.sbrac.org > > -- _______________________________________________________ Achilleas Anastasopoulos Associate Professor EECS Department Voice : (734)615-4024 UNIVERSITY OF MICHIGAN Fax : (734)763-8041 Ann Arbor, MI 48109-2122 E-mail: anastas@... URL: http://www.eecs.umich.edu/~anastas/ _______________________________________________________ _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@... https://lists.gnu.org/mailman/listinfo/discuss-gnuradio test_delay.grc* (11K) Download Attachment
	Re: dynamically changing delay in gr_delay (or history in any gr_block) by Marcus D. Leech :: Rate this Message: Reply \| View Threaded \| Show Only this Message On 11/15/2011 06:16 PM, Achilleas Anastasopoulos wrote: > Take a look at the attached grc file: > > As implemented, it does not work (changing the delay does not have an effect). > > If I introduce the "fictitious" filter (1,0,0,0,0,..) > it works as expected. > > AM I doing something wrong in the first case? > > Achilleas > It seems that the runtime machinery pays attention to d_history only on block init, and at no other time, which leads to unexpected results. But, surely, this must have worked at some point? I mean, I regularly use filters whose parameters I change dynamically, and they apparently do what I want, although, perhaps at the moment of changing parameters, the phasing isn't "right", but they seem to work. Someone with more exposure to the gr-runtime stuff should comment here. > > -- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@... https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
	Re: dynamically changing delay in gr_delay (or history in any gr_block) by Achilleas Anastasopoulos :: Rate this Message: Reply \| View Threaded \| Show Only this Message Marcus, The grc file that i sent does not support your theory: I have 2 filters: one with taps: (0,)delay+(1,) and the other with taps (1,)+(0,)delay then I can change the delay dynamically, which also means that the history is also changed dynamically (NOT ONLY AT INIT) and there is no problem whatsoever. Clearly the second filter is not needed but if i get rid of it then the whole thing does not work... I am really confused... Achilleas On Tue, Nov 15, 2011 at 6:21 PM, Marcus D. Leech < mleech@...> wrote: > On 11/15/2011 06:16 PM, Achilleas Anastasopoulos wrote: >> >> Take a look at the attached grc file: >> >> As implemented, it does not work (changing the delay does not have an >> effect). >> >> If I introduce the "fictitious" filter (1,0,0,0,0,..) >> it works as expected. >> >> AM I doing something wrong in the first case? >> >> Achilleas >> > It seems that the runtime machinery pays attention to d_history only on > block init, and at no other time, which leads to unexpected > results. But, surely, this must have worked at some point? > > I mean, I regularly use filters whose parameters I change dynamically, and > they apparently do what I want, although, perhaps at the moment > of changing parameters, the phasing isn't "right", but they seem to work. > > Someone with more exposure to the gr-runtime stuff should comment here. > > >> >> > > > -- > Marcus Leech > Principal Investigator > Shirleys Bay Radio Astronomy Consortium > http://www.sbrac.org > > -- _______________________________________________________ Achilleas Anastasopoulos Associate Professor EECS Department Voice : (734)615-4024 UNIVERSITY OF MICHIGAN Fax : (734)763-8041 Ann Arbor, MI 48109-2122 E-mail: anastas@... URL: http://www.eecs.umich.edu/~anastas/ _______________________________________________________ _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@... https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
	Re: dynamically changing delay in gr_delay (or history in any gr_block) by Marcus D. Leech :: Rate this Message: Reply \| View Threaded \| Show Only this Message On 11/15/2011 07:24 PM, Achilleas Anastasopoulos wrote: > Marcus, > > The grc file that i sent does not support your theory: > I have 2 filters: > > one with taps: (0,)delay+(1,) > and the other with taps (1,)+(0,)delay > > then I can change the delay dynamically, which also means that the > history is also changed dynamically (NOT ONLY AT INIT) and there is no problem > whatsoever. > Clearly the second filter is not needed but if i get rid of it then the whole > thing does not work... > > I am really confused... > Achilleas > Yes, there's some deep weirdness. The only time the runtime pays attention to history, in my second pass through there, is in forecast() computations, via a little inlined function called "history()", which just returns "d_history". Not sure what this means. But clearly, there's some brokenness there, and it's not clear to me how to fix it, although I desperately want dynamically-settable gr_delay() blocks to work as well, for some interferometry work. -- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@... https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
	Re: dynamically changing delay in gr_delay (or history in any gr_block) by Johnathan Corgan-2 :: Rate this Message: Reply \| View Threaded \| Show Only this Message On Tue, Nov 15, 2011 at 16:44, Marcus D. Leech <mleech@...> wrote: But clearly, there's some brokenness there, and it's not clear to me how to fix it, although I desperately want dynamically-settable gr_delay() blocks to work as well, for some interferometry work. Sorry, I've been buried in some commercial projects that haven't left me with much time to look at the issue more in depth. I can confirm that dynamically changing the delay in gr_delay does not (and never has) worked. The fix for this is not that complex but it would be a change in the runtime that would need a lot of regression testing. In the FIR-based delay scenario, it would be useful to know if there is a difference between changing the taps from, say [0, 0, 0, 0, 1] to [0, 0, 1], so the taps end up changing length, or changing the position of the 1 but leaving trailing 0's so the tap length would remain the same. Johnathan _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@... https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
	Re: dynamically changing delay in gr_delay (or history in any gr_block) by Marcus D. Leech :: Rate this Message: Reply \| View Threaded \| Show Only this Message On 11/15/2011 11:19 PM, Johnathan Corgan wrote: On Tue, Nov 15, 2011 at 16:44, Marcus D. Leech <mleech@...> wrote: But clearly, there's some brokenness there, and it's not clear to me how to fix it, although I desperately want dynamically-settable gr_delay() blocks to work as well, for some interferometry work. Sorry, I've been buried in some commercial projects that haven't left me with much time to look at the issue more in depth. What, you want to feed your kids in preference to helping a buncha feeloaders like us? :-) :-) -- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@... https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
	Re: dynamically changing delay in gr_delay (or history in any gr_block) by Josh Blum-2 :: Rate this Message: Reply \| View Threaded \| Show Only this Message On 11/15/2011 12:00 PM, Achilleas Anastasopoulos wrote: > I made a simple example with a cosine and a delayed version of that > going through > a multiplier, and observing the output together with a slider that > changes the delay dynamically. > However i do not see any change (eg, elimination of the dc component > when delay ~ pi/2). > > > Looking at the code of the block gr_delay it shows that the delay can > dynamically change > and this results essentially in a call to set_history() in gr_block. > Looking further into the set_history() method, it sets the private > variable d_history. > > The question is: does the dynamic change of history have any effect in gr_block? > What happens in the guts of the block when d_history changes? > and why don't i see any effect in the example above? > I dont think that set history works quite that way. I made a new delay block in gr-basic. Demo in GRC attached. Here is the implementation: http://gnuradio.org/cgit/jblum.git/tree/gr-basic/lib/gr_basic_delay.cc?h=gr_basic -Josh _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@... https://lists.gnu.org/mailman/listinfo/discuss-gnuradio delaydemo.grc (9K) Download Attachment
	Re: dynamically changing delay in gr_delay (or history in any gr_block) by Achilleas Anastasopoulos :: Rate this Message: Reply \| View Threaded \| Show Only this Message I can confirm that if my FIR taps are defined as: (0,)delay+(1,)+(0,)(19-delay) then i can change the delay dynamically for any values between 0 and 19 in the grc file that i sent earlier (attached here as well) EVEN without the second (trivial) FIR filter present! So it is clearer now that the problem with delay/filters is in the setting of history... thanks for the hints! Achilleas PS: Johnathan, could you give us a simple explanation of what happens in the internals when there is a history change so that at least we understand the computational model. On Tue, Nov 15, 2011 at 11:19 PM, Johnathan Corgan < jcorgan@...> wrote: > On Tue, Nov 15, 2011 at 16:44, Marcus D. Leech < mleech@...> wrote: >> >> But clearly, there's some brokenness there, and it's not clear to me how >> to fix it, although I desperately want dynamically-settable >> gr_delay() blocks to work as well, for some interferometry work. > > Sorry, I've been buried in some commercial projects that haven't left me > with much time to look at the issue more in depth. > > I can confirm that dynamically changing the delay in gr_delay does not (and > never has) worked. The fix for this is not that complex but it would be a > change in the runtime that would need a lot of regression testing. > > In the FIR-based delay scenario, it would be useful to know if there is a > difference between changing the taps from, say [0, 0, 0, 0, 1] to [0, 0, 1], > so the taps end up changing length, or changing the position of the 1 but > leaving trailing 0's so the tap length would remain the same. > > Johnathan > -- _______________________________________________________ Achilleas Anastasopoulos Associate Professor EECS Department Voice : (734)615-4024 UNIVERSITY OF MICHIGAN Fax : (734)763-8041 Ann Arbor, MI 48109-2122 E-mail: anastas@... URL: http://www.eecs.umich.edu/~anastas/ _______________________________________________________ _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@... https://lists.gnu.org/mailman/listinfo/discuss-gnuradio test_delay.grc (12K) Download Attachment

dynamically changing delay in gr_delay (or history in any gr_block)

dynamically changing delay in gr_delay (or history in any gr_block)

dynamically changing delay in gr_delay (or history in any gr_block)

Re: dynamically changing delay in gr_delay (or history in any gr_block)

Re: dynamically changing delay in gr_delay (or history in any gr_block)

Re: dynamically changing delay in gr_delay (or history in any gr_block)

Re: dynamically changing delay in gr_delay (or history in any gr_block)

Re: dynamically changing delay in gr_delay (or history in any gr_block)

Re: dynamically changing delay in gr_delay (or history in any gr_block)

Re: dynamically changing delay in gr_delay (or history in any gr_block)

Re: dynamically changing delay in gr_delay (or history in any gr_block)

Re: dynamically changing delay in gr_delay (or history in any gr_block)

Re: dynamically changing delay in gr_delay (or history in any gr_block)

Re: dynamically changing delay in gr_delay (or history in any gr_block)