USRP2 source and receiving samples question

Hi,
I’m trying to write a module that works almost identical to the
usrp2_source_16sc module, but I’m having trouble with receiving the
samples. It seems my module is never satisfied with the amount of data
I send it, it just keeps polling for data in the background loop. What
I want to do is send a file, run it through a loopback on an external
hardware device, then read it back in on the host. Here is what my
code does:

self.asink = afpga.sink_raw(options.interface)
self.asrc = afpga.source_raw(options.interface)

self.input = gr.file_source(gr.sizeof_int,“in.txt”,0) #only send once
self.output = gr.file_sink(gr.sizeof_int,“out.txt”)

self.connect (self.input,self.asink)
self.connect (self.asrc, self.output)

#control stuff
tb.start()
raw_input(‘Press Enter to quit: \n’)
tb.stop()
tb.wait()

Pretty simple stuff. I the data loops back correctly and my handler
shows nsamples as correct, but my program never halts or writes the
samples to the file. It actually won’t even let me control-c my python
script. The only odd thing to me is that noutput_items for my work
function is 8162. Not sure how this value is set, but to me it should
be the number of samples.

Some output (file gets split up into two frames, one with 371 samples
and the second with 142):
work: noutput items 8162
data handler: len: 1512
rx_samples: want more
work: handled 371 samples

noutput items 8162
data handler: len: 596
rx_samples want more
work:handled 142 samples
poll for more samples forever…

Any ideas or a description on how the receive system works would be
much appreciated.

version 3.2.2
Ubuntu 9.04

Thanks,
Charles

Hi,
I made a lower level c++ implementation using the code from
rx_streaming_samples.cc in /usrp2/host/apps and manually put in a tx
before the receive portion and it works fine. It seems the issue is
related to noutput_items in my gr- module. As I stated above it uses
8162 for noutput_items for whatever reason and this is what is used to
define the maximum number of samples for the rx_nop_handler. The
reason the c++ one works is because the rx_nop_handler is created with
an nsamples value that is expected which lets has_finished_p() be
triggered. If I manually put in 8162 into the rx_nop_handler in the
c++ implementation I get the “never ending can’t even control-c have
to sudo kill the process” behavior as I was in the python
implementation. I’m not adept at the GNU Radio scheduler or this SWIG
stuff, so if anyone could give me some idea of how the number of
output items is determined or why my module is saying it needs 8162 I
would appreciate it.

Charles

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