On 09/24/2015 06:37 PM, Simon Olvhammar wrote:
Yes, in my current Python Gnuradio application I have implemented
Dicke-switching by syncing it with external signals that indicate S/R
as well as transition state of RF. I have not seen any issues with
overlapping fft:s. The switch frequency is 1 Hz and the transition
state signal has an interval of perhaps 100us where no storing of ffts
is done.
I'm still very new to signal processing and I'm having trouble to
understand the relation between alpha and how much is averaged, I just
see a scale factor in the transfer function? 0.01 seconds seems quite
alot and to reduce this to 0.001 seconds I could perhaps choose
alpha=0.1 and N=10 if I'm understanding you right? Are we talking same
delay times if I were to implement this is my current non FPGA
gnuradio app?
You can chose the latency tradeoffs yourself. If you want data
delivered to the host faster, you'd likely choose a shorter integration
time, by playing with alpha values.
But if your Dicke-switching time is on the order of 1s, then you could
discard several FFT frames and still have very-high-quality data.
There's also a technique called "oblivious synchronous detection"
developed by Ken Tapping at DRAO, and I did an implementation of it in
my gr-ra_blocks package. If the difference between "sky" and
"reference" is more than a few dB, then you can just take buffers of data
and "sort them into their houses" (ref or sky) by "slicing" based on
the distinct populations of samples, without having to worry about
strict synchronization with your (external) switching source--the
samples themselves tell you what "house" they belong in.
I have attached a flowgraph and it would be greatly appreciated if you
could check if it looks right for the purpose of just storing averaged
FFT:s.
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
