Send USRP-users mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of USRP-users digest..."
Today's Topics:
1. Re: UHD Announcement - March 18th 2011 (Pol Henarejos)
2. Re: UHD Announcement - March 18th 2011 (Philip Balister)
3. Re: [Discuss-gnuradio] Write registers on USRP2 FPGA
(Eduardo Lloret Fuentes)
4. Re: Basic grc application for the USRP N210 (Nishin Vasu)
5. Re: Regarding 10Mhz External Clock for USRP2 (abhinav anand)
----------------------------------------------------------------------
Message: 1
Date: Mon, 21 Mar 2011 10:13:02 +0100
From: Pol Henarejos <[email protected]>
To: [email protected]
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] UHD Announcement - March 18th 2011
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
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
[email protected]
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
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
Message: 2
Date: Mon, 21 Mar 2011 09:31:31 -0400
From: Philip Balister <[email protected]>
To: [email protected]
Cc: "[email protected]" <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [USRP-users] UHD Announcement - March 18th 2011
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
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
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Message: 3
Date: Mon, 21 Mar 2011 14:35:30 +0100
From: Eduardo Lloret Fuentes <[email protected]>
To: Nick Foster <[email protected]>
Cc: [email protected], discuss-gnuradio
<[email protected]>
Subject: Re: [USRP-users] [Discuss-gnuradio] Write registers on USRP2
FPGA
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
Hello,
Thanks for the info about those methods, they seem to be very useful for me.
You were right, what I am trying to write are the FPGA registers. But I mean
the registers of my own design. I added a module into the u2_rev3.v file and
I would like to modify the value of some registers of this design. I only
mentioned I2C and SPI standards because I thought they were usually used to
modify the registers values.
Now, another question comes to my mind. How could I get the 32-bit aligned
address of a register from the verilog code?
A lot of thanks for your help and time.
Edu.
2011/3/17 Nick Foster <[email protected]>
> On Thu, 2011-03-17 at 14:10 +0100, Eduardo Lloret Fuentes wrote:
> > Hello!
> >
> > I was successful trying to add my own FPGA code into the original FPGA
> > project. I just added a module into the u2_rev3.v and bypass the DSP
> > pipeline. So, all the original FPGA code is there and the firmware is
> > running. Now, I would like to modify some registers of my own FPGA
> > design. Maybe using the I2C or the SPI standards already implemented
> > via ethernet.
> >
> > I read that for the USRP there is a command, "usrper i2c_write
> > i2c_addr <hex-string>" that can be used to modify some existing
> > registers.
> >
> > Is there anything similar for USRP2?
> >
> > Is there any other way to modify an existing register (from the
> > original code) or a custom register (from my own code) via ethernet?
>
> There are peek32 and poke32, which are both methods in the USRP2 lib and
> are brought out to the Python interface. These allow you to read and
> write to FPGA registers. I assume you're not really trying to write I2C
> or SPI, but to write to FPGA registers -- if you want to access the I2C
> or SPI buses, you'll have to either modify the USRP2 firmware or use UHD
> and write some custom code.
>
> --n
>
> >
> > I would like to clarify that I am using the gnuradio master branch but
> > if there is a way to write these registers using the UHD driver it is
> > also quite interesting for me.
> >
> > A lot of thanks in advance.
> >
> > Eduardo.
> > _______________________________________________
> > Discuss-gnuradio mailing list
> > [email protected]
> > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20110321/9a9ef592/attachment-0001.html>
------------------------------
Message: 4
Date: Mon, 21 Mar 2011 23:15:57 +0800
From: Nishin Vasu <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Basic grc application for the USRP N210
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
************************************************************************************************************************
> UHD source block got error code 0x1
>
> output. We're marking it DONE
>
This is a timeout. Can you tell me what images you are using? And can
you post the output of examples/rx_timed_samples?
Prior to yesterday, these were the most recent images
http://www.ettus.com/downloads/uhd_images/UHD-images-002.20110122035832.cd5631f/
And most of the time when this happens, somebody is using older images,
and has a network card that rejects packets slightly over default MTU.
------------------------------
--------------------------------------------
Whatever the case, I strongly suggest you update to the most recent
images, uhd master branch, and gnuradio master branch.
http://www.ettus.com/downloads/uhd_images/UHD-images-most-recent/
-Josh
************************************************************************************************************************
Hello,
Thank you for the quick reply. The image I was using previously was an older
one(Dec 14th).
I updated the master branch for the GNU radio and the UHD like as you
suggested and
used the latest images for the UHD. I was not obtaining the error now.(
however not verified the
output of the GRC.)
I have also attached the output of the rx_timed_samples UHD example.
Thanks Again
Nishin,
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20110321/0e6884db/attachment-0001.html>
-------------- next part --------------
nishin@ubuntu:/usr/local/share/uhd/examples$ ./rx_timed_samples
linux; GNU C++ version 4.4.3; Boost_104000; UHD_003.20110306123542.7a949ff
Warning:
EnvironmentError: OSError: error in pthread_setschedparam
Failed to set thread priority 0.5 (realtime):
Performance may be negatively affected.
See the general application notes.
Creating the usrp device with: ...
mtu recv bytes 1472
mtu send bytes 1472
Making transport for DSP0...
Current recv sock buff size: 50000000 bytes
Making transport for DSP1...
Current recv sock buff size: 50000000 bytes
Making transport for ERR0...
mboard0 MIMO master
Warning:
EnvironmentError: OSError: error in pthread_setschedparam
Failed to set thread priority 0.5 (realtime):
Performance may be negatively affected.
See the general application notes.
Using Device: Single USRP:
Device: USRP2/N Series device
Mboard 0: USRP-N210 mboard
RX Channel: 0
RX DSP: USRP-N210 ddc0
RX Dboard: USRP-N210 dboard (rx unit)
RX Subdev: WBX (0x0053)
TX Channel: 0
TX DSP: USRP-N210 duc0
TX Dboard: USRP-N210 dboard (tx unit)
TX Subdev: WBX (0x0052)
Setting RX Rate: 6.250000 Msps...
Actual RX Rate: 6.250000 Msps...
Setting device timestamp to 0...
Begin streaming 10000 samples, 1.500000 seconds in the future...
Received packet: 362 samples, 1 full secs, 0.500000 frac secs
Received packet: 362 samples, 1 full secs, 0.500058 frac secs
Received packet: 362 samples, 1 full secs, 0.500116 frac secs
Received packet: 362 samples, 1 full secs, 0.500174 frac secs
Received packet: 362 samples, 1 full secs, 0.500232 frac secs
Received packet: 362 samples, 1 full secs, 0.500290 frac secs
Received packet: 362 samples, 1 full secs, 0.500348 frac secs
Received packet: 362 samples, 1 full secs, 0.500406 frac secs
Received packet: 362 samples, 1 full secs, 0.500464 frac secs
Received packet: 362 samples, 1 full secs, 0.500522 frac secs
Received packet: 362 samples, 1 full secs, 0.500580 frac secs
Received packet: 362 samples, 1 full secs, 0.500637 frac secs
Received packet: 362 samples, 1 full secs, 0.500695 frac secs
Received packet: 362 samples, 1 full secs, 0.500753 frac secs
Received packet: 362 samples, 1 full secs, 0.500811 frac secs
Received packet: 362 samples, 1 full secs, 0.500869 frac secs
Received packet: 362 samples, 1 full secs, 0.500927 frac secs
Received packet: 362 samples, 1 full secs, 0.500985 frac secs
Received packet: 362 samples, 1 full secs, 0.501043 frac secs
Received packet: 362 samples, 1 full secs, 0.501101 frac secs
Received packet: 362 samples, 1 full secs, 0.501159 frac secs
Received packet: 362 samples, 1 full secs, 0.501217 frac secs
Received packet: 362 samples, 1 full secs, 0.501275 frac secs
Received packet: 362 samples, 1 full secs, 0.501333 frac secs
Received packet: 362 samples, 1 full secs, 0.501390 frac secs
Received packet: 362 samples, 1 full secs, 0.501448 frac secs
Received packet: 362 samples, 1 full secs, 0.501506 frac secs
Received packet: 226 samples, 1 full secs, 0.501564 frac secs
Done!
------------------------------
Message: 5
Date: Mon, 21 Mar 2011 09:37:32 -0700
From: abhinav anand <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Regarding 10Mhz External Clock for USRP2
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
Hi Josh,
thanks for the pointer. I used below code to sync to external 10Mhz clock.
I see the LED-E is up now when I connect the 10Mhz clock. Is there anything
else left out to be set in the code??
<code snippet>
*
uhd::clock_config_t clock_config;
std::string args ("192.168.10.2");
uhd::device_addr_t dev_addr;
dev_addr["addr"] = args.c_str();
clock_config.ref_source = uhd::clock_config_t::REF_SMA;
clock_config.pps_source = uhd::clock_config_t::PPS_SMA;
clock_config.pps_polarity = uhd::clock_config_t::PPS_POS;
uhd::usrp::single_usrp::sptr dev = uhd::usrp::single_usrp::make(dev_addr);
dev->set_clock_config(clock_config, 0);
*
Thanks,
--
Abhinav
On Sat, Mar 19, 2011 at 10:35 AM, Josh Blum <[email protected]> wrote:
>
>
> On 03/19/2011 04:38 AM, abhinav anand wrote:
> > Hi Group,
> >
> > I am in a need of using a function generator to provide 10Mhz reference
> > clock to USRP2. I am using *standalone UHD*
> > with USRP2, and not the Gnuradio-UHD.
> >
> > I want to know how to *enable locking* in USRP2 to use 10Mhz external
> clock
> > instead of 100Mhz internal one.
> > Is there any python script to be executed or any firmware change in UHD
> > required for the same ??
> >
> > Please suggest me a way to do it.
> >
>
> See
>
> http://www.ettus.com/uhd_docs/doxygen/html/classuhd_1_1usrp_1_1multi__usrp.html#aceddf575752fda1a8cc75513a1178fd9
>
>
> http://www.ettus.com/uhd_docs/doxygen/html/structuhd_1_1clock__config__t.html
>
> -Josh
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20110321/8ffe4e8c/attachment.html>
------------------------------
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
End of USRP-users Digest, Vol 7, Issue 35
*****************************************
