discuss-gnuradio
[Top][All Lists]
Advanced

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

Re: [Discuss-gnuradio] Ettus N210 GMSK 9600


From: Andy Walls
Subject: Re: [Discuss-gnuradio] Ettus N210 GMSK 9600
Date: Thu, 24 Mar 2016 19:26:25 -0400

                              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







reply via email to

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