USRP2 UHD Matlab Receiver Communications Blockset

Hi,

I stumbled on this blockset on the Matlab website:

http://www.mathworks.com/help/toolbox/commblks/ref/usrp2receiver.html

I’ve been making do with the old firmware and fpga, but when I saw this
link, I
became really excited - especially because it implies I can decrease the
decimation on my USRP2 to 1 - perhaps by requesting real, single
precision
values instead of complex doubles.

Is there an open source version of that blockset?

Alternatively, despite poking around the UHD API, it wasn’t immediately
obvious
how I could change the type of data, or set a decimation of 1, from the
uhd::usrp::simple_usrp class. I suspect it may have something to do with
the
uhd::io_type_t class, but, again, I’m not too sure.

Has anyone had a chance to play around with this blockset, or know how
it works?
It looks really neat, and appears to work with wbx boards.

Vincent W

On 09/09/2010 06:43 PM, Vincent W wrote:

The minimum sustainable sample rate over the wire is 25Msps for the UHD
(unless you change FPGA implementation). I dont know what FPGA code
“they” are using. Also, I dont think these simulink blocks have UHD
under the hood.

Is there an open source version of that blockset?

Alternatively, despite poking around the UHD API, it wasn’t immediately obvious
how I could change the type of data, or set a decimation of 1, from the
uhd::usrp::simple_usrp class. I suspect it may have something to do with the
uhd::io_type_t class, but, again, I’m not too sure.

The device::send and device::recv calls take the IO type as an argument.
The samples are converted between IO type and over-the-wire type in the
UHD implementation code.

-Josh

On 09/10/2010 12:55 AM, Josh B. wrote:

values instead of complex doubles.
uhd::io_type_t class, but, again, I’m not too sure.

The device::send and device::recv calls take the IO type as an argument. The
samples are converted between IO type and over-the-wire type in the UHD
implementation code.

-Josh

Hi,

It seems very likely that they do have uhd implimentation, if only
judging by
the support articles they’ve written about the usrp2, albeit with
outdated
firmware and fpga images:

http://www.mathworks.com/support/solutions/en/data/1-CUN7JZ/index.html?product=CB&solution=1-CUN7JZ

http://www.mathworks.com/support/solutions/en/data/1-D2KBPZ/index.html?product=CB&solution=1-D2KBPZ

So, to be clear then, it’s not possible to get 1x decimation, or change
the
output type, using the resourced above?

Vincent

On 09/10/2010 12:55 AM, Josh B. wrote:

became really excited - especially because it implies I can decrease the
Alternatively, despite poking around the UHD API, it wasn’t immediately obvious
how I could change the type of data, or set a decimation of 1, from the
uhd::usrp::simple_usrp class. I suspect it may have something to do with the
uhd::io_type_t class, but, again, I’m not too sure.

The device::send and device::recv calls take the IO type as an argument. The
samples are converted between IO type and over-the-wire type in the UHD
implementation code.

-Josh

I stand corrected; it seems like they are using the udp drivers, as
opposed to
the uhd drivers.

My bad.

vvv

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