Re: [Discuss-gnuradio] RFNoc and data rates

[mleech]

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