Hi Roman, On Wed, 2018-03-14 at 11:21 +0300, Roman wrote: > Marcus, many thanks again! > It seems that I am on the right way, at least with calculations. :)Lets > continue with your thought-provoking questions. > " Is your received signal real-valued?" No, I put the "complex-to-mag" block > before.
Wait, are we looking for variance of your signal, or variance of your signal's power? > Regarding the final goal.I would like to evaluate the channel characteristics > for the same bursty packet signal in channels with different propagation > characteristics.For example in environment with multipath propagation will > cause signal fading (at least, it should). I would like to evaluate how deep > the fading is by calculating the variance of the received signal level.Is it > a right approach? I'd argue you want to build a correlation receiver! > Or can you advise better alternatives of using gnuradio for such purpose? Yep, send a sequence (for example, a pseudorandom sequence in a signal source). In the receiver, correlate against that sequence. Since correlation is mathematically related to convolution, you can implement that correlation by employing a filter. As taps, use the conjugate complex time-reversed . If your sequence was real-valued to begin with, conjugation is a non-operation, and you can just use reversed() as filter taps. It's not uncommon for to just be a white alternation of -1 and +1. The output will be the correlation coefficient for every sample delay between receive signal and reference sequence. Since receive signal is (neglecting frequency offset, working in discrete domain, be sure you understand what that implies): with being the transmit signal and being the channel response. The output of the filter will hence be You can, if your finit was perfectly white, directly read the channel impulse response from that. The longe , the “whiter” it can get, and the better the SNR of your estimate becomes. However, choosing a is limited by the channel coherence (i.e. the inverse of doppler spread) and computational limits (but these are surprisingly OK, assuming highly accelerated filters like GNU Radio has them, and sufficiently fast PCs/laptops). Best regards, Marcus
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
