On Fri, Jan 2, 2015 at 8:57 AM, Andy Walls <[email protected]> wrote:
> On Wed, 2014-12-31 at 15:48 -0500, Andy Walls wrote: > > On Wed, 2014-12-31 at 14:00 -0500, Andy Walls wrote: > > > Hi. > > > > > > Can someone give me a brief clue about the threshold testing in the > > > correlate_and_sync block? > > I found my answer in this post: > > https://gnuradio.org/redmine/projects/gnuradio/wiki/Hackfest1310 > > "The correlation peak is tested by first observing that the width of the > correlation peak will be sps number of samples wide. So we look at > sample i and sample (i-sps). If the difference between these two symbols > is greater than the threashold we calculated in the constructor, we > declare a correlation." > > That probably works for most preambles. > > Unfortunately it becomes a problem with the data sequence > "101010101010..." and a rectangular pulse filter, as the absolute value > (magnitude) peaks of the correlation increase somewhat linearly as the > sequences align, and there will be a peak at every sps samples. Thus > the threshold test won't trigger as expected. > > The correlation absolute value peak happens every sps samples because, > using NRZ bit mapping (0 => -1, 1 => 1), the positive correlation is > about as strong as the neighboring negative correlation that is sps > samples away. > > I'm not sure if I should file a bug report for this corner case or not. > > I'm writing my own correlator block based on the correlate_and_sync > block; except that it works on real, not complex, input samples. For > myself, I just use the unmodified output of the real valued correlation > filter and just set the threshold test to be relative to 0. Andy, Thanks for the reports and details. I can definitely see the problem with the situation you're describing. We obviously weren't considering that case when we designed the block. We were really expecting any preamble/access code that we were using would have good autocorrelation statistics. From that perspective, the 10101... pattern is pretty silly, but hey, it is used. Right now, you're probably best off redoing your own block as you say to deal with the specifics of your case. However, I'd like us to think about how we can abstract this concept within the current block so that we can more easily provide the behavior we'd like to see, such as the correlation and detection logic, and the filter design. I know Nick Foster has thoughts on this, too, with his work on GMSK signals. Tom > > > > > > Then in the work function (corr is a totally different array variable > > > here): > > > > > > // Calculate the correlation with the known symbol > > > d_filter->filter(noutput_items, in, corr); > > > > > > // Find the magnitude squared of the correlation > > > std::vector<float> corr_mag(noutput_items); > > > volk_32fc_magnitude_squared_32f(&corr_mag[0], corr, > noutput_items); > > > > > > int i = d_sps; > > > while(i < noutput_items) { > > > if((corr_mag[i] - corr_mag[i-d_sps]) > d_thresh) { > > > > > > This "if" test confuses me slightly. We check to see if the value of > > > the output of the matched filtering has crossed the threshold relative > > > to one symbol previous? Why not just check relative to 0? > > > > > > An additional note: The "if" test doesn't work too well, if the preamble > > sequence is "101010101010...", since then the correlation will have > > peaks at the symbol spacing, d_sps. Maybe > > > > if((corr_mag[i] - corr_mag[i-d_sps/2]) > d_thresh) { > > > > would be better, since the correlation should sag at the half symbol? > > Regards, > Andy > > > > _______________________________________________ > Discuss-gnuradio mailing list > [email protected] > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >
_______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
