Gr.file_sink() or connect() limitations?


#1

Below is a short GNU Radio pipeline. Its purpose is to write an impulse
response to a character device node representing an FPGA (which contains
a
4-coefficient lowpass filter), read the FPGA’s output, and store said
output
in a file.

#!/usr/bin/env python

from gnuradio import gr, gru, eng_notation, optfir
from gnuradio import blks
from gnuradio.eng_option import eng_option
import sys
#import math

class filter_impulse_test (gr.flow_graph):

def __init__(self):
    gr.flow_graph.__init__(self)

    # build graph

    zeroes = [0 for i in range(20)]
    impulse = [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0,

0, 0, 0]
impulse.extend(zeroes)

    src = gr.vector_source_f(impulse, 0)

    FPGA_OUT = gr.file_source(gr.sizeof_float, "/dev/MQP_Pipe")

    FPGA_IN = gr.file_sink(gr.sizeof_float, "/dev/MQP_Pipe")

    scale = gr.multiply_const_ff(1.0/65535.0)

    head = gr.head(gr.sizeof_float, 1016)

    # file as final sink
    file_sink = gr.file_sink(gr.sizeof_float, 

“./FPGA_impulse_test.dat”)

    # now wire it all together
    # WILL NOT WORK SIMULTANEOUSLY. This is resolved in a later 

update
with os.fork().
# This version is used for debugging reading from/writing to the
FPGA individually.
# Comment out the first self.connect() to read, and the second
to
write.

    self.connect (src, FPGA_IN)
    self.connect (FPGA_OUT, file_sink) #Removed 'scale' and 'head'

blocks to ensure they were not
#interfering with
the
file IO.

if name == ‘main’:
fg = filter_impulse_test()
try:
fg.run()
except KeyboardInterrupt:
pass


The pipeline, however, just creates a file and doesn’t write to it,
leaving
a file of 0 bytes. I can confirm that the FPGA is working properly, and
that
GNU Radio is writing properly and making requests to read properly given
the
FPGA driver debugger’s output (screenshots included in this post). The
data
is just not getting from the FPGA to its final destination properly. The
pipeline functioned properly with an earlier version of the driver
(which
did not support simultaneous read/write). While driver help isn’t the
primary focus of this mailing list, I’m fairly confident that portion of
this demo is functioning properly. I was wondering if there were any
limitations to the file_sink processing block that I’m unaware of…

At least, it’d be appreciated if someone could point me to the code for
gr.file_sink() itself. I get lost in the mass of processing blocks that
make
use of it when I try to search for it, and can’t find the file_sink()
block
itself.

~ Francesco

http://www.nabble.com/file/p22366939/writing.PNG writing.PNG

http://www.nabble.com/file/p22366939/reading.PNG reading.PNG

View this message in context:
http://www.nabble.com/gr.file_sink()-or-connect()-limitations--tp22366939p22366939.html
Sent from the GnuRadio mailing list archive at Nabble.com.


#2

On Thu, Mar 05, 2009 at 10:35:37PM -0800, Francesco B. wrote:

Below is a short GNU Radio pipeline. Its purpose is to write an impulse
response to a character device node representing an FPGA (which contains a
4-coefficient lowpass filter), read the FPGA’s output, and store said output
in a file.

FWIW, the comment about os.fork() concerns me. If you are expecting
both parent and child to continue running GNU Radio code after
os.fork, you have a misunderstanding of our code, and possibly of fork
in general. (I’m not certain that this is what you’re trying to do,
but if it is, it won’t work.) There’s a bunch of shared state behind
the scenes that will end up “copy-on-write” after fork, leaving the
no-longer-shared state inconsistent. A standalone call to fork is
almost never the answer to any problem. If you’re trying to run an
external program from within python, consider using os.system or
os.popen.

At least, it’d be appreciated if someone could point me to the code for
gr.file_sink() itself. I get lost in the mass of processing blocks that make
use of it when I try to search for it, and can’t find the file_sink() block
itself.

Using common command line tools will allow you to find the source for
any block. E.g.,

$ find . -print | grep -v .svn | xargs grep -l file_sink

./gnuradio-core/src/lib/io/gr_file_sink.h
./gnuradio-core/src/lib/io/gr_file_sink_base.cc

The etags and/or ctags command are helpful too.

$ man ctags

Eric


#3

Thanks for the tip regarding fork(). I’ll use popen() instead. :slight_smile:

Still need to deal with the file_sink issue, though… fork() was only
an
idea for later. Will investigate this further.

~ Francesco

Eric B. wrote:

FWIW, the comment about os.fork() concerns me. If you are expecting

At least, it’d be appreciated if someone could point me to the code for


Discuss-gnuradio mailing list
removed_email_address@domain.invalid
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio


View this message in context:
http://www.nabble.com/gr.file_sink()-or-connect()-limitations--tp22366939p22380157.html
Sent from the GnuRadio mailing list archive at Nabble.com.