Hi all,
I’m having some issues with the USRP and some latency in the output
signal. I am using a C++ program which modulates a signal and writes to
a file continuously.
When I use a normal file, the C++ program output looks perfect. When I
use a script made in GRC to read the C++ output file, the USRP generated
signal also looks perfect with an oscilloscope.
Now to get the process real-time, when I use mkfifo to tie the C++ and
GRC script together, I notice a problem. The C++ program constructs a
packet and then flushes and repeats continously. I’m sure this is less
than the 64KB buffer size with FIFOs. The GRC script reads from that
file and I see the signal output showing the modulated blocks, but I
notice it is not continuous and there seems to be 1-2 seconds of zero
signal, every 5 seconds or so.
I also see uU from the GRC script output about every 5 or so seconds.
Does anyone have any idea if this is a FIFO problem, or is it a USRP/GRC
issue? I am using a Duo core SU7300 laptop so I would think it should
run OK real-time unless the C++ and GRC script demand much more
processing power when used at the same time. Does anyone know any tricks
I can try?
Thanks,
Tom
I also see uU from the GRC script output about every 5 or so seconds.
Does anyone have any idea if this is a FIFO problem, or is it a
USRP/GRC issue? I am using a Duo core SU7300 laptop so I would think
it should run OK real-time unless the C++ and GRC script demand much
more processing power when used at the same time. Does anyone know
any tricks I can try?
The U printed means underflow, the host does not feed the USRP fast
enough. Sometimes enabling RT scheduling on the flow graph can help with
this.
-Josh
Josh…
Thanks, real time scheduling is enabled, and I run my python script with
sudo and I do not see the typical failure message saying real-time was
not enabled.
When I run the C++ program in one terminal and output the modulated
signal to a normal file, I can read that file in with my python script
and see the output on the USRP with no gaps like I was seeing before.
The problem is that this isn’t real-time and I am writing to a file with
the C++ program that grows with time. I did however not see any uU
underruns with the USRP so I am pretty sure the laptop can handle
running both the C++ and the python script at the same time.
I’m guessing its some type of buffer size issue. The C++ program flushes
packet by packet. When I run the C++ program and output to a fifo file
and do cat tempfifo.dat > check.dat, the check.dat shows none of that
latency or zero signal when I open it afterwards. Could it be that the
USRP or GRC script has a much smaller buffer size than the packet
generated by the C++ program?
Does anyone else have any ideas on what I should try?
Thanks-Tom
— On Mon, 3/28/11, Josh B. [email protected] wrote:
From: Josh B. [email protected]
Subject: Re: [Discuss-gnuradio] USRP Streaming Latency
To: [email protected]
Date: Monday, March 28, 2011, 8:54 PM
I also see uU from the GRC script output about every 5 or so seconds.
Does anyone have any idea if this is a FIFO problem, or is it a
USRP/GRC issue? I am using a Duo core SU7300 laptop so I would think
it should run OK real-time unless the C++ and GRC script demand much
more processing power when used at the same time. Does anyone know
any tricks I can try?
The U printed means underflow, the host does not feed the USRP fast
enough. Sometimes enabling RT scheduling on the flow graph can help with
this.
-Josh
On Mar 30, 2011, at 4:45 PM, Tom H. [email protected] wrote:
Does anyone else have any ideas on what I should try?
You might try profiling one or both apps or the system to see where
they’re spending time. I like RotateRight’s Zoom better than the free
ones I’ve tried.
-Marc