Re: [Discuss-gnuradio] Ettus N210 GMSK 9600

[Andy Walls]

On Fri, 2016-03-25 at 12:00 -0400, address@hidden
wrote:

> I do have that fix in place.  I added the tag_debug for time_est.  I'm
> not
> sure which value causes the error, but I see:
> 

> thread[thread-per-block[17]: <block msk_timing_recovery_cc (10)>]:
> mmse_fir_interpolator_cc: imu out of bounds.
> 
> 
> ----------------------------------------------------------------------
> Tag Debug: corr_est
> Input Stream: 00
>   Offset: 40221  Source: corr_est_cc0     Key: time_est   Value: 0.0493416
>   Offset: 40231  Source: corr_est_cc0     Key: time_est   Value: -0.022505
>   Offset: 40271  Source: corr_est_cc0     Key: time_est   Value: 0.305939
>   Offset: 40292  Source: corr_est_cc0     Key: time_est   Value: 0.130002
>   Offset: 40302  Source: corr_est_cc0     Key: time_est   Value: -1.17942
And there it is --------------------------------------------------^^^^^^^^
:(


----------------------------------------------------------------------
> Tag Debug: corr_est
> Input Stream: 00
>   Offset: 46763  Source: corr_est_cc0     Key: time_est   Value: 0.0567441
>   Offset: 46773  Source: corr_est_cc0     Key: time_est   Value: -1.31157
> And there is another ---------------------------------------------^^^^^^^^
:(



The corr_est block shouldn't be outputing values outside of [-1.0, 1.0].
The msk_timing_recovery block should do the right thing for values
within [-1.0, 1.0] and do something sensible for values outside of that
range.

Right now the msk_timing_recovery block only does the right thing for
values in the range [0.0, 1.0), does the wrong thing (I think) for
values in (-1.0, 0.0), and bombs out for values outside of that range.


So two fixes have to take place:

a) the msk_timing_recovery block needs to handle all time_est values
properly, including garbage values.

b) the corr_est block needs to be fixed to generate time_est values
restricted to the range (-1.0, 1.0) 


I'm booked up until April 4th, so don't wait for fixes from me, if
you're in a hurry.

FWIW, I couldn't get the attached flowgraph (which looks to correlate to
the HDLC flag) to crash.  I was probably just lucky.

-Andy

gmsk9600_test2.grc
Description: application/xml