Piping to the USRP - mkfifo issue

GNU Radio
1

Hi

I am using a web
camera to get an MPEG-4 rtsp stream that is set to a constant bitrate. I
have a script which pipes the rtsp stream to a code in C++. The C++
code modulates the signal and writes a .WAV file to the hard disk.

I have a python script which interfaces with GNURadio/USRP which I
created using GRC. This takes a file stored on the hard disk and
outputs the analog waveform on the output of the USRP and I run this in
a
second terminal window.

Everything works on the transmitter side, except that I have a file that
is constantly increasing in size, and the USRP script starts from the
beginning of the file and plays for a certain time before stopping. If I
restart, it does it longer and longer each time as expected since the
file is increasing in size. I verified I have gotten an output on the
USRP using an oscilloscope and it looked fine.

I wanted to try and use piping with mkfifo.

When I erase the file that is written/read from with the couple of
scripts I have, I then use mkfifo temp.wav (where temp.wav is my .wav
file).

Then I start my scripts that pipe the camera output to the temp.wav
file. In a second terminal window I then run my USRP script and it
seems to open the file but I don’t get any output on the USRP.

Has anyone encountered this problem? I’m not sure what could be wrong,
but
it works with a normal file as I described above. Any suggestions?

Thanks for your help!

-Tom

2

On Sun, Mar 6, 2011 at 6:59 PM, Tom H. [email protected] wrote:

window.

Thanks for your help!
-Tom

Tom,
Look how piping to fifo files is handled in the gr-atsc. That might help
get
you going.

Tom

3

Thanks Tom,

I’m a beginner still with linux/GNURadio so I couldn’t really find any
information that makes sense as to how gr-atsc handles the fifo piping.

I had seen an example online of someone that had done a transmission
using the USRP and piping. They had piped the output of gstreamer using
mkfifo like I had tried but I can’t get any output on the USRP when I
read from the file created by mkfifo.

-Tom

— On Mon, 3/7/11, Tom R. [email protected] wrote:

From: Tom R. [email protected]
Subject: Re: [Discuss-gnuradio] Piping to the USRP - mkfifo issue
To: “Tom H.” [email protected]
Cc: [email protected]
Date: Monday, March 7, 2011, 12:53 AM

On Sun, Mar 6, 2011 at 6:59 PM, Tom H. [email protected] wrote:

Hi

I am using a web
camera to get an MPEG-4 rtsp stream that is set to a constant bitrate. I
have a script which pipes the rtsp stream to a code in C++. The C++
code modulates the signal and writes a .WAV file to the hard disk.

I have a python script which interfaces with GNURadio/USRP which I
created using GRC. This takes a file stored on the hard disk and
outputs the analog waveform on the output of the USRP and I run this in
a
second terminal window.

Everything works on the transmitter side, except that I have a file that
is constantly increasing in size, and the USRP script starts from the
beginning of the file and plays for a certain time before stopping. If I
restart, it does it longer and longer each time as expected since the
file is increasing in size. I verified I have gotten an output on the
USRP using an oscilloscope and it looked fine.

I wanted to try and use piping with mkfifo.

When I erase the file that is written/read from with the couple of
scripts I have, I then use mkfifo temp.wav (where temp.wav is my .wav
file).

Then I start my scripts that pipe the camera output to the temp.wav
file. In a second terminal window I then run my USRP script and it
seems to open the file but I don’t get any output on the USRP.

Has anyone encountered this problem? I’m not sure what could be wrong,
but
it works with a normal file as I described above. Any suggestions?

Thanks for your help!

-Tom

Tom,Look how piping to fifo files is handled in the gr-atsc. That might
help get you going.
Tom

4

On Mon, Mar 7, 2011 at 2:45 AM, Tom H. [email protected] wrote:

http://wiki.oz9aec.net/index.php/Simple_DVB_with_Gstreamer_and_GNU_Radio

-Tom

Hi tom,

Maybe the program you use for writing the video to the file uses some
operations that only work on regular files? You may compare it to
gnuradio/core/src/lib/io/gr_file_sink.cc which works well with named
pipes.
Also note that applications that use named pipes are frozen until both
ends
of the pipe are open. So if both applications are running then the “pipe
connection” should be OK and the problem could be data type mismatch or
something like that.

Alex

5

When I run “make” (after running ./configure), I get a series of errors.
The odd thing is that the error goes away or changes into something else
when I run “make” again.

Any ideas on what might be causing this? Or is it ok to re-run “make”
till it shows no errors.
I am reproducing the error message below.
Best regards,-Vijay

Creating library file: .libs/libgnuradio-core.dll.a
libtool: link: ( cd “.libs” && rm -f “libgnuradio-core.la” && ln -s
“…/libgnura
dio-core.la” “libgnuradio-core.la” )
/bin/sh …/…/…/libtool --tag=CXX --mode=link g++ -g -O2 -Wall
-Woverloaded-
virtual -no-undefined -version-info 0:0:0
“-Wl,–enable-runtime-pseudo-reloc”
-o libgnuradio-core-qa.la bug_work_around_6.lo filter/libfilter-qa.la
general/l
ibgeneral-qa.la runtime/libruntime-qa.la libgnuradio-core.la -lcppunit
-ldl -l
winmm
libtool: link: warning:
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../libfftw3f.la ' seems to be moved libtool: link: warning:/usr/lib/gcc/i686-pc-cygwin/3.4.4/…/…/…/libgsl.la’ s
eems to be moved
libtool: link: warning:
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../libgslcblas. la' seems to be moved libtool: link: warning:/usr/lib/gcc/i686-pc-cygwin/3.4.4/…/…/…/libblas.la’
seems to be moved
libtool: link: warning: -version-info/-version-number' is ignored for convenien ce libraries libtool: link: rm -fr .libs/libgnuradio-core-qa.a .libs/libgnuradio-core-qa.la libtool: link: (cd .libs/libgnuradio-core-qa.lax/libfilter-qa.a && ar x "/home/V ijay/gnuradio-3.3.0/gnuradio-core/src/lib/filter/.libs/libfilter-qa.a") ../../../libtool: line 977: 5916 Aborted ( cd $f_ex_an_ar_dir & & ar x "$f_ex_an_ar_oldlib" ) ../../../libtool: line 980: 4116 Aborted ( exit 134 ) make[5]: *** [libgnuradio-core-qa.la] Error 134 make[5]: Leaving directory/home/Vijay/gnuradio-3.3.0/gnuradio-core/src/lib’
make[4]: *** [all-recursive] Error 1
make[4]: Leaving directory
/home/Vijay/gnuradio-3.3.0/gnuradio-core/src/lib' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory/home/Vijay/gnuradio-3.3.0/gnuradio-core/src’
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory /home/Vijay/gnuradio-3.3.0/gnuradio-core' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory/home/Vijay/gnuradio-3.3.0’
make: *** [all] Error 2

6

Sorry for replying so late.

I’ve been using pipes with file sources and sinks.
One trick you have to do is start the consumer before the producer. For
some reason if the writing on the pipes starts before the reading,
things
get messed up.
Try starting the transmitter reading the pipe before you start the
process
that writes to the pipes. That did the trick for me.

Charles

7

See man 7 fifo on your local Linux system.

Normally, the sending-side will block until the reading-side has opened.

8 
transmission using the USRP and piping.  They had piped the output

Maybe the program you use for writing the video to the file uses some
operations that only work on regular files? You may compare it to
gnuradio/core/src/lib/io/gr_file_sink.cc which works well with named
pipes. Also note that applications that use named pipes are frozen
until both ends of the pipe are open. So if both applications are
running then the “pipe connection” should be OK and the problem could
be data type mismatch or something like that.

Alex

So, you have to make sure that your “producer” isn’t buffering really
large amounts of data. Also, stupid question, are you producer and
consumer processes both executing at the same time, and if so, how
are you arranging that?

9

On Fri, Jul 1, 2011 at 14:51, Marcus D. Leech [email protected] wrote:

Marcus L.
Principal Investigator
Shirleys Bay Radio Astronomy Consortiumhttp://www.sbrac.org

That’s what it should do.
But in practice, I’ve seen some blocks locking if their writes were
blocked. That’s why I suggested starting in this order.

Charles

10

That’s what it should do.
But in practice, I’ve seen some blocks locking if their writes were
blocked. That’s why I suggested starting in this order.

The other issue is that if you have multiple FIFOs, then the only
reliable mechanism for making it work is to have the reader open
non-blocking, since the opening-order in the reader doesn’t
necessarily correspond to the order in the writer. So you end up with
a kind of deadlock where neither process can make any progress.

–
Marcus L.
Principal Investigator
Shirleys Bay Radio Astronomy Consortium