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.
Den 2015-09-24 kl. 16:24, skrev mle...@ripnet.com:
Since you'd be decimating on the FPGA, your latency would be dominated
by the rate at which you send FFTs to the host. In the scenario
descibed, that would be about 0.01second, plus the inherent group
delay of the filters in the radio, which if you're running at full ADC
bandwidth won't be much.
Define "instantaneous". Are you switching between "sky" and
"reference", and want to be sure that you have no cross-contamination
between the two virtual "channels"? You'll always have *some*. When
I've done similar things, I always discard some samples during the
switching interval, because both analog and digital bits and pieces
make samples delivered during that time ambiguous.
On 2015-09-24 03:48, Simon Olvhammar wrote:
Thanks!
One concern that I have however is how the iir filter will affect delays in the
flow graph. In the current (non RFNoC) application; when I switch the input RF
to another source I would like to to see an almost instantaneous change in the
samples of the file sink. Which I pretty much do right now with all averaging
done in python. Could the iir filter affect this aspect? What delay time could
I expect from the x310:s A/D converter down to file sink?
Simon
On 09/24/2015 02:14 AM, Marcus D. Leech wrote:
On 09/23/2015 06:13 PM, Simon Olvhammar wrote:
What would be a good choice for N in this case? However, this seems
very promising and I thank you for your help! Cheers Simon
Whatever rate you're comfortable receiving integrated FFTs at. You'd
adjust the 'alpha' value for the IIR filter and N appropriately.
Let's say you're running the FFT input at full bandwidth--200Msps,
and you have an FFT size of 2048. That's 97.7e3 FFTs/second being
produced in the FFT machinery in RFNoC, including the complex-to-mag
part. Run that through a single-pole-IIR filter with an alpha value
of, let's say, 0.01 (or the integer/fixed-point equivalent). Then
set your 'N' in keep-one-in-N to be about 100. You'll get roughly
97.7e1 FFTs/second into your host instead of 97.7e3 FFTs/second. At
those low rates, even a purely-Python-based secondary long-term
integrator should be able to keep up just fine.
On 09/23/2015 11:40 PM, Marcus D. Leech wrote:
On 09/23/2015 04:19 PM, Simon Olvhammar wrote:
Hi Marcus, No, we also have some spectrometers for atmospheric
measurements. Regarding the keep 1 in N. It occurs to me then
that by using this I would loose (N-1)/N percent of the FFT data
for a given amount of observation time? Or am I missing
something? Simon
Since you're integrating prior to decimation here, there should be
no loss of information.
Den 2015-09-23 kl. 21:40, skrev Marcus D. Leech:
On 09/23/2015 03:06 PM, Marcus D. Leech wrote:
On 09/23/2015 02:49 PM, Simon Olvhammar wrote:
Hello, Thank you for your answers. Yes we do alot of averaging
to expose the signal, in some applications we even average
over several months.
Are these astronomical spectral features? They usually aren't
that wide, even with doppler spreading.
_______________________________________________ Discuss-gnuradio
mailing list Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________ Discuss-gnuradio
mailing list Discuss-gnuradio@gnu.org
<mailto:Discuss-gnuradio@gnu.org>
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________ Discuss-gnuradio
mailing list Discuss-gnuradio@gnu.org
<mailto:Discuss-gnuradio@gnu.org>
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________ Discuss-gnuradio
mailing list Discuss-gnuradio@gnu.org
<mailto:Discuss-gnuradio@gnu.org>
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________ Discuss-gnuradio
mailing list Discuss-gnuradio@gnu.org
<mailto:Discuss-gnuradio@gnu.org>
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org <mailto:Discuss-gnuradio@gnu.org>
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
