To expand on that, only a *hardware endpoint* or a *throttle* block makes any sample-rate notion actually "real" in the temporal sense.Put a throttle in the flowgraph after your signal source. When you aren't using real hardware as part of a flowgraph, you have to throttle the flowgraph or it will run as fast as possible and consume all available CPU.
--n
Nearly all of the blocks in Gnu Radio simply use any sample-rate parameter input to calculate internal parameters (for example, when calculating
filter coefficients, the sample rate is used to calculate the normalized-equivalent filter from the input parameters). Internal to a flow-graph,
Gnu Radio is entirely stream oriented, it has no inherent notions of samples rates -- everything is just a stream of samples that flow past
at whatever rate they flow past at, and block functions simply operate on whatever data they get, at whatever times they get that data.
The implication of that is that without either a throttle block, or actual hardware to "pace" samples at the expected temporal pace, things will
simply run flat-out.
Even the signal-source block, which takes a sample-rate input parameter, simply uses that parameter to calculate the internal phase accumulator
increments, it makes no attempt to actually supply samples at the desired rate.
On 01/09/2013 04:54 PM, José María Valencia wrote:
Why the scope sink window is freeze when I run this simulation (see the image) and some buttons are not visible?
<<...>>
_______________________________________________ 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
-- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org