usrp-users@lists.ettus.com
Discussion and technical support related to USRP, UHD, RFNoC
View all threadsUHD Announcement - March 18th 2011
Hello list,
New code has been pushed to master and new images have been uploaded.
This effects USRP2, USRP-N210, and USRP-E100.
http://www.ettus.com/downloads/uhd_images/UHD-images-most-recent/
E100 Users: expect a follow-up announcement for an updated kernel and
instructions.
-- Stability
The gr-uhd component is now part of the gnuradio master branch; the
gnuradio-master branch and the uhd master branch are now compatible.
At this point, we intend to keep the master branch of UHD stable. The
master branch will only be changed for bug fixes, and new hardware
support. Other than that, API and implementation code will not be changed.
After an initial trial period to discover bugs and provide fixes, we
plan to provide UHD installers for the various platforms (rpm, deb, exe).
-- New feature - second DDC in USRP2 and N210
The USRP2 and N210 now features a second receiver chain the FPGA. This
will allow one to simultaneously receive from daughterboards with
multiple subdevices (Ex: Basic-RX, TVRX2). Or, have two channels with
different frequency offsets on one subdevice. Both channels will have
the same sample rate.
To use the second receiver, set the appropriate RX subdevice
specification. For example, to get get subdevice A on channel 0 and
subdevice B on channel 1 on a BasicRX, use ":A :B". The behavior is
identical for anyone using multi channel UHD on a USRP1.
There is also a multi-channel receive example in uhd:
http://code.ettus.com/redmine/ettus/projects/uhd/repository/revisions/master/entry/host/examples/rx_multi_samples.cpp
-- New feature - jumbo frames with USRP2 and N210
After some refactoring of the buffering in the device, we have not only
freed additional block rams, but the internal buffering now supports
larger frames sizes up to 4K. In order to use jumbo frames, you must
have an ethernet card that supports the large frame size. Usually this
can be set with ifconfig <dev> mtu <size>
The default frame size will not exceed 2K unless the user overrides this
with special transport options:
http://www.ettus.com/uhd_docs/manual/html/transport.html#udp-transport-sockets
Testing and feedback is always welcome!
Thanks,
-Josh
Dear list,
I pulled my directory but I am unable to compile UHD. It errors me
3>....\lib\transport\libusb1_zero_copy.cpp(202) : error C2440: '=' : no
se puede realizar la conversión de 'void (__cdecl *)(libusb_transfer *)'
a 'libusb_transfer_cb_fn'
3> Esta conversión requiere reinterpret_cast, conversión de
estilo de C o conversión de estilo de función
which means
"unable to convert 'void (__cdecl *)(libusb_transfer *)' to
'libusb_transfer_cb_fn'. It requires a reinterpret_cast, C-style
conversion or function-style conversion"
Thanks for your help & patience.
Pol Henarejos
Research Engineer, MSc
pol.henarejos@cttc.es
Centre Tecnològic de Telecomunicacions de Catalunya (CTTC)
Engineering Unit
Parc Mediterrani de la Tecnologia
Av. Carl Friedrich Gauss, 7
08860 Castelldefels, Barcelona (Spain)
Tel: +34 93 396 71 70 Ext: 2177
Fax. +34 93 645 29 01
www.cttc.es
El 19/03/2011 1:36, Josh Blum escribió:
Hello list,
New code has been pushed to master and new images have been uploaded.
This effects USRP2, USRP-N210, and USRP-E100.
http://www.ettus.com/downloads/uhd_images/UHD-images-most-recent/
E100 Users: expect a follow-up announcement for an updated kernel and
instructions.
-- Stability
The gr-uhd component is now part of the gnuradio master branch; the
gnuradio-master branch and the uhd master branch are now compatible.
At this point, we intend to keep the master branch of UHD stable. The
master branch will only be changed for bug fixes, and new hardware
support. Other than that, API and implementation code will not be changed.
After an initial trial period to discover bugs and provide fixes, we
plan to provide UHD installers for the various platforms (rpm, deb, exe).
-- New feature - second DDC in USRP2 and N210
The USRP2 and N210 now features a second receiver chain the FPGA. This
will allow one to simultaneously receive from daughterboards with
multiple subdevices (Ex: Basic-RX, TVRX2). Or, have two channels with
different frequency offsets on one subdevice. Both channels will have
the same sample rate.
To use the second receiver, set the appropriate RX subdevice
specification. For example, to get get subdevice A on channel 0 and
subdevice B on channel 1 on a BasicRX, use ":A :B". The behavior is
identical for anyone using multi channel UHD on a USRP1.
There is also a multi-channel receive example in uhd:
http://code.ettus.com/redmine/ettus/projects/uhd/repository/revisions/master/entry/host/examples/rx_multi_samples.cpp
-- New feature - jumbo frames with USRP2 and N210
After some refactoring of the buffering in the device, we have not only
freed additional block rams, but the internal buffering now supports
larger frames sizes up to 4K. In order to use jumbo frames, you must
have an ethernet card that supports the large frame size. Usually this
can be set with ifconfig<dev> mtu<size>
The default frame size will not exceed 2K unless the user overrides this
with special transport options:
http://www.ettus.com/uhd_docs/manual/html/transport.html#udp-transport-sockets
Testing and feedback is always welcome!
Thanks,
-Josh
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
On 03/18/2011 08:36 PM, Josh Blum wrote:
Hello list,
New code has been pushed to master and new images have been uploaded.
This effects USRP2, USRP-N210, and USRP-E100.
http://www.ettus.com/downloads/uhd_images/UHD-images-most-recent/
E100 Users: expect a follow-up announcement for an updated kernel and
instructions.
I'm about to post a set of kernel modules and new kernel on the ettus
website. Before I do so, would someone like to do a quick test of them
for me?
Obviously, they work for me :)
Philip
-- Stability
The gr-uhd component is now part of the gnuradio master branch; the
gnuradio-master branch and the uhd master branch are now compatible.
At this point, we intend to keep the master branch of UHD stable. The
master branch will only be changed for bug fixes, and new hardware
support. Other than that, API and implementation code will not be changed.
After an initial trial period to discover bugs and provide fixes, we
plan to provide UHD installers for the various platforms (rpm, deb, exe).
-- New feature - second DDC in USRP2 and N210
The USRP2 and N210 now features a second receiver chain the FPGA. This
will allow one to simultaneously receive from daughterboards with
multiple subdevices (Ex: Basic-RX, TVRX2). Or, have two channels with
different frequency offsets on one subdevice. Both channels will have
the same sample rate.
To use the second receiver, set the appropriate RX subdevice
specification. For example, to get get subdevice A on channel 0 and
subdevice B on channel 1 on a BasicRX, use ":A :B". The behavior is
identical for anyone using multi channel UHD on a USRP1.
There is also a multi-channel receive example in uhd:
http://code.ettus.com/redmine/ettus/projects/uhd/repository/revisions/master/entry/host/examples/rx_multi_samples.cpp
-- New feature - jumbo frames with USRP2 and N210
After some refactoring of the buffering in the device, we have not only
freed additional block rams, but the internal buffering now supports
larger frames sizes up to 4K. In order to use jumbo frames, you must
have an ethernet card that supports the large frame size. Usually this
can be set with ifconfig<dev> mtu<size>
The default frame size will not exceed 2K unless the user overrides this
with special transport options:
http://www.ettus.com/uhd_docs/manual/html/transport.html#udp-transport-sockets
Testing and feedback is always welcome!
Thanks,
-Josh
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
On 03/21/2011 02:13 AM, Pol Henarejos wrote:
Dear list,
I pulled my directory but I am unable to compile UHD. It errors me
3>....\lib\transport\libusb1_zero_copy.cpp(202) : error C2440: '=' : no
se puede realizar la conversión de 'void (__cdecl *)(libusb_transfer *)'
a 'libusb_transfer_cb_fn'
3> Esta conversión requiere reinterpret_cast, conversión de
estilo de C o conversión de estilo de función
which means
"unable to convert 'void (__cdecl *)(libusb_transfer *)' to
'libusb_transfer_cb_fn'. It requires a reinterpret_cast, C-style
conversion or function-style conversion"
The function cast has been fixed. Pull the latest code to get the fix.
-Josh