File source woes

I’m attempting to write a script, based on
usrp_fft.py, that will read a file of gr_complex and
display it. It works, except that it plays back much
faster than it was recorded. For example, I recorded
a five second file and gave it to my script. It
looked to be correct data, but it finished playback in
less than a second. Here’s the essential code:

self.input = gr.file_source(gr.sizeof_gr_complex,
options.filename, options.loop)

adc_freq = 64e6 #inherent to USRP
decim_rate = float(options.decim) #whatever decimation
rate used in recording

input_rate = adc_freq / decim_rate

self.scope = fftsink.fft_sink_c(self, panel,
fft_size=1024, sample_rate=input_rate)

self.connect(self.input, self.scope)

self._build_gui(vbox)


Any help would be greatly appreciated.

John B.


TV dinner still cooling?
Check out “Tonight’s Picks” on Yahoo! TV.
http://tv.yahoo.com/

John B. wrote:

I’m attempting to write a script, based on
usrp_fft.py, that will read a file of gr_complex and
display it. It works, except that it plays back much
faster than it was recorded.

Insert a gr.throttle() instance after the file source to reduce the
stream item rate.

throttle = gr.throttle(itemsize, items_per_second)


Johnathan C.
Corgan Enterprises LLC
http://corganenterprises.com

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

There is a gr_throttle block that you can use to rate-limit your data. I
think the only rate-limiting going on here is CPU time.

  • -Dan

John B. wrote:


TV dinner still cooling?
Check out “Tonight’s Picks” on Yahoo! TV.
http://tv.yahoo.com/


Discuss-gnuradio mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGjTYUy9GYuuMoUJ4RAtmXAKCZ5DF9IoFsySeGQnCqVrfvu+5uQACgvvLE
4PanFN6JXiX5Bi56H/MrYYg=
=nCEo
-----END PGP SIGNATURE-----

Dan H. wrote:

There is a gr_throttle block that you can use to rate-limit your data. I
think the only rate-limiting going on here is CPU time.

Correct. The GNU Radio runtime scheduler will always execute signal
processing blocks at the fastest rate possible given data availability.
With “real” sources like the USRP, the flowgraph usually becomes
rate-limited by the data production rate of the USRP. Sometimes it’s
the data sink that does the rate limiting, like an audio sink.

In the OP’s flowgraph, there is nothing holding up the scheduler other
than the hosts CPU speed, memory bandwidth, or hard disk controller.


Johnathan C.
Corgan Enterprises LLC
http://corganenterprises.com

Well, that was easy. Thanks guys!

John

— Johnathan C. [email protected]
wrote:

source to reduce the
stream item rate.

throttle = gr.throttle(itemsize, items_per_second)


Johnathan C.
Corgan Enterprises LLC
http://corganenterprises.com


Be a better Globetrotter. Get better travel answers from someone who
knows. Yahoo! Answers - Check it out.
http://answers.yahoo.com/dir/?link=list&sid=396545469

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs