discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] RFNoc and data rates


From: Marcus D. Leech
Subject: Re: [Discuss-gnuradio] RFNoc and data rates
Date: Thu, 24 Sep 2015 21:35:54 -0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0

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?

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.
Just looked at your flow-graph.  Looks OK to me, but at 100Msps, I imagine that your computer is working very, very hard.

Also, Gnu Radio doesn't have predictable latency, so trying to synchronize to your external Dicke-switching hardware will be a significant
  challenge.

Another approach, that Ken Tapping and I have used successfully, is what we call a differential radiometer:

http://www.sbrac.org/files/DTP_RX.pdf

This happens to use RTLSDR dongles, but the same approach of identical SDR RX chains providing full-time "sky" in one channel and
  "reference" in another eliminates the switching hardware, and the need to synchronize yourself with it....



reply via email to

[Prev in Thread] Current Thread [Next in Thread]