discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] Assertion "imu >= 0" failed on random times


From: Tom Rondeau
Subject: Re: [Discuss-gnuradio] Assertion "imu >= 0" failed on random times
Date: Fri, 22 Apr 2011 13:39:29 -0400

On Fri, Apr 22, 2011 at 2:57 AM, Daniel Bartel <address@hidden> 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


 

reply via email to

[Prev in Thread] Current Thread [Next in Thread]