Forum: GNU Radio Problems with 2 RX

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Albert Rodriguez (Guest)
on 2007-05-09 15:03
(Received via mailing list)
Hi everyone!
We're trying to receive two signals from two different RFX2400 in the
same USRP. We've already read everything about setting the rx mux and
the n_channels. However, we still cannot receive the two signals
correctly.
When we put signal in the first Rx1 (that goes to one RFX2400), we can
see it, but we cannot see the other in Rx2 (to the other RFX2400),
it's like it hasn't any kind of input signal. I add the code. We don't
know if it's a problem of the deinterleave, or the mux. Thanks in
advance

class my_graph(stdgui.gui_flow_graph):

    def __init__(self,frame,panel,vbox,argv):
   stdgui.gui_flow_graph.__init__ (self,frame,panel,vbox,argv)

  sample_rate = 320000
  freq = 2450000000
  usrp_decim = 200
  decim = 10
#USRP
  src = usrp.source_c(0, usrp_decim, fpga_filename="std_2rxhb_2tx.rbf")
  src.set_mux(gru.hexint(0x32103210))
  src.set_nchannels(2)
  subdev_spec1 = (0,0)
  subdev_spec2 = (1,0)
  subdev1 = usrp.selected_subdev(src, subdev_spec1)
  subdev2 = usrp.selected_subdev(src, subdev_spec2)
  subdev1.set_auto_tr(True)
  subdev2.set_auto_tr(True)
  subdev1.select_rx_antenna('RX2')
  subdev2.select_rx_antenna('RX2')
  r=src.tune(0,subdev1,freq)
  r=src.tune(0,subdev2,freq)
  self.fft_1=fftsink.fft_sink_c(self,panel,0,10,50,sample_rate,512,2)
  self.fft_2=fftsink.fft_sink_c(self,panel,0,10,50,sample_rate,512,2)
  di=gr.deinterleave(gr.sizeof_gr_complex)
  fg = gr.flow_graph ()

  self.connect (src,di)
  self.connect ((di,0),self.fft_1)
  self.connect ((di,1),self.fft_2)
  self._build_gui(vbox)

    def _build_gui(self, vbox):

  vbox.Add(self.fft_1.win, 10, wx.EXPAND)
  vbox.Add(self.fft_2.win, 10, wx.EXPAND)

if __name__ == '__main__':
    app = stdgui.stdapp (my_graph, " ")
    app.MainLoop ()
Eric B. (Guest)
on 2007-05-09 20:08
(Received via mailing list)
On Wed, May 09, 2007 at 01:02:52PM +0200, Albert Rodriguez wrote:
>
>   src = usrp.source_c(0, usrp_decim, fpga_filename="std_2rxhb_2tx.rbf")
>   src.set_mux(gru.hexint(0x32103210))
>   src.set_nchannels(2)
>   subdev_spec1 = (0,0)
>   subdev_spec2 = (1,0)
>   subdev1 = usrp.selected_subdev(src, subdev_spec1)
>   subdev2 = usrp.selected_subdev(src, subdev_spec2)
>   subdev1.set_auto_tr(True)
>   subdev2.set_auto_tr(True)
>   subdev1.select_rx_antenna('RX2')
>   subdev2.select_rx_antenna('RX2')

These lines:

>   r=src.tune(0,subdev1,freq)
>   r=src.tune(0,subdev2,freq)

Should be:

>   r=src.tune(0,subdev1,freq)
>   r=src.tune(1,subdev2,freq)

BTW, checking the return value is always a good idea ;)
Dan H. (Guest)
on 2007-05-09 20:27
(Received via mailing list)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Eric B. wrote:
> On Wed, May 09, 2007 at 01:02:52PM +0200, Albert Rodriguez wrote:
>> We're trying to receive two signals from two different RFX2400 in the
>> same USRP. We've already read everything about setting the rx mux and
<snip>
> BTW, checking the return value is always a good idea ;)
Can you explain this? I was under the impression that the first
parameter to tune was which USRP board, and they're using the same USRP.

- -Dan
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGQfZfy9GYuuMoUJ4RAqlfAKDUJ5Ui9zfPgnjNr8DV1sZ+tyCpYACgl2Fm
6O24e/P7eJ4mbpoj6wAxUeY=
=FQnE
-----END PGP SIGNATURE-----
Dan H. (Guest)
on 2007-05-09 20:29
(Received via mailing list)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Dan H. wrote:
>
>>>   r=src.tune(0,subdev1,freq)
>>>   r=src.tune(1,subdev2,freq)
>> BTW, checking the return value is always a good idea ;)
>
> Can you explain this? I was under the impression that the first
> parameter to tune was which USRP board, and they're using the same USRP.

No, no, I'm an idiot. That's handled in usrp_source_c(...). Sorry.

- -Dan
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGQfaxy9GYuuMoUJ4RAucRAKDMfJ0DZvDorDV9JPGCbJJ7hzXBAgCgh5GO
vMubHKzc+E6wTnnpeVumzh0=
=lqR+
-----END PGP SIGNATURE-----
Eric B. (Guest)
on 2007-05-09 20:34
(Received via mailing list)
On Wed, May 09, 2007 at 09:27:11AM -0700, Dan H. wrote:
> > Should be:
> >
> >>   r=src.tune(0,subdev1,freq)
> >>   r=src.tune(1,subdev2,freq)
> >
> > BTW, checking the return value is always a good idea ;)
>
> Can you explain this? I was under the impression that the first
> parameter to tune was which USRP board, and they're using the same USRP.

The first parameter to the CONSTRUCTOR is the USRP board.
In the call to tune, the first parameter is the channel that we want
to tune (in the code below from usrp.py, u is effectively self.  Ignore
it.)



def tune(u, chan, subdev, target_freq):
    """
    Set the center frequency we're interested in.

    @param u: instance of usrp.source_* or usrp.sink_*
    @param chan: DDC/DUC channel
    @type  chan: int
    @param subdev: daughterboard subdevice
    @param target_freq: frequency in Hz
    @returns False if failure else tune_result

    Tuning is a two step process.  First we ask the front-end to
    tune as close to the desired frequency as it can.  Then we use
    the result of that operation and our target_frequency to
    determine the value for the digital down converter.
    """
This topic is locked and can not be replied to.