From:
Tom Golden
Date:
Thu, 24 Mar 2016 13:07:57 -0600
________________________________________________________________________
>Sorry - I was attempting to be courteous to other users.
No worries. It's just that others can't learn and contribute, if the
conversation goes off list. Also, I charge for private consulting. ;)
If other users don't like on-topic posts, then I suppose they'll be
unsubscribing shortly anyway.
>I added a Correlation Estimator before the MSK Timing Recover looking
>for 0x7E (the start frame byte for AX.25). I think it found it (based
>on the image below) - unfortunately when it hits, execution stops with
>the error:
>thread[thread-per-block[9]: <block msk_timing_recovery_cc (8)>]:
>mmse_fir_interpolator_cc: imu out of bounds.
Ah crud, that bug.
OK, in the MSK timing recovery block, "mu" is an inter-sample distance
in the range [0.0, 1.0), which gets passed to the mmse_fir_interpolator
to interpolate between samples.
The MSK timing recovery block doesn't do enough sanity checking on the
"time_est" tag payload value produced by the corr_est block, so it
screws up its internal value of "mu" and then bombs.
Does your version of gnuradio have this fix in place:
https://github.com/gnuradio/gnuradio/blob/master/gr-digital/lib/msk_timing_recovery_cc_impl.cc#L150
?
If you run the flowgraph again, can you put a tag_debug block on the
output of the corr_est block to dump out the values of the "time_est"
tag. I'm curious as to what value of "time_est" coming out of the
corr_est block may be tripping up the msk_timing_recovery_block.
-Andy
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
