On Fri, Apr 22, 2011 at 2:57 AM, Daniel Bartel
<[email protected]>wrote:
> 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
>
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
_______________________________________________
Discuss-gnuradio mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
