Re: [Discuss-gnuradio] RFNoc and data rates

[Marcus D. Leech]

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.