Re: [Discuss-gnuradio] dynamically changing delay in gr_delay (or history in any gr_block)

2011-11-16 Thread Achilleas Anastasopoulos
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
jcor...@corganenterprises.com wrote:
 On Tue, Nov 15, 2011 at 16:44, Marcus D. Leech mle...@ripnet.com 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: anas...@umich.edu
URL: http://www.eecs.umich.edu/~anastas/
___


test_delay.grc
Description: Binary data
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


Re: [Discuss-gnuradio] dynamically changing delay in gr_delay (or history in any gr_block)

2011-11-15 Thread Achilleas Anastasopoulos
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 mle...@ripnet.com 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: anas...@umich.edu
URL: http://www.eecs.umich.edu/~anastas/
___

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


Re: [Discuss-gnuradio] dynamically changing delay in gr_delay (or history in any gr_block)

2011-11-15 Thread Marcus D. Leech

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@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


Re: [Discuss-gnuradio] dynamically changing delay in gr_delay (or history in any gr_block)

2011-11-15 Thread Johnathan Corgan
On Tue, Nov 15, 2011 at 16:44, Marcus D. Leech mle...@ripnet.com 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@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


Re: [Discuss-gnuradio] dynamically changing delay in gr_delay (or history in any gr_block)

2011-11-15 Thread Marcus D. Leech

On 11/15/2011 11:19 PM, Johnathan Corgan wrote:
On Tue, Nov 15, 2011 at 16:44, Marcus D. Leech mle...@ripnet.com 
mailto:mle...@ripnet.com 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@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


Re: [Discuss-gnuradio] dynamically changing delay in gr_delay (or history in any gr_block)

2011-11-15 Thread Josh Blum


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




delaydemo.grc
Description: application/gnuradio-grc
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


[Discuss-gnuradio] dynamically changing delay in gr_delay (or history in any gr_block)

2011-11-15 Thread Achilleas Anastasopoulos
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@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


Re: [Discuss-gnuradio] dynamically changing delay in gr_delay (or history in any gr_block)

2011-11-15 Thread Marcus D. Leech

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@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


Re: [Discuss-gnuradio] dynamically changing delay in gr_delay (or history in any gr_block)

2011-11-15 Thread Achilleas Anastasopoulos
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 mle...@ripnet.com 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: anas...@umich.edu
URL: http://www.eecs.umich.edu/~anastas/
___

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


Re: [Discuss-gnuradio] dynamically changing delay in gr_delay (or history in any gr_block)

2011-11-15 Thread Marcus D. Leech

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@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


Re: [Discuss-gnuradio] dynamically changing delay in gr_delay (or history in any gr_block)

2011-11-15 Thread Achilleas Anastasopoulos
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 mle...@ripnet.com 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: anas...@umich.edu
URL: http://www.eecs.umich.edu/~anastas/
___


test_delay.grc
Description: Binary data
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


Re: [Discuss-gnuradio] dynamically changing delay in gr_delay (or history in any gr_block)

2011-11-15 Thread Marcus D. Leech

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@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio