Hi All, I am pretty confused with some of the changes to the corr_est_cc_impl.cc threshold detection algorithm.
Previously, in _set_threshold(), the zero-offset autocorrelation of the reference symbols was computed and scaled by the desired relative threshold when the correlation estimator is instantiated to provide a fixed (constant for the run) threshold (d_thresh). That makes sense to me and appeared to work pretty well. Now, in _set_threshold(), a XXXX is calculated as d_pfa = -logf(1.0f - threshold) . In the work function, the detection threshold is calculated anew on each invocation as the mean value of the square of the current correlation of the reference symbols with the input symbols, scaled by d_pfa. How can the threshold for detecting the peak of the correlation against the reference symbols be a function of the input symbols? I know that using an absolute threshold based on only the reference symbols may be a problem because you can’t know the magnitude of the received input symbols, but I think that’s why there is a block callback for set_threshold(). The net result is that when one runs the correlation estimator, a bunch of peaks are output in the vicinity of the sync sequence in the input stream. The test_corr_est.grc example in gr-digital shows this well. I checked the commit history and the only relevant comment is “Works with arbitrary scaling”. This suggests that the changes are meant to include in the threshold the effect of arbitrary input signal power, which does make some sense. Again, I thought that was why there was a callback, but even that is clunky and I could be wrong. Anyway, all I know is that the correlation estimator used to work really well for me and is now, in my applications, broken badly. Maybe I’m not setting it up correctly, but AFAIK the block parameters are the same. Thanks for your consideration of this question, steven Steven Knudsen, Ph.D., P.Eng. www. techconficio.ca www.linkedin.com/in/knudstevenknudsen All the wires are cut, my friends Live beyond the severed ends. Louis MacNeice
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
