Hey Dean, For what it’s worth, I’ve resorted to two hacks.
1) where the sum of consecutive correlation mag squared samples is compared to 4*detection, I’ve gone to 8*detection. With the block threshold set to 0.999999, this results in threshold levels (compared to the peak correlation value) of 32 to 78 %. 2) I added a variable to track the max cross-correlation magnitude for samples that exceed the 8*detection threshold. Then i compare those (peak) samples to that max/4 and those that are above, I let pass. I had to do the latter because I was seeing false correlations at the very end of my TDMA packets. I think they are due to the tx-to-rx transient I see with my B200mini. My thought is that the transient is slow (looks like a DC offset) and may create a false peak when part of it is convolved with the reference sync sequence. Anyway, implementing #2 made that problem go away. The other thought I have for my particular application is to disabled the Correlation Estimator (CE) when I know there will be no sync sequence. Since I have a TDMA system with a GPSDO/clock governing the slot scheme, I can generate an “enable” pulse from my MAC and use it to control the CE block. The big flaw with my approach in 1) and 2) is that I am not accounting for variable receive power such as you’d expect in a multi-radio TDMA system… first things first, though, gotta see packets received reliably under Tx constant power. Steven Knudsen, Ph.D., P.Eng. www. techconficio.ca www.linkedin.com/in/knudstevenknudsen Der entscheidende Augenblick der menschlichen Entwicklung ist immerwährend. Darum sind die revolutionären geistigen Bewegungen, welche alles Frühere für nichtig erklären, im Recht, denn es ist noch nichts geschehen. - Franz Kafka > On Oct 4, 2016, at 13:31, devin kelly <dwwke...@gmail.com> wrote: > > Steven, > > I've had the exact same problem as you - my flowgraphs from 3.7.9 worked well > but now I'm getting a lot of false detections from this block. > > Is this really how this block is supposed to perform? We just have to use > trial and error to find the right threshold? > > Thanks For Any Help, > Devin > > > On Tue, Sep 27, 2016 at 11:37 AM, Steven Knudsen <ee.k...@gmail.com > <mailto:ee.k...@gmail.com>> wrote: > Alright, after some more thought I believe I understand what is going on. > > By looking at the cross-correlation power for the current input samples, the > threshold can be calculated as a desired false alarm rate. An “arbitrary” > threshold can be set independently of the received signal power. > > Unfortunately, for the test_corr_est.grc example, you just can’t set the > threshold high enough to avoid false alarms. I tried the CE block with up to > 0.999999 for the threshold and it was still a mess, though much better. > > That said, for my own application/flowgraph, setting the CE block threshold > to 0.9999 appears to work. I can set as “low” as 0.999, but that’s it. > > This makes me wonder why bother to have a threshold parameter at all? Maybe > just set the calculated d_pfa value to 10 or something and be done with it. > Of course, we all hate magic numbers, and so doing would introduce a second > number to the algorithm (the first is a multiplier of 4 in the peak > thresholding logic). > > Thanks for your patience… > > > Steven Knudsen, Ph.D., P.Eng. > www. techconficio.ca <http://techconficio.ca/> > www.linkedin.com/in/knudstevenknudsen > <http://www.linkedin.com/in/knudstevenknudsen> > > Von einem gewissen Punkt an gibt es keine Rückkehr mehr. Dieser Punkt ist zu > erreichen. - Franz Kafka > >> Begin forwarded message: >> >> From: Steven Knudsen <ee.k...@gmail.com <mailto:ee.k...@gmail.com>> >> Subject: Correlation Estimator in 3.7.10 >> Date: September 27, 2016 at 07:40:17 MDT >> To: GNURadio Discussion List <discuss-gnuradio@gnu.org >> <mailto:discuss-gnuradio@gnu.org>> >> Cc: Knud <k...@ieee.org <mailto:k...@ieee.org>> >> >> 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 <http://techconficio.ca/> >> www.linkedin.com/in/knudstevenknudsen >> <http://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 <mailto:Discuss-gnuradio@gnu.org> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > <https://lists.gnu.org/mailman/listinfo/discuss-gnuradio> > >
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
