[Top][All Lists]

[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

Tom Golden

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:

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.


reply via email to

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