|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|
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:
John, 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. Tom
|[Prev in Thread]||Current Thread||[Next in Thread]|