Send USRP-users mailing list submissions to
usrp-users@lists.ettus.com
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
usrp-users-requ...@lists.ettus.com
You can reach the person managing the list at
usrp-users-ow...@lists.ettus.com
When replying, please edit your Subject line so it is more specific
than "Re: Contents of USRP-users digest..."
Today's Topics:
1. Re: [Discuss-gnuradio] Strange uhd::device::send execution
times (Gaetano Mendola)
2. E100 Static IP (Scott Johnston)
3. Re: E100 Static IP (Douglas Geiger)
4. Re: E100 Static IP (Scott Johnston)
5. Re: E100 Static IP (Douglas Geiger)
6. Re: [Discuss-gnuradio] Strange uhd::device::send execution
times (Gaetano Mendola)
7. error on spectrum sensing.py (suneel g)
8. Re: error on spectrum sensing.py (Morgan Redfield)
9. Problem when building UHD for E100 (Christophe ALEXANDRE)
10. Re: [Discuss-gnuradio] Strange uhd::device::send execution
times (Gaetano Mendola)
11. Fwd: USRP-FIFO, question about double buffering
(George Sklivanitis)
12. uhd: mboard_impl.cpp -> mboard_get -> case MBOARD_PROP_IFACE
missing (Andre Pool)
----------------------------------------------------------------------
Message: 1
Date: Mon, 20 Jun 2011 18:07:09 +0200
From: Gaetano Mendola <mend...@gmail.com>
To: j...@ettus.com
Cc: "usrp-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] [Discuss-gnuradio] Strange uhd::device::send
execution times
Message-ID: <banlktimalvvmsx88dn5v+8xhnxm2pqw...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
On Mon, Jun 20, 2011 at 5:52 PM, Josh Blum <j...@ettus.com> wrote:
> The thread in UHD is primarily for TX flow control. It has its own
> socket for async messages, and spends most of the time sleeping on the
> socket recv call. The thread wakes up a few hundred times per second to
> update the flow control sequence number.
>
> I can't explain what you are seeing. If you have somehow stopped this
> thread from waking up, then the calls to send() will be throttled. Which
> means they will block until the flow control condition updates or timeout.
Neither I, consider that same software, same operating system running on
on another server (same processor, same motherboard, tomorrow I will check
the ram) is running fine even if I put those two threads even on same core.
The only difference I can see with lspci is:
00:01.0 PCI bridge: Intel Corporation 5520/5500/X58 I/O Hub PCI
Express Root Port 1 (rev 22)
00:03.0 PCI bridge: Intel Corporation 5520/5500/X58 I/O Hub PCI
Express Root Port 3 (rev 22)
00:07.0 PCI bridge: Intel Corporation 5520/5500/X58 I/O Hub PCI
Express Root Port 7 (rev 22)
while on the working system (without the need of the cpu affinity):
00:01.0 PCI bridge: Intel Corporation 5520/5500/X58 I/O Hub PCI
Express Root Port 1 (rev 13)
00:03.0 PCI bridge: Intel Corporation 5520/5500/X58 I/O Hub PCI
Express Root Port 3 (rev 13)
00:07.0 PCI bridge: Intel Corporation 5520/5500/X58 I/O Hub PCI
Express Root Port 7 (rev 13)
the revision is different, I hope there isn't a latent bug related to that rev.
Gaetano
--
cpp-today.blogspot.com
------------------------------
Message: 2
Date: Mon, 20 Jun 2011 12:29:27 -0400
From: Scott Johnston <scott.johns...@ll.mit.edu>
To: "usrp-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: [USRP-users] E100 Static IP
Message-ID: <4dff7567.9030...@ll.mit.edu>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Hello,
Can the E100 be assigned a static IP address? My network requires it.
Thanks
Scott
Gaetano Mendola wrote:
> On Mon, Jun 20, 2011 at 5:52 PM, Josh Blum <j...@ettus.com> wrote:
>
>> The thread in UHD is primarily for TX flow control. It has its own
>> socket for async messages, and spends most of the time sleeping on the
>> socket recv call. The thread wakes up a few hundred times per second to
>> update the flow control sequence number.
>>
>> I can't explain what you are seeing. If you have somehow stopped this
>> thread from waking up, then the calls to send() will be throttled. Which
>> means they will block until the flow control condition updates or timeout.
>>
>
> Neither I, consider that same software, same operating system running on
> on another server (same processor, same motherboard, tomorrow I will check
> the ram) is running fine even if I put those two threads even on same core.
>
> The only difference I can see with lspci is:
>
> 00:01.0 PCI bridge: Intel Corporation 5520/5500/X58 I/O Hub PCI
> Express Root Port 1 (rev 22)
> 00:03.0 PCI bridge: Intel Corporation 5520/5500/X58 I/O Hub PCI
> Express Root Port 3 (rev 22)
> 00:07.0 PCI bridge: Intel Corporation 5520/5500/X58 I/O Hub PCI
> Express Root Port 7 (rev 22)
>
> while on the working system (without the need of the cpu affinity):
>
> 00:01.0 PCI bridge: Intel Corporation 5520/5500/X58 I/O Hub PCI
> Express Root Port 1 (rev 13)
> 00:03.0 PCI bridge: Intel Corporation 5520/5500/X58 I/O Hub PCI
> Express Root Port 3 (rev 13)
> 00:07.0 PCI bridge: Intel Corporation 5520/5500/X58 I/O Hub PCI
> Express Root Port 7 (rev 13)
>
> the revision is different, I hope there isn't a latent bug related to that
> rev.
>
> Gaetano
>
>
--
Scott Johnston
MIT Lincoln Laboratory
244 Wood Street, Lexington, MA 02420-9108
(781) 981-8196
scott.johns...@ll.mit.edu
------------------------------
Message: 3
Date: Mon, 20 Jun 2011 12:42:36 -0400
From: Douglas Geiger <doug.gei...@bioradiation.net>
To: Scott Johnston <scott.johns...@ll.mit.edu>
Cc: "usrp-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] E100 Static IP
Message-ID: <BANLkTi=yjwodhmbd77r558xoyaqb2kc...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Edit the file /etc/network/interfaces. In particular the line you're
looking to change is:
iface eth0 inet dhcp
Change it to something like:
iface eth0 inet static
address 192.168.x.y
netmask 255.255.255.0
gateway 192.168.x.z
Or whatever the appropriate settings for your local network are.
You can use the serial console connection to edit this before plugging
it into the network, or if you're building your own image (e.g.
following the wiki pages on how to do that) you can mess with the
sources/openembedded/recipes/netbase/netbase/interfaces file.
On Mon, Jun 20, 2011 at 12:29 PM, Scott Johnston
<scott.johns...@ll.mit.edu> wrote:
> Hello,
>
> Can the E100 be assigned a static IP address? My network requires it.
>
> Thanks
>
> Scott
>
> Gaetano Mendola wrote:
>>
>> On Mon, Jun 20, 2011 at 5:52 PM, Josh Blum <j...@ettus.com> wrote:
>>
>>>
>>> The thread in UHD is primarily for TX flow control. It has its own
>>> socket for async messages, and spends most of the time sleeping on the
>>> socket recv call. The thread wakes up a few hundred times per second to
>>> update the flow control sequence number.
>>>
>>> I can't explain what you are seeing. If you have somehow stopped this
>>> thread from waking up, then the calls to send() will be throttled. Which
>>> means they will block until the flow control condition updates or
>>> timeout.
>>>
>>
>> Neither I, consider that same software, same operating system running on
>> on another server (same processor, same motherboard, tomorrow I will check
>> the ram) ?is running fine even if I put those two threads even on same
>> core.
>>
>> The only difference I can see with lspci is:
>>
>> 00:01.0 PCI bridge: Intel Corporation 5520/5500/X58 I/O Hub PCI
>> Express Root Port 1 (rev 22)
>> 00:03.0 PCI bridge: Intel Corporation 5520/5500/X58 I/O Hub PCI
>> Express Root Port 3 (rev 22)
>> 00:07.0 PCI bridge: Intel Corporation 5520/5500/X58 I/O Hub PCI
>> Express Root Port 7 (rev 22)
>>
>> while on the working system (without the need of the cpu affinity):
>>
>> 00:01.0 PCI bridge: Intel Corporation 5520/5500/X58 I/O Hub PCI
>> Express Root Port 1 (rev 13)
>> 00:03.0 PCI bridge: Intel Corporation 5520/5500/X58 I/O Hub PCI
>> Express Root Port 3 (rev 13)
>> 00:07.0 PCI bridge: Intel Corporation 5520/5500/X58 I/O Hub PCI
>> Express Root Port 7 (rev 13)
>>
>> the revision is different, I hope there isn't a latent bug related to that
>> rev.
>>
>> Gaetano
>>
>>
>
> --
> Scott Johnston
> MIT Lincoln Laboratory
> 244 Wood Street, Lexington, MA 02420-9108
> (781) 981-8196
> scott.johns...@ll.mit.edu
>
>
> _______________________________________________
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
--
Doug Geiger
doug.gei...@bioradiation.net
------------------------------
Message: 4
Date: Mon, 20 Jun 2011 12:55:19 -0400
From: Scott Johnston <scott.johns...@ll.mit.edu>
To: Douglas Geiger <doug.gei...@bioradiation.net>
Cc: "usrp-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] E100 Static IP
Message-ID: <4dff7b77.8010...@ll.mit.edu>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Thank you
Where can I find it's MAC address?
Douglas Geiger wrote:
> Edit the file /etc/network/interfaces. In particular the line you're
> looking to change is:
>
> iface eth0 inet dhcp
>
> Change it to something like:
>
> iface eth0 inet static
> address 192.168.x.y
> netmask 255.255.255.0
> gateway 192.168.x.z
>
> Or whatever the appropriate settings for your local network are.
> You can use the serial console connection to edit this before plugging
> it into the network, or if you're building your own image (e.g.
> following the wiki pages on how to do that) you can mess with the
> sources/openembedded/recipes/netbase/netbase/interfaces file.
>
> On Mon, Jun 20, 2011 at 12:29 PM, Scott Johnston
> <scott.johns...@ll.mit.edu> wrote:
>
>> Hello,
>>
>> Can the E100 be assigned a static IP address? My network requires it.
>>
>> Thanks
>>
>> Scott
>>
>> Gaetano Mendola wrote:
>>
>>> On Mon, Jun 20, 2011 at 5:52 PM, Josh Blum <j...@ettus.com> wrote:
>>>
>>>
>>>> The thread in UHD is primarily for TX flow control. It has its own
>>>> socket for async messages, and spends most of the time sleeping on the
>>>> socket recv call. The thread wakes up a few hundred times per second to
>>>> update the flow control sequence number.
>>>>
>>>> I can't explain what you are seeing. If you have somehow stopped this
>>>> thread from waking up, then the calls to send() will be throttled. Which
>>>> means they will block until the flow control condition updates or
>>>> timeout.
>>>>
>>>>
>>> Neither I, consider that same software, same operating system running on
>>> on another server (same processor, same motherboard, tomorrow I will check
>>> the ram) is running fine even if I put those two threads even on same
>>> core.
>>>
>>> The only difference I can see with lspci is:
>>>
>>> 00:01.0 PCI bridge: Intel Corporation 5520/5500/X58 I/O Hub PCI
>>> Express Root Port 1 (rev 22)
>>> 00:03.0 PCI bridge: Intel Corporation 5520/5500/X58 I/O Hub PCI
>>> Express Root Port 3 (rev 22)
>>> 00:07.0 PCI bridge: Intel Corporation 5520/5500/X58 I/O Hub PCI
>>> Express Root Port 7 (rev 22)
>>>
>>> while on the working system (without the need of the cpu affinity):
>>>
>>> 00:01.0 PCI bridge: Intel Corporation 5520/5500/X58 I/O Hub PCI
>>> Express Root Port 1 (rev 13)
>>> 00:03.0 PCI bridge: Intel Corporation 5520/5500/X58 I/O Hub PCI
>>> Express Root Port 3 (rev 13)
>>> 00:07.0 PCI bridge: Intel Corporation 5520/5500/X58 I/O Hub PCI
>>> Express Root Port 7 (rev 13)
>>>
>>> the revision is different, I hope there isn't a latent bug related to that
>>> rev.
>>>
>>> Gaetano
>>>
>>>
>>>
>> --
>> Scott Johnston
>> MIT Lincoln Laboratory
>> 244 Wood Street, Lexington, MA 02420-9108
>> (781) 981-8196
>> scott.johns...@ll.mit.edu
>>
>>
>> _______________________________________________
>> USRP-users mailing list
>> USRP-users@lists.ettus.com
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>>
>
>
>
>
--
Scott Johnston
MIT Lincoln Laboratory
244 Wood Street, Lexington, MA 02420-9108
(781) 981-8196
scott.johns...@ll.mit.edu
------------------------------
Message: 5
Date: Mon, 20 Jun 2011 12:58:48 -0400
From: Douglas Geiger <doug.gei...@bioradiation.net>
To: Scott Johnston <scott.johns...@ll.mit.edu>
Cc: "usrp-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] E100 Static IP
Message-ID: <BANLkTinUq5LVzQb+FW+NOQ-=na_wbsw...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
ifconfig eth0
It's listed right after HWaddr on the first line.
Doug
On Mon, Jun 20, 2011 at 12:55 PM, Scott Johnston
<scott.johns...@ll.mit.edu> wrote:
> Thank you
>
> Where can I find it's MAC address?
>
>
> Douglas Geiger wrote:
>>
>> Edit the file /etc/network/interfaces. In particular the line you're
>> looking to change is:
>>
>> iface eth0 inet dhcp
>>
>> Change it to something like:
>>
>> iface eth0 inet static
>> ?address 192.168.x.y
>> ?netmask 255.255.255.0
>> ?gateway 192.168.x.z
>>
>> Or whatever the appropriate settings for your local network are.
>> You can use the serial console connection to edit this before plugging
>> it into the network, or if you're building your own image (e.g.
>> following the wiki pages on how to do that) you can mess with the
>> sources/openembedded/recipes/netbase/netbase/interfaces file.
>>
>> On Mon, Jun 20, 2011 at 12:29 PM, Scott Johnston
>> <scott.johns...@ll.mit.edu> wrote:
>>
>>>
>>> Hello,
>>>
>>> Can the E100 be assigned a static IP address? My network requires it.
>>>
>>> Thanks
>>>
>>> Scott
>>>
>>> Gaetano Mendola wrote:
>>>
>>>>
>>>> On Mon, Jun 20, 2011 at 5:52 PM, Josh Blum <j...@ettus.com> wrote:
>>>>
>>>>
>>>>>
>>>>> The thread in UHD is primarily for TX flow control. It has its own
>>>>> socket for async messages, and spends most of the time sleeping on the
>>>>> socket recv call. The thread wakes up a few hundred times per second to
>>>>> update the flow control sequence number.
>>>>>
>>>>> I can't explain what you are seeing. If you have somehow stopped this
>>>>> thread from waking up, then the calls to send() will be throttled.
>>>>> Which
>>>>> means they will block until the flow control condition updates or
>>>>> timeout.
>>>>>
>>>>>
>>>>
>>>> Neither I, consider that same software, same operating system running on
>>>> on another server (same processor, same motherboard, tomorrow I will
>>>> check
>>>> the ram) ?is running fine even if I put those two threads even on same
>>>> core.
>>>>
>>>> The only difference I can see with lspci is:
>>>>
>>>> 00:01.0 PCI bridge: Intel Corporation 5520/5500/X58 I/O Hub PCI
>>>> Express Root Port 1 (rev 22)
>>>> 00:03.0 PCI bridge: Intel Corporation 5520/5500/X58 I/O Hub PCI
>>>> Express Root Port 3 (rev 22)
>>>> 00:07.0 PCI bridge: Intel Corporation 5520/5500/X58 I/O Hub PCI
>>>> Express Root Port 7 (rev 22)
>>>>
>>>> while on the working system (without the need of the cpu affinity):
>>>>
>>>> 00:01.0 PCI bridge: Intel Corporation 5520/5500/X58 I/O Hub PCI
>>>> Express Root Port 1 (rev 13)
>>>> 00:03.0 PCI bridge: Intel Corporation 5520/5500/X58 I/O Hub PCI
>>>> Express Root Port 3 (rev 13)
>>>> 00:07.0 PCI bridge: Intel Corporation 5520/5500/X58 I/O Hub PCI
>>>> Express Root Port 7 (rev 13)
>>>>
>>>> the revision is different, I hope there isn't a latent bug related to
>>>> that
>>>> rev.
>>>>
>>>> Gaetano
>>>>
>>>>
>>>>
>>>
>>> --
>>> Scott Johnston
>>> MIT Lincoln Laboratory
>>> 244 Wood Street, Lexington, MA 02420-9108
>>> (781) 981-8196
>>> scott.johns...@ll.mit.edu
>>>
>>>
>>> _______________________________________________
>>> USRP-users mailing list
>>> USRP-users@lists.ettus.com
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>
>>>
>>
>>
>>
>>
>
> --
> Scott Johnston
> MIT Lincoln Laboratory
> 244 Wood Street, Lexington, MA 02420-9108
> (781) 981-8196
> scott.johns...@ll.mit.edu
>
>
--
Doug Geiger
doug.gei...@bioradiation.net
------------------------------
Message: 6
Date: Mon, 20 Jun 2011 19:47:55 +0200
From: Gaetano Mendola <mend...@gmail.com>
To: j...@ettus.com
Cc: "usrp-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] [Discuss-gnuradio] Strange uhd::device::send
execution times
Message-ID: <banlktinpt-i-az4z43vwksumxubi42p...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
On Mon, Jun 20, 2011 at 6:07 PM, Gaetano Mendola <mend...@gmail.com> wrote:
> On Mon, Jun 20, 2011 at 5:52 PM, Josh Blum <j...@ettus.com> wrote:
>> The thread in UHD is primarily for TX flow control. It has its own
>> socket for async messages, and spends most of the time sleeping on the
>> socket recv call. The thread wakes up a few hundred times per second to
>> update the flow control sequence number.
>>
>> I can't explain what you are seeing. If you have somehow stopped this
>> thread from waking up, then the calls to send() will be throttled. Which
>> means they will block until the flow control condition updates or timeout.
>
> Neither I, consider that same software, same operating system running on
> on another server (same processor, same motherboard, tomorrow I will check
> the ram) ?is running fine even if I put those two threads even on same core.
>
> The only difference I can see with lspci is:
>
> 00:01.0 PCI bridge: Intel Corporation 5520/5500/X58 I/O Hub PCI
> Express Root Port 1 (rev 22)
> 00:03.0 PCI bridge: Intel Corporation 5520/5500/X58 I/O Hub PCI
> Express Root Port 3 (rev 22)
> 00:07.0 PCI bridge: Intel Corporation 5520/5500/X58 I/O Hub PCI
> Express Root Port 7 (rev 22)
>
> while on the working system (without the need of the cpu affinity):
>
> 00:01.0 PCI bridge: Intel Corporation 5520/5500/X58 I/O Hub PCI
> Express Root Port 1 (rev 13)
> 00:03.0 PCI bridge: Intel Corporation 5520/5500/X58 I/O Hub PCI
> Express Root Port 3 (rev 13)
> 00:07.0 PCI bridge: Intel Corporation 5520/5500/X58 I/O Hub PCI
> Express Root Port 7 (rev 13)
>
> the revision is different, I hope there isn't a latent bug related to that
> rev.
Also what I noticed is the fact that even if the send method lasts 1 second
and the timeout is still the default (0.1 second) the value returned reflect the
fact that all samples were sent; so or I haven't catched that timeout meaning
or for the send the samples were sent in time.
Gaetano
--
cpp-today.blogspot.com
------------------------------
Message: 7
Date: Mon, 20 Jun 2011 23:24:21 +0530 (IST)
From: suneel g <gsunil...@yahoo.co.in>
To: usrp <usrp-users@lists.ettus.com>
Subject: [USRP-users] error on spectrum sensing.py
Message-ID: <831744.34509...@web137318.mail.in.yahoo.com>
Content-Type: text/plain; charset="iso-8859-1"
hai all
while running uhd_spectrum_sense_sum.py? i got a error as
?File "./spectrumsensing.py", line 261
??? filename = "spectrum_sense_exp_" + time.strftime('%y%m%d_%H%M%S') + ".csv"
?????????? ^
IndentationError: expected an indented block
and some times error showing at
??????? def __init__(self, tb):
??????????? ^
IndentationError: expected an indented block
any one help me how solve this error.
iam very new to python language.
?
thanks in advance.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20110620/aefed595/attachment-0001.html>
------------------------------
Message: 8
Date: Mon, 20 Jun 2011 11:20:20 -0700
From: Morgan Redfield <redfie...@gmail.com>
To: suneel g <gsunil...@yahoo.co.in>
Cc: usrp <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] error on spectrum sensing.py
Message-ID: <banlktin09cds6gkbcrgpc3ztgnbv_0k...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Woops. That's my fault. Looks like my last git push had a broken file. I
just updated it and it should work for you now.
In general, if you get errors like that it means that the indentation is
off. If you've edited the files at all, make sure that the indentations are
all spaces, and not tabs.
You probably can comment out all the file io. That was all for my specific
project, and I'm not sure how helpful it'll be for other people. The
spectrum_sense.py file is the same as the uhd_spectrum_sense_sum.py file,
but with the code cleaned up quite a bit. You might find that more helpful
(note that it depends on the sense_path.py file).
https://github.com/mogar/uhd_utils/blob/master/spectrum_sense.py
Morgan
On Mon, Jun 20, 2011 at 10:54 AM, suneel g <gsunil...@yahoo.co.in> wrote:
> hai all
>
> while running uhd_spectrum_sense_sum.py i got a error as
>
> File "./spectrumsensing.py", line 261
> filename = "spectrum_sense_exp_" + time.strftime('%y%m%d_%H%M%S') +
> ".csv"
> ^
> IndentationError: expected an indented block
>
> and some times error showing at
> def __init__(self, tb):
> ^
> IndentationError: expected an indented block
>
> any one help me how solve this error.
>
> iam very new to python language.
>
> thanks in advance.
>
> _______________________________________________
> USRP-users mailing list
> USRP-users@lists.ettus.com
> 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/20110620/c499ede0/attachment-0001.html>
------------------------------
Message: 9
Date: Tue, 21 Jun 2011 09:40:58 +0200
From: "Christophe ALEXANDRE" <christophe.alexan...@cnam.fr>
To: <usrp-users@lists.ettus.com>
Cc: c.vel...@free.fr
Subject: [USRP-users] Problem when building UHD for E100
Message-ID: <7372D0E3744C42388E812ED8B0B8283E@fletan>
Content-Type: text/plain; format=flowed; charset="iso-8859-1";
reply-type=response
so i have made the test to check my E100
following the faq. What i have done :
connect keyboard, mouse, screen to the E100
and boot angstrom. Loggin, open terminal then followed the faq :
$ git clone git://ettus.sourcerepo.com/ettus/uhd.git
$ cd uhd/host/
$ mkdir build
$ cd build
$
cmake -DCMAKE_CXX_FLAGS:STRING="-mcpu=cortex-a8 -mfpu=neon -mfloat-abi=softfp
-g" -DENABLE_USRP_E100=TRUE -DENABLE_USRP_E_UTILS=TRUE ../
$ make
$ make test
$ su
# make install
# ldconfig
it seems ok. then :
$ cd uhd/host/build/examples
$ su
then i tried the new program benchmark_rate :
root@usrp-e1xx:~/uhd/host/build/examples# ./benchmark_rate --rx_rate
1000 --tx_rate 1000 --duration 10
linux; GNU C++ version 4.5.2 20101204 (prerelease); Boost_104100;
UHD_003.001.002-d7a4ef0
Creating the usrp device with: ...
-- Opening USRP-E on /dev/usrp_e0
Error: EnvironmentError: IOError: Failed to open /dev/usrp_e0
what should i do then ?
Regards.
Christophe ALEXANDRE
Conservatoire National des Arts et M?tiers (CNAM)
Laboratoire CEDRIC-LAETITIA
D?partement EASY
Acc?s 17-1-32, Case 2D2P10
292 rue Saint Martin
75141 PARIS CEDEX 03
FRANCE
email : christophe.alexan...@cnam.fr
tel. 0140272699
fax. 0140272994
----- Original Message -----
From: "Philip Balister" <phi...@opensdr.com>
To: "Christophe ALEXANDRE" <christophe.alexan...@cnam.fr>
Cc: <c.vel...@free.fr>
Sent: Monday, June 20, 2011 2:56 PM
Subject: Re: (CNAM)Problem when building UHD for E100 under UBUNTU 11.04
> On 06/20/2011 08:07 AM, Christophe ALEXANDRE wrote:
>> Hi Philip,
>>
>> my name is ALEXANDRE Christophe and i'm a professor here at the CNAM.
>> C.VELLIN is one of my student. i try to make my brand new E100
>> work. I'm following the FAQ and i just want to check that the E100
>> is working properly, without any success for now.
>>
>> i can build and install UHD.
>> i can build and install GNURADIO.
>>
>> the fix i should apply to grc_grc.m4 in the following procedure :
>>
>> How can I build GRC with GNU Radio??
>> GRC will not be built by default because of an autoconfig dependency on
>> wxPython, which isn't provided in the opkg repos. GRC does not need
>> wxPython to run, however - it is only needed for GUI flow graphs.
>>
>> To build GRC without wxPython on the E1XX, apply this fix to the
>> autoconf m4 files:
>> https://github.com/balister/GNU-Radio/commit/e4d9277ca3822d55562f6a75b7044dec78d68ff0
>>
>>
>> is obsolete because the m4 has changed. I don't know what i am supposed
>> to do.
>
> Try ignoring this step. It is possible we removed the need for this step.
>
>>
>> i want to check my 2 E100. So i follow the procedure :
>>
>> How can I test my UHD build and my E1XX??
>> but first the
>>
>> benchmark_rx_rate
>>
>> program doesn't work and now it has disappeared from uhd git.
>>
>> So i have a simple question : how can i test the E100 simply ?
>>
>
> Try benchmark_rate. We just combined them into one program last week. Use
> benchmark_rate --help to see the new options.
>
> I'll be traveling to Brussels tomorrow for WINCOMM and on vacation for a
> week after that. The usrp-users list would be a good place to post
> questions in case my internet access is not good.
>
> Philip
>
>>
>> regards.
>>
>>
>> Christophe ALEXANDRE
>> Conservatoire National des Arts et M?tiers (CNAM)
>> Laboratoire CEDRIC-LAETITIA
>> D?partement EASY
>> Acc?s 17-1-32, Case 2D2P10
>> 292 rue Saint Martin
>> 75141 PARIS CEDEX 03
>> FRANCE
>> email : christophe.alexan...@cnam.fr
>> tel. 0140272699
>> fax. 0140272994
>>
>>
>> ----- Original Message ----- From: "Philip Balister" <phi...@opensdr.com>
>> To: <c.vel...@free.fr>
>> Cc: <christophe.alexan...@cnam.fr>
>> Sent: Thursday, June 16, 2011 6:19 PM
>> Subject: Re: (CNAM)Problem when building UHD for E100 under UBUNTU 11.04
>>
>>
>>> On 06/16/2011 09:14 AM, c.vel...@free.fr wrote:
>>>> Hi,
>>>> my last mail wasn't clear, here are some more informations :
>>>> We're still doing the e100's FAQ.
>>>> We succeed with the UHD build.
>>>>
>>>> But when we execute ldconfig, we get :
>>>> ****
>>>> ldconfig: /usr/lib/libstdc++.so.6.0.14-gdb.py is not an ELF file - it
>>>> has the
>>>> wrong magic bytes at the start.
>>>> ****
>>>
>>> This is harmless. Ignore it. This should be fixed in the future updates.
>>>
>>>>
>>>> And if we try to continue in order to test the e100
>>>> (./benchmark_rx_rate --rate
>>>> 100
>>>> ) we get :
>>>> ****
>>>> root@usrp-e1xx:~/uhd/host/build/examples# ./benchmark_rx_rate --rate
>>>> 100
>>>>
>>>> linux; GNU C++ version 4.5.2 20101204 (prerelease); Boost_104100;
>>>> UHD_003.001.001-9abe8ae
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Creating the usrp device with: ...
>>>>
>>>> use_count = 2
>>>>
>>>> -- Opening USRP-E on /dev/usrp_euse_count = 2
>>>
>>> It sounds like another program has the device driver open. Only one
>>> program can use the fpga interface at a time.
>>>
>>>>
>>>> 0
>>>>
>>>> Error: EnvironmentError: IOError: Failed to open /dev/usrp_e0
>>>>
>>>> ****
>>>>
>>>> And finally a question : where is on the e100 the firmaware for the
>>>> FPGA?(the
>>>> source file of ISE project) ??
>>>
>>> In the git repository from ettus, look in the directory usrp2/top/u1e
>>> (I think the last name is correct, the tree O have has another name as
>>> part of a naming clean up) If you let me know what directories you
>>> see, I can make sure you are in the correct place.
>>>
>>> Philip
>>>
>>>>
>>>> Sincerely,
>>>>
>>>> Christian.
>>>>
>>>>
>>>> Quoting Philip Balister<phi...@opensdr.com>:
>>>>
>>>>> On 06/15/2011 09:53 AM, c.vel...@free.fr wrote:
>>>>>> We have already read this link,
>>>>>> how can we use gnu radio on PC with the e100?
>>>>>
>>>>> You should be able to run gnuradio-companion on the E100. It is
>>>>> possible
>>>>> to write a flowgrpah on the E100 that uses the UDP sink/source
>>>>> blocks to
>>>>> transfer data to a PC that also runs GNU Radio.
>>>>>
>>>>> Philip
>>>>>
>>>>>>
>>>>>> Selon Philip Balister<phi...@opensdr.com>:
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 06/15/2011 09:33 AM, c.vel...@free.fr wrote:
>>>>>>>> Ok,
>>>>>>>> we don't need any driver on linux and it's the same on windows?
>>>>>>>> So how GNU radio communicate with E100? using ethernet?
>>>>>>>> And where GNU radio should run ? on PC or E100?
>>>>>>>> sincerely,
>>>>>>>
>>>>>>> The E100 has an ARM processor that can run GNU Radio.
>>>>>>>
>>>>>>> This page will help you get started:
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>> http://ettus-apps.sourcerepo.com/redmine/ettus/projects/usrpe1xx/wiki/FAQ#How-do-I-talk-to-the-E100
>>>>
>>>>>>>
>>>>>>> Philip
>>>>>>>
>>>>>>>> chris
>>>>>>>>
>>>>>>>> Quoting Philip Balister<phi...@balister.org>:
>>>>>>>>
>>>>>>>>> On 06/15/2011 07:18 AM, c.vel...@free.fr wrote:
>>>>>>>>>> Hi,
>>>>>>>>>> we bought two E100 with WBX daughter board few weeks ago
>>>>>>>>> (ECR10Z1E1/EAR10Z7E1).
>>>>>>>>>> We received on friday these items.
>>>>>>>>>> Today we followed steps mentionned in the link
>>>>>>>>>>
>>>>>>> following:http://code.ettus.com/redmine/ettus/projects/usrpe1xx/wiki/FAQ/.
>>>>>>>
>>>>>>>>>> But when we tried to build the UHD, the cmake instruction
>>>>>>>>>> failed (cmake
>>>>>>>>>> -DCMAKE_CXX_FLAGS:STRING="-mcpu=cortex-a8 -mfpu=neon
>>>>>>>>>> -mfloat-abi=softfp
>>>>>>> -g"
>>>>>>>>>> -DENABLE_USRP_E100=TRUE -DENABLE_USRP_E_UTILS=TRUE ../).
>>>>>>>>>>
>>>>>>>>>> Here are the terminal message:
>>>>>>>>>>
>>>>>>>>>> ************************************************
>>>>>>>>>> alex@dauphin:~/uhd/host/build$ cmake
>>>>>>>>> -DCMAKE_CXX_FLAGS:STRING="-mcpu=cortex-a8
>>>>>>>>>
>>>>>>>>> These instructions are for building uhd on teh e100, not on an
>>>>>>>>> x86 PC.
>>>>>>>>> Are you sure you are logged into the e100?
>>>>>>>>>
>>>>>>>>> Philip
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> -mfpu=neon -mfloat-abi=softfp -g" -DENABLE_USRP_E100=TRUE
>>>>>>>>>> -DENABLE_USRP_E_UTILS=TRUE ../
>>>>>>>>>> -- The CXX compiler identification is unknown
>>>>>>>>>> -- Check for working CXX compiler: /usr/bin/c++
>>>>>>>>>> -- Check for working CXX compiler: /usr/bin/c++ -- broken
>>>>>>>>>> CMake Error at
>>>>> /usr/share/cmake-2.8/Modules/CMakeTestCXXCompiler.cmake:45
>>>>>>>>>> (MESSAGE):
>>>>>>>>>> The C++ compiler "/usr/bin/c++" is not able to compile a simple
>>>>> test
>>>>>>>>>> program.
>>>>>>>>>>
>>>>>>>>>> It fails with the following output:
>>>>>>>>>>
>>>>>>>>>> Change Dir: /home/alex/uhd/host/build/CMakeFiles/CMakeTmp
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Run Build Command:/usr/bin/make "cmTryCompileExec/fast"
>>>>>>>>>>
>>>>>>>>>> /usr/bin/make -f CMakeFiles/cmTryCompileExec.dir/build.make
>>>>>>>>>> CMakeFiles/cmTryCompileExec.dir/build
>>>>>>>>>>
>>>>>>>>>> make[1]: Entering directory
>>>>>>>>> `/home/alex/uhd/host/build/CMakeFiles/CMakeTmp'
>>>>>>>>>>
>>>>>>>>>> /usr/bin/cmake -E cmake_progress_report
>>>>>>>>>> /home/alex/uhd/host/build/CMakeFiles/CMakeTmp/CMakeFiles 1
>>>>>>>>>>
>>>>>>>>>> Building CXX object
>>>>>>>>> CMakeFiles/cmTryCompileExec.dir/testCXXCompiler.cxx.o
>>>>>>>>>>
>>>>>>>>>> /usr/bin/c++ -mcpu=cortex-a8 -mfpu=neon -mfloat-abi=softfp -g -o
>>>>>>>>>> CMakeFiles/cmTryCompileExec.dir/testCXXCompiler.cxx.o -c
>>>>>>>>>>
>>>>>>>>>> /home/alex/uhd/host/build/CMakeFiles/CMakeTmp/testCXXCompiler.cxx
>>>>>>>>>>
>>>>>>>>>> `-mcpu=' is deprecated. Use `-mtune=' or '-march=' instead.
>>>>>>>>>>
>>>>>>>>>> cc1plus: error: unrecognized command line option "-mfpu=neon"
>>>>>>>>>>
>>>>>>>>>> cc1plus: error: unrecognized command line option
>>>>> "-mfloat-abi=softfp"
>>>>>>>>>>
>>>>>>>>>>
>>>>>>> /home/alex/uhd/host/build/CMakeFiles/CMakeTmp/testCXXCompiler.cxx:1:0:
>>>>>>>
>>>>>>>>>> error: bad value (cortex-a8) for -mtune= switch
>>>>>>>>>>
>>>>>>>>>> make[1]: ***
>>>>> [CMakeFiles/cmTryCompileExec.dir/testCXXCompiler.cxx.o]
>>>>>>>>> Error
>>>>>>>>>> 1
>>>>>>>>>>
>>>>>>>>>> make[1]: Leaving directory
>>>>>>>>> `/home/alex/uhd/host/build/CMakeFiles/CMakeTmp'
>>>>>>>>>>
>>>>>>>>>> make: *** [cmTryCompileExec/fast] Error 2
>>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> CMake will not be able to correctly generate this project.
>>>>>>>>>> Call Stack (most recent call first):
>>>>>>>>>> CMakeLists.txt:27 (PROJECT)
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> -- Configuring incomplete, errors occurred!
>>>>>>>>>>
>>>>>>>>>> *********************************************
>>>>>>>>>> Do we install a specific packages?
>>>>>>>>>> Any information will help!
>>>>>>>>>> Sincerely.
>>>>>>>>>> Christian Vellin.
>>>>>>>>>> Cnam Paris France.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>
------------------------------
Message: 10
Date: Tue, 21 Jun 2011 12:45:41 +0200
From: Gaetano Mendola <mend...@gmail.com>
To: j...@ettus.com
Cc: "usrp-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] [Discuss-gnuradio] Strange uhd::device::send
execution times
Message-ID: <BANLkTimTahyVAo7aJTEk5ePDkJTYmZrH=a...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
On Mon, Jun 20, 2011 at 7:47 PM, Gaetano Mendola <mend...@gmail.com> wrote:
> On Mon, Jun 20, 2011 at 6:07 PM, Gaetano Mendola <mend...@gmail.com> wrote:
>> On Mon, Jun 20, 2011 at 5:52 PM, Josh Blum <j...@ettus.com> wrote:
>>> The thread in UHD is primarily for TX flow control. It has its own
>>> socket for async messages, and spends most of the time sleeping on the
>>> socket recv call. The thread wakes up a few hundred times per second to
>>> update the flow control sequence number.
>>>
>>> I can't explain what you are seeing. If you have somehow stopped this
>>> thread from waking up, then the calls to send() will be throttled. Which
>>> means they will block until the flow control condition updates or timeout.
>>
>> Neither I, consider that same software, same operating system running on
>> on another server (same processor, same motherboard, tomorrow I will check
>> the ram) ?is running fine even if I put those two threads even on same core.
>>
>> The only difference I can see with lspci is:
>>
>> 00:01.0 PCI bridge: Intel Corporation 5520/5500/X58 I/O Hub PCI
>> Express Root Port 1 (rev 22)
>> 00:03.0 PCI bridge: Intel Corporation 5520/5500/X58 I/O Hub PCI
>> Express Root Port 3 (rev 22)
>> 00:07.0 PCI bridge: Intel Corporation 5520/5500/X58 I/O Hub PCI
>> Express Root Port 7 (rev 22)
>>
>> while on the working system (without the need of the cpu affinity):
>>
>> 00:01.0 PCI bridge: Intel Corporation 5520/5500/X58 I/O Hub PCI
>> Express Root Port 1 (rev 13)
>> 00:03.0 PCI bridge: Intel Corporation 5520/5500/X58 I/O Hub PCI
>> Express Root Port 3 (rev 13)
>> 00:07.0 PCI bridge: Intel Corporation 5520/5500/X58 I/O Hub PCI
>> Express Root Port 7 (rev 13)
>>
>> the revision is different, I hope there isn't a latent bug related to that
>> rev.
>
> Also what I noticed is the fact that even if the send method lasts 1 second
> and the timeout is still the default (0.1 second) the value returned reflect
> the
> fact that all samples were sent; so or I haven't catched that timeout meaning
> or for the send the samples were sent in time.
A little update on the issue. As you know I have two servers one working and
another one working only if I do a cpu affinity for the internal UHD thread.
I have moved the disks, ram, processors from the working server to non working
one and the problem persists.
The two mother boards are from same provider but have two different revision and
different bios version.
Josh said that the only reason for the send method to throttle is to
stop the flow
control thread or the time out expiration. From what I can see the
timeout never
expires even if he send method takes too long (some time the send returns
after 2 seconds...) and the return value of the send is always the
amount of samples
I have request to send; of course the transmission is corrupted due
the fact the sender
thread is blocking on the send call not transmitting anything for too long.
Gaetano
--
cpp-today.blogspot.com
------------------------------
Message: 11
Date: Tue, 21 Jun 2011 14:41:09 +0300
From: George Sklivanitis <george.sklivani...@gmail.com>
To: usrp-users@lists.ettus.com
Subject: [USRP-users] Fwd: USRP-FIFO, question about double buffering
Message-ID: <4e008355.6000...@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Hello all,
Lately, I am experimenting with an implementation of a point-to-point
On-off Keying communication system. I mostly prefer to use the USRP as
the receiver, in which I can capture samples and later process them
through Matlab. However, because of the algorithms I try to apply at the
receiver (packet/symbol synchronization, channel estimation,
carrier-frequency offset cancellation, detection) I have to deal with a
lot of delay at the receiver processing part. As a result, my
transmitter keeps sending packets which will either get lost or stored
at the fifo.
Therefore, I would like to know, if it is possible to construct a second
buffer (softwarely in Matlab) in order not to lose so many data packets.
Does anyone have an intuition about the way the fifo is used?
Thanks,
GS
--
Sklivanitis Georgios
M.Sc. Student
Telecommunications Division,
Department of Electronics and Computer Engineering
Technical University of Crete,
Kounoupidiana Campus, Office 145.A10
Chania, Crete, 73100, Greece
Tel. : 28210 59257
www.telecom.tuc.gr/~gsklivanitis
------------------------------
Message: 12
Date: Tue, 21 Jun 2011 15:16:39 +0200
From: Andre Pool <andre.p...@vdg-security.com>
To: usrp-users@lists.ettus.com
Subject: [USRP-users] uhd: mboard_impl.cpp -> mboard_get -> case
MBOARD_PROP_IFACE missing
Message-ID: <4e0099b7.3080...@vdg-security.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Hi all,
I wanted to use the following function from the multi_usrp.cpp
mboard_iface::sptr get_mboard_iface(size_t mboard){
return _mboard(mboard)[MBOARD_PROP_IFACE].as<mboard_iface::sptr>();
}
When running the application i get the following error:
Error: LookupError: KeyError: cannot get this property
in void usrp1_impl::mboard_get(const wax::obj&, wax::obj&)
at ...../uhd/host/lib/usrp/usrp1/mboard_impl.cpp:321
Looking at the mboard_impl.cpp i see there is no case implemented for
MBOARD_PROP_IFACE.
So what is the story here?
Thanks in advance,
Andre
------------------------------
_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
End of USRP-users Digest, Vol 10, Issue 30
******************************************
