[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] Simultaneously send data and store it in file wit

From: mleech
Subject: Re: [Discuss-gnuradio] Simultaneously send data and store it in file with high sample rate
Date: Mon, 25 Mar 2013 11:02:44 -0400
User-agent: Roundcube Webmail/0.7.2

To expand on this further.

The number of MFLOPS required is proportional to the sample-rate X inherent-flowgraph-complexity.

If, on average, there's a deficit in available MFLOPS vs required MFLOPs, you'll get overflows.  Buffering within the flow-graph, and the driver stacks, allows you to have short-term shortfalls, but if on average you don't have enough MFLOPs, you'll fall behind, and get overruns.  Think of it as a kind of "physics of computing" thing.

The more "stuff" you do in a flowgraph, the higher the inherent-flowgraph-complexity.  A digital receiver DSP chain is quite complex, and requires a *lot* of operations to be performed on every sample. The architecture of Gnu Radio exacerbates this somewhat, because the data-flow model tends to produce redundant data motion that would not occur in a signal-processing chain that was "hand coded" and "hand optimized".  It's the price you pay for the flexibility of the "plug a bunch of modules together" architecture.

That being said, I have flow-graphs that run at 16.67Msps, doing "stuff" and they keep up fairly well--but on a 6-core 3.2GHz machine with 4G of fast memory.



On 25 Mar 2013 10:36, Tom Rondeau wrote:


The ability to process data in a software radio application is
directly proportional to the sampling rate used. The higher the
sampling rate, the more computational power required. As you increase
the computational load on your application, each block takes longer to
process data, and at some point, your application can take too much
time, which means that the data flowing from the USRP to the host is
coming too fast to be processed, so it gets dropped.

A digital receiver is a complex set of algorithms used to properly
synchronize (in time, frequency, and phase not to mention any
multipath distortions) the incoming signal. This is much more complex
than just drawing the signal in a GUI.

So in other words, you shouldn't expect to be able to handle those
kinds of bandwidth with the digital receiver. Now, there's a lot more
optimization that can be done to make those algorithms more
computationally efficient in order to continue increasing the
potential symbol rate.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]