Hello,
in the program I am currently working on, I sometimes get the following
error messsage:
python: gri_mmse_fir_interpolator_cc.cc:66: gr_complex
gri_mmse_fir_interpolator_cc::interpolate(const gr_complex*, float):
Zusicherung »imu >= 0« nicht erfüllt.
Abgebrochen
It seems like the assertion “imu >= 0” failed.
The strange thing is, that the message behaves completely
non-deterministic.
e.g. When I start the program 4 times, on the first 3 runs I get the
error message and suddenly at the 4th try, it runs without an error.
The assertion comes from the following method, which is located in the
gri_mmse_fir_interpolator_cc.cc file.
gr_complex
gri_mmse_fir_interpolator_cc::interpolate (const gr_complex input[],
float mu)
{
int imu = (int) rint (mu * NSTEPS);
assert (imu >= 0);
assert (imu <= NSTEPS);
gr_complex r = filters[imu]->filter (input);
return r;
}
Does anyone has an explanation for this behavior or for what “imu >= 0”
stands for?
Thanks for your help,
Daniel
On Fri, Apr 22, 2011 at 2:57 AM, Daniel Bartel
[email protected]wrote:
It seems like the assertion “imu >= 0” failed.
mu)
Does anyone has an explanation for this behavior or for what “imu >= 0”
stands for?
Thanks for your help,
Daniel
The imu value tells the interpolating filter where in the filter to take
the
output from. This is used in the M&M blocks to determine what phase
offset
to select in the sample stream; it first interpolates the samples up and
then selects the phase that, in the steady-state condition, determines
the
sample peak without actually changing the sample clock.
It’s likely that whatever block is calling this interpolating filter is
updating its mu value from some error signal and driving it negative.
The
input mu should really be 0 <= mu <= 1. So it’s correct to check the imu
condition inside of the block (although we could argue if using asserts
is
really the best way to do this). But it might be better have a check in
the
block that calls the interpolator for the mu condition I have here, and
possibly just clip mu so that if(mu > 1) mu=1; if(mu < 0) mu=0. It’s
possible that under these conditions, the block won’t converge at all,
but
it also won’t blow up.
What block are you using to call the interpolator? What values is the
block
working off? If it’s the M&M clock recovery block, it’s possible that
the
amplitude your input signal is too high, which is causing overly-large
error
values that are resulting in mu being driven negative.
Tom
Hi Tom,
thanks for your explanation and sorry for my late reply.
What block are you using to call the interpolator? What values is the block
working off? If it’s the M&M clock recovery block, it’s possible that the
amplitude your input signal is too high, which is causing overly-large error
values that are resulting in mu being driven negative.
You’re right, it’s the M&M clock recovery block, which calls the
interpolator.
What do you mean with “that the amplitude your input signal is too
high”?
Are there any restricts concerning amplitudes inside the flowgraph?
Kind regards,
Daniel
On Sat, Apr 30, 2011 at 8:10 PM, Daniel Bartel
[email protected]wrote:
What do you mean with “that the amplitude your input signal is too high”?
Are there any restricts concerning amplitudes inside the flowgraph?
Kind regards,
Daniel
This is one of those “theoretically…” answers. Theoretically, there
should
be no restrictions on the amplitude of the signal. In practice, however,
you’ll want the signal to go into the block at +/- 1. From my
experiments
with it, you don’t have to be very close to that, and there’s no hard
limit
on what is acceptable. But if you are putting in signals that are in the
thousands, you’ll probably run into trouble.
Tom