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.
–
Marcus L.
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
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 issue → http://gnuradio.org/redmine/issues/462
thanks
-josh
On 11/02/2011 07:39 PM, Josh B. wrote:
-josh
Discuss-gnuradio mailing list
[email protected]
Discuss-gnuradio Info Page
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.
–
Marcus L.
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
On 11/02/2011 04:43 PM, Marcus D. Leech wrote:
thanks
But calling that callback in the C++ code doesn’t appear to affect the
delay.
I guess the delay block should add extra delay cycles or insert dummy
samples depending upon the value. That could be useful
-josh
On Wed, Nov 2, 2011 at 16:43, Marcus D. Leech [email protected] 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 changes the history requirements of
the
block, which will not take effect until the thread executing the work()
function returns, and could be hundreds or thousands of items in the
future. But it does take effect eventually.
One way to change this behavior would be to implement the pattern used
in
the FIR blocks for when the number of taps changes. Changing the delay
would set a flag that the work function could check for and return
immediately. However, this wold come a high price, as the work()
function
currently uses memcpy to move data from the input to the output, and
instead you’d have to have an iterative loop with a conditional equality
check in the middle.
Johnathan
On Wed, Nov 2, 2011 at 17:19, Marcus D. Leech [email protected] 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 SWIG goop appears to be correct.
Quit finding bugs in years old, assumed working code!
It looks like this has never worked, and maybe was never even
implemented.
I’m combing through the appropriate archaeological strata in the tree to
see if the needed handling was removed at some point, but it looks
unlikely.
Johnathan
On 11/02/2011 09:33 PM, Johnathan C. wrote:
Quit finding bugs in years old, assumed working code!
It looks like this has never worked, and maybe was never even
implemented. I’m combing through the appropriate archaeological
strata in the tree to see if the needed handling was removed at some
point, but it looks unlikely.Johnathan
I even tried a quick “hack” that sets an “updated” flag, and at the top
of the work function, calling set_history() on a d_pending
delay value, and then immediately returning 0. That did nothing
useful.
If people have ever tried to use this for phased-array coarse delay
setting in a dynamic sense, it never would have worked.
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 to be able to do it dynamically.
One quick hack I tried was to have a bunch of delay blocks, each with
their own initial delay setting, and then selecting which one
I wanted. That worked just fine. So the initial set_history()
appears to have the desired effect.
On 11/02/2011 08:03 PM, Johnathan C. wrote:
the output, and instead you’d have to have an iterative loop with a
conditional equality check in the middle.Johnathan
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 SWIG goop appears to be correct.
On 11/02/2011 09:33 PM, Johnathan C. wrote:
Quit finding bugs in years old, assumed working code!
It looks like this has never worked, and maybe was never even
implemented. I’m combing through the appropriate archaeological
strata in the tree to see if the needed handling was removed at some
point, but it looks unlikely.Johnathan
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 setting is the main difference here.
On Wed, Nov 2, 2011 at 18:39, Marcus D. Leech [email protected] wrote:
I want it for two-element interferometry (the nearly-degenerate-case of a
phased array
complex phase rotation, but coarse adjustment requires that delays be
inserted. I need to be able to do it dynamically.One quick hack I tried was to have a bunch of delay blocks, each with
their own initial delay setting, and then selecting which one
I wanted. That worked just fine. So the initial set_history() appears
to have the desired effect.
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
On 11/02/2011 09:45 PM, Johnathan C. 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 L.
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
On 11/02/2011 09:48 PM, Johnathan C. wrote:
I don’t think it matters. Grepping the tree to find out what code
pays attention to d_history member in the block class turns up…very
little aside from the initial block construction sequence (creating
buffers, etc.)Johnathan
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.
On Wed, Nov 2, 2011 at 18:41, Marcus D. Leech [email protected] 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 setting is the main difference here.
I don’t think it matters. Grepping the tree to find out what code pays
attention to d_history member in the block class turns up…very little
aside from the initial block construction sequence (creating buffers,
etc.)
Johnathan
On 03/11/2011 2:44 PM, Johnathan C. wrote:
Johnathan
Fair enough.
I went through …/runtime last night, and indeed d_history seems to
only be “looked at” on initialization. So, how are
dynamically-changeable
FIR filters working at all? I await your weekendly wisdom.
On Wed, Nov 2, 2011 at 19:20, Marcus D. Leech [email protected] 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.
Johnathan
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
Sponsor our Newsletter | Privacy Policy | Terms of Service | Remote Ruby Jobs