I’m having difficulty with a block I’m writing that I’ve been
unable to resolve, and I hope somebody out there can help.
The block’s input and output run at different rates, so I
inherited from gr_block, as in the howto-write-a-block-3.1.1
first example. In addition, I supplied a forecast method
that returns the number of input items required for a given
number of output items, and I used the
“set_relative_rate” method in the constructor to set
the relative rate to output_rate/input_rate.
When I do a “make check” to run my test case, I get:
Making check in python
make check-TESTS
…/gr_buffer.h:96: failed assertion `s < d_bufsize’
After a little debug, I found that this happens when
fg.run() is invoked.
The code in gr_buffer.h does not ovver much to go on ,
other than the fact that it happens while doing an
“add”.
Can someone who is more familiar with the runtime
system point me in the right direction? My details
are:
MacBook Pro dual 2.33 GHz
Mac OSX 10.4.11
Gnu Radio 3.1.1
TIA
@(^.^)@ Ed
On Mon, Nov 19, 2007 at 10:43:32AM -0500, Ed Criscuolo wrote:
other than the fact that it happens while doing an
“add”.
Can someone who is more familiar with the runtime
system point me in the right direction? My details
are:
MacBook Pro dual 2.33 GHz
Mac OSX 10.4.11
Gnu Radio 3.1.1
Hi Ed,
This is usually caused by doing something like returning an incorrect
value from general_work or consuming more than you were given. Check
your calls to consume/consume_each and your return value.
Eric
On Mon, Nov 19, 2007 at 10:43:32AM -0500, Ed Criscuolo wrote:
I’m having difficulty with a block I’m writing that I’ve been
unable to resolve, and I hope somebody out there can help.
The block’s input and output run at different rates, so I
inherited from gr_block, as in the howto-write-a-block-3.1.1
first example. In addition, I supplied a forecast method
that returns the number of input items required for a given
number of output items, and I used the
“set_relative_rate” method in the constructor to set
the relative rate to output_rate/input_rate.
BTW, is the input rate to output rate relationship constant?
E.g., 1:N or N:1. If so, you can use the gr_sync_interpolator or
gr_sync_decimator base class. Less likelihood of trouble with those 
Eric
Yes, the relative rate is constant.
It was my understanding that the sync_interpolator class
interpolates zeros into the data stream, requiring you to
low-pass filter the results to remove the introduced
high-frequency ailasing. This wasn’t suitable my use, as
I’m trying to resample a digital bitstream, and the
interpolated values need to duplicate the previous
input value.
Is my understanding wrong?
@(^.^)@ Ed
Eric B. wrote:
Take a look at general/gr_bytes_to_syms.{h,cc}.
(It’s deprecated because there’s a more general way to solve the
problem it was addressing. However, the basic pattern is sound.)
Eric,
I looked at gr_bytes_to_syms, and at gr_sync_interpolator.
gr_sync_interpolator requires a 1:N integer interpolation factor.
My digital bitstream’s rate is unrelated to my output rate,
so my interpolation factor is a floating point rational number
expressable as M:N. It’s similar to the rational_resampler,
but in the digital-bitstream domain instead of in the
digitized-analog-signal domain.
I checked my consume_each and return value, and did find
an “off-by-one” error, but I’m still getting the
failed assertion `s < d_bufsize’
error.
@(^.^)@ Ed
On Mon, Nov 19, 2007 at 12:09:29PM -0500, Ed Criscuolo wrote:
I looked at gr_bytes_to_syms, and at gr_sync_interpolator.
failed assertion `s < d_bufsize’
error.
Are you consuming more input than is available (as indicated by the
ninput_items argument to general_work)?
I suspect a problem either in forecast or in your loop control
in general_work.
Regarding “floating point rational number”: if it’s M:N perhaps you
should be working with rationals, not floats.
Eric
On Mon, Nov 19, 2007 at 11:19:05AM -0500, Ed Criscuolo wrote:
Yes, the relative rate is constant.
It was my understanding that the sync_interpolator class
interpolates zeros into the data stream, requiring you to
low-pass filter the results to remove the introduced
high-frequency ailasing.
It doesn’t insert anything into the data stream.
Everything is left up to your work method.
Take a look at general/gr_bytes_to_syms.{h,cc}.
(It’s deprecated because there’s a more general way to solve the
problem it was addressing. However, the basic pattern is sound.)
This wasn’t suitable my use, as I’m trying to resample a digital
bitstream, and the interpolated values need to duplicate the
previous input value.
Is my understanding wrong?
Yes
Eric
Eric B. wrote:
Are you consuming more input than is available (as indicated by the
ninput_items argument to general_work)?
I suspect a problem either in forecast or in your loop control
in general_work.
I finally found a subtle bug that was clobbering the return value
fron general_work right before the return. Works fine now.
Thanks for the help!
@(^.^)@ Ed
On Tue, Nov 20, 2007 at 02:07:56PM -0500, Ed Criscuolo wrote:
I finally found a subtle bug that was clobbering the return value
fron general_work right before the return. Works fine now.
Thanks for the help!
You’re welcome. Glad to hear you got it sorted out.
Eric