Re: [Discuss-gnuradio] RFNoc and data rates

[Simon Olvhammar]

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?

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.

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