I am trying to combine the two sub device on a LFRX card, but I can not
find any documentation on the USRP dual source. GRC has it’s own block
“grc_usrp.dual_source_c”, but using this (configured with GRC) I get the
error:
TypeError: init() got an unexpected keyword argument ‘side_b’
How can this be overcome?
I am not able to find a dual source from the plain GR library, but it
may exist? However, I have tried to use two separate USRP sources and
specify separate sub devices on the two:
self.usrp_source_0a = usrp.source_c(0, 64) # Decimation factor: 64 #self.usrp_source_0a.db(0, 0) # Side A, sub device A
usrp.selected_subdev (self.usrp_source_0a, (0,0)) # Side A, sub device A
self.usrp_source_0a.set_rx_freq(0, 0) # Set frequency 0 Hz
self.usrp_source_0b = usrp.source_c(0, 64) # Decimation factor: 64 #self.usrp_source_0b.db(0, 1) # Side A, sub device B
usrp.selected_subdev (self.usrp_source_0b, (0,1)) # Side A, sub device B
self.usrp_source_0a.set_rx_freq(0, 0) # Set frequency 0 Hz
This however also fails. It seams the reason is that the USRP is already
taken by the first instance:
I am trying to combine the two sub device on a LFRX card, but I can not
find any documentation on the USRP dual source. GRC has it’s own block
“grc_usrp.dual_source_c”, but using this (configured with GRC) I get the
error:
TypeError: init() got an unexpected keyword argument ‘side_b’
Can you post the python code that GRC generated for the flow graph?
side_b is a keyword argument in init, I am afraid that you may have
multiple versions of gnuradio installed… What version of gnuradio are
you running?
How can this be overcome?
I am not able to find a dual source from the plain GR library, but it
may exist? However, I have tried to use two separate USRP sources and
specify separate sub devices on the two:
The USRP blocks in grc are special wrappers around the current usrp api
(to make life easier). You can use them in any custom flow graph. To
understand usage, I would take a look at the generated python code with
a usrp dual source.
You have to do something like, create one usrp source, create 2
subdevices, and deinterleave the usrp stream into 2 streams. See the
link posted above to get an idea.
What then is the correct way to receive on both sub devices on the same
time?
Einar
I Use 2 LFRX boards to get 4 channels (for only 2 channels you don’t
have to
do anything special as the default image handles that automatically) of
real
data each sampled at 2Msps. Here is the python code to do that. I think
you
are looking for the second line.
self.rx_src = usrp.source_c(fpga_filename=“std_4rx_0tx.rbf”)
rx_subdev = self.rx_src.db[0]+self.rx_src.db[1]
self.rx_src.set_mux(gru.hexint(0xf3f2f1f0)) #Sets all Q to zero
deinterleaver_usrp = gr.deinterleave(gr.sizeof_gr_complex)
self.connect(self.rx_src,skip_head_0,deinterleaver_usrp)
Real [(deinterleaver_usrp,0)] → SideAA
Real [(deinterleaver_usrp,1)] → SideAB
Real [(deinterleaver_usrp,2)] → SideBA
Real [(deinterleaver_usrp,3)] → SideBB
Can you post the python code that GRC generated for the flow graph?
The python code is attached to this e-mail. Is it possible to see the
problem from the python file?
side_b is a keyword argument in init, I am afraid that you may have
multiple versions of gnuradio installed… What version of gnuradio are
you running?
I did try to look around (and use “locate”) without finding several
parallel versions of GNU Radio installed. I went on deleting all GNU
Radio related in “/Library/Python/2.5/site-packages/” and
“/usr/local/share/” before reinstalling from the latest SVN revision
(10443).
I am not able to test with the USRP again until to morrow, so I can not
confirm whether or not this made any difference, but I did not see
anything that to me indicated several versions (I may be wrong).
You have to do something like, create one usrp source, create 2
subdevices, and deinterleave the usrp stream into 2 streams. See the
link posted above to get an idea.
I have read some of the files in the above URL, and will give doing it
manually a try to morrow if the problem with the dual-sink persists.
However I suspect that the dual source will be preferable if possible,
as it will be more readable and easy to implement.
Einar
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.