Hello,
I am am new to the gnuradio system and I have a USRP1 board running
gnuradio-3.0.2 (I have a box that was setup with this older version).
I modified the usrp_oscope.py and scopesink.py code to run without the
gui
(files attached). I then decided to measure the time taken to retrieve a
message from the msgq. I find that the time taken (at a decimrate of
256,
128, or 64) to get a single msg from the msgq (using msgq.delete_head())
to be anywhere between 30 - 60ms. This seems to be particularly high. I
do
have USB 2.0 on my machine. I also tried this with different fusb_nlocks
and fusb_block_size params but I still get the same delay.
I have looked at the mailing list archive and I haven’t really a post
with
the same issue.
Would anybody know why I might be seeing this error?
thanks,
Rohan
On Fri, Dec 5, 2008 at 12:22 AM, Rohan Narayana Murty
[email protected] wrote:
I am am new to the gnuradio system and I have a USRP1 board running
gnuradio-3.0.2 (I have a box that was setup with this older version).
There are numerous identified bugs in this release that have been
fixed along the way. If possible, I’d recommend upgrading to the
latest stable release, 3.1.3.
I modified the usrp_oscope.py and scopesink.py code to run without the gui
(files attached). I then decided to measure the time taken to retrieve a
message from the msgq. I find that the time taken (at a decimrate of 256,
128, or 64) to get a single msg from the msgq (using msgq.delete_head()) to
be anywhere between 30 - 60ms. This seems to be particularly high. I do have
USB 2.0 on my machine. I also tried this with different fusb_nlocks and
fusb_block_size params but I still get the same delay.
This is not an error. The flowgraph generates FFT vectors by default
at 15 frames per second. This is every 66 ms. Depending on whether
one is already in the message queue when you query it, you will get a
delay up to this amount of time.
-Johnathan