Forum: GNU Radio USRP2 for my Radio Astronomy stuff

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.
Marcus D. Leech (Guest)
on 2009-02-11 21:11
(Received via mailing list)
Well, I now have my first user with a USRP2.

So, what are the gotchas that are going to bite me when supporting USRP2
in code that's used to USRP1?

Setup seems a little different--only 1 TX and 1 RX channel, etc.


Here's my new setup_usrp() function:

def setup_usrp(self):

        if (self.usrp2 == False):
            if (self.dual_mode == False and self.interferometer ==
False):
                if (self.decim > 4):
                    self.u =
usrp.source_c(decim_rate=self.decim,fusb_block_size=8192)
                else:
                    self.u =
usrp.source_c(decim_rate=self.decim,fusb_block_size=8192,
fpga_filename="std_4rx_0tx.rbf")
                self.u.set_mux(usrp.determine_rx_mux_value(self.u,
self.rx_subdev_spec))
                # determine the daughterboard subdevice we're using
                self.subdev[0] = usrp.selected_subdev(self.u,
self.rx_subdev_spec)
                self.subdev[1] = self.subdev[0]
                self.cardtype = self.subdev[0].dbid()
            else:
                self.u=usrp.source_c(decim_rate=self.decim,
nchan=2,fusb_block_size=8192)
                self.subdev[0] = usrp.selected_subdev(self.u, (0, 0))
                self.subdev[1] = usrp.selected_subdev(self.u, (1, 0))
                self.cardtype = self.subdev[0].dbid()
                self.u.set_mux(0x32103210)
                c1 = self.subdev[0].name()
                c2 = self.subdev[1].name()
                if (c1 != c2):
                    print "Must have identical cardtypes for --dual_mode
or --interferometer"
                    sys.exit(1)
                #
                # Set 8-bit mode
                #

                width = 8
                shift = 8
                format = self.u.make_format(width, shift)
                r = self.u.set_format(format)
        else:
            if (self.dual_mode == True or self.interferometer == True):
                print "Cannot use dual_mode or interferometer with
single USRP2"
                sys.exit(1)
            self.u = usrp2.source_32fc(self.interface, self.mac_addr)
            self.u.set_decim (self.decim)
            self.cardtype = self.u.daughterboard_id()

Also, is there a way to set 8-bit mode on USRP2?   Inquiring minds want
to know.

--
Marcus L.
Principal Investigator, Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org
Johnathan C. (Guest)
on 2009-02-11 21:19
(Received via mailing list)
On Wed, Feb 11, 2009 at 11:10 AM, Marcus D. Leech 
<removed_email_address@domain.invalid>
wrote:

> So, what are the gotchas that are going to bite me when supporting USRP2
> in code that's used to USRP1?
>
> Setup seems a little different--only 1 TX and 1 RX channel, etc.

Yes, it is simpler in this regard, no subdev, etc.

One significant change to consider is your sample rate plan--you now
have different ADC and DAC frequencies, so depending on what you're
doing, your integer decimation ratios may need to change.

The floating point source for the usrp1 has a range of [-32768.0
32767.0], while for the usrp2 it is automatically scaled to [-1.0
1.0].  This will affect your front end range scaling or software AGCs.

> Also, is there a way to set 8-bit mode on USRP2?

Not yet.

Johnathan
Marcus D. Leech (Guest)
on 2009-02-11 21:26
(Received via mailing list)
Johnathan C. wrote:
>
> One significant change to consider is your sample rate plan--you now
> have different ADC and DAC frequencies, so depending on what you're
> doing, your integer decimation ratios may need to change.
>
That's not a problem.  I run at various bandwidths, depending on what
machine I'm running on, what I'm
  observing, etc.  I have a script that invokes the usrp_ra_receiver.py
code, and it can do the necessary
  calculations, etc.
> The floating point source for the usrp1 has a range of [-32768.0
> 32767.0], while for the usrp2 it is automatically scaled to [-1.0
> 1.0].  This will affect your front end range scaling or software AGCs.
>
>
Oh.  Is that done on the host side?  And, well, why?  [no criticism
here, just a little puzzled]
>
> Not yet.
>
>
>
Well, geez, Jonathan.   What's taking you?  :-) :-) :-)


--
Marcus L.
Principal Investigator, Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org
Johnathan C. (Guest)
on 2009-02-11 21:46
(Received via mailing list)
On Wed, Feb 11, 2009 at 11:25 AM, Marcus D. Leech 
<removed_email_address@domain.invalid>
wrote:

>> The floating point source for the usrp1 has a range of [-32768.0
>> 32767.0], while for the usrp2 it is automatically scaled to [-1.0
>> 1.0].  This will affect your front end range scaling or software AGCs.
>>
> Oh.  Is that done on the host side?  And, well, why?  [no criticism
> here, just a little puzzled]

Yes, on the host, as we convert from the raw wire format into the
format of the particular source or sink block chosen.

We decided to standardize the range of the sample streams into and out
of the USRP2, such that regardless of daughterboard, decim/interp
rates, etc., the maximum and minimum values in the floating point
domain would be [-1.0 1.0].  This simplifies the rest of the flowgraph
design.

We're not there yet.  On the TX side, we're compensating for variable
interpolation gain, but on the RX side, changing decimation ratios
still affects the signal range.  Neither have we worked out the
differences among daughterboards.  Right now if you TX at 1.0 with the
BasicTX or LFTX, you get the full DAC range output.

Someday we'll have predictable RF power to flowgraph value
calculations for both TX and RX (at least for the linear portion of
their ranges), subject only to manufacturing tolerances.  Then a
calibration step by the user can store a board-specific adjustment
factor in the board's EEPROM and we can automatically take this into
account.

Someday.

Johnathan
This topic is locked and can not be replied to.