Hi all, I was just looking through the code in corr_est_cc_impl.cc because it is behaving unexpectedly and I think I have spotted a few bugs.
1) If you look at line 203 inside _set_threshold and line 240 inside work, the correlation output is being squared in both cases. The output of the correlation operation is already proportional to the voltage squared, so squaring it again makes it proportional to the fourth of voltage. These extra squares are likely a bug. I don't think this has a big effect on function, but it's not optimal and is extra calculations nonetheless. It is also the case that the phase_est and time_est values are being calculated on mag^4 data instead of mag^2 data. Because they are both monotonically increasing, again there is probably not a functional effect, but once again not optimal. 2) The peak value of the correlation peak is being reported as twice as big as they should be able to get, given a known input length with no noise added. For example, given a length 10 sequence which we correlate against, when they align perfect, you expect to see a peak value of 100 (1 or -1 times itself summed 10 times = 10 and then squared because of the current code implementation is 100). Yet, the peak values reported by the corr_start tag value are 200, which shouldn't be achievable. I can't figure out where this factor of two is being introduced in the code. 3) This may be intended, but doesn't feel right. When you look at the correlation output port (port 1), the values of the y-axis seem to have been square rooted, so that they appear to be in the range you would expect, though the corr_start tag shows the squared peak value that is proportional to the 4th of voltage. It's confusing and the fact that these two values are being sent to the user makes me think this is unintentional. 4) I have noticed that when I start my receiver first, with a power squelch gate up front, and then start my transmitter, the correlator places thousands of tags on the initial output of the squelch. While the input data is very low, the values of the mag^2 being reported in the corr_start tag value are very high, well above threshold. I don't know how this could happen. It's causing thousands of false tags to be placed in the stream that should not be there. I have not figured out anything concrete about this bug. It's possible it could be my setup, but I don't see how yet. This is an over the air test. I'm hoping the original block designers can provide some feedback that might help me understand what the intentions were. Thanks, Rich
_______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
