Re: [Discuss-gnuradio] RFNoc and data rates

[Marcus D. Leech]

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.
>
> Could you elaborate on the internal precision that you mentioned?
> We are looking for a simple block that could do sum(FFT:s)/(Number of 
> FFT:s) element-wise and output this as as stream. For example a input 
> of 1000 FFT:s with 4096 channels will result in a output of 1 averaged 
> FFT with 4096 channels. I dont think we would need a iir filter for this?
A single-pole IIR is often used as a cheap way to perform integration--I 
use them all the time in radio astronomy processing.

> Regarding stream decimation block, if it makes one item out of n items 
> then what kind of processing is performed on those items? A simple 
> average sum(items)/numItems or something else? Maybe it's this block 
> that i'm looking for.
It just keeps 1 in N of the samples/vectors that are presented to it, 
without further processing.  All this DSP stuff is modular, so that
  a single-pole-IIR block does *only* that--it doesn't then also 
decimate the resulting stream/vector to a lower sample rate.  So, you'd:

[Caveat: I'm not an RFNoC person (yet), but the flow described below can 
be mapped onto existing RFNoC blocks as far as I know]:

Radio-->FFT--->complex-to-mag---->single-pole-IIR--->keep-one-in-N

The precision requirements come in when considering the single-pole-IIR 
filter, which has a feedback term, so imprecision can accumulate.
  However, if you "split the work" of long-term integration between the 
host and the FPGA, you can integrate over shorter periods in
  the FPGA, retaining precision, and then do bulk, long-term, 
integration on the host, and the host only has to process averaged FFT
  results at a *much, much* lower rate than the raw sample-rate would 
imply.   One would have to experiment with parameters to
  achieve the desired results, but with the bulk of your long-term 
integration happening on the host, you shouldn't need to worry
  that much about precision issues, I would think.    The RFNoC block 
*implementation team* could perhaps comment.


> Best regards
> Simon
>
>
>
> Den 2015-09-23 kl. 10:10, skrev Sylvain Munaut:
> > Hi,
> >
> > > > My question is, is this possible using current RFnoc blocks?, with for
> > > > example an average block?
> > One thing worth considering is the internal precision.
> >
> > I'm not familiar with the requirement for RA but I assume if you do a
> > lot of averaging it's to get rid of the noise and dig out very weak
> > signals.
> > The current average block might not have enough internal precision for
> > your needs and might need to be tweaked a bit.
> >
> >
> > > > Also wondering if a 8k channel FFT block might be expected in RFNoc
> > > > anytime soon?
> > Most of the blocks currently assume that 1 vector / fft size = 1
> > packet. And packets have to fit within the MTU, so with 4 bytes per
> > sc16 sample, that's 2048 which is the current limit. And I think even
> > the internal RFNoC fifos are sized with this MTU size in mind.
> >
> > So for larger FFTs you'll need other mechanism to synchonize the FFT
> > boundaries, like the EOB flag.
> >
> > Cheers,
> >
> >    Sylvain
> >
> > _______________________________________________
> > 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