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.
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 address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________
Discuss-gnuradio mailing list address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________
Discuss-gnuradio mailing list address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________
Discuss-gnuradio mailing list address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________
Discuss-gnuradio mailing list address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
|