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. Non-uniform behaviour of swigged objects (was:
uhd.tune_request always returns 0) (Marcus M?ller)
2. Re: Non-uniform behaviour of swigged objects (Marcus M?ller)
3. Re: Non-uniform behaviour of swigged objects (Elvis Angelaccio)
4. Re: The transimitter gain of USRP NI-2920 (Marcus M?ller)
5. Re: 'create the usrp device' fails==Unhandled exception at
0x000007FEE74B14A8 (uhd.dll) (Nik B.)
6. Finding E310 Release Version (devin kelly)
----------------------------------------------------------------------
Message: 1
Date: Sun, 22 May 2016 18:02:56 +0200
From: Marcus M?ller <[email protected]>
To: [email protected], GNURadio Discussion List
<[email protected]>
Subject: [USRP-users] Non-uniform behaviour of swigged objects (was:
uhd.tune_request always returns 0)
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"
Well, the python semantics, at least as I understand them, dictate that
"not objectname" is True if objectname is of NoneType, or if objectname
is actually False, or evaluates to something that is False (i.e. 0).
A valid object "should be".
Checking it against the typical swigged GNU Radio objects:
$from gnuradio import blocks, uhd
$vs = blocks_vector_sink_b()
$f = uhd.tune_request(10)
$bool(vs)
True
$bool(f)
False
That's non-uniform behaviour, and it surprises me!
I'll have to meditate about this.
Best regards,
Marcus
On 22.05.2016 17:51, Marcus D. Leech via USRP-users wrote:
> On 05/22/2016 11:46 AM, Marcus M?ller via USRP-users wrote:
>> Hm, interesting. I shouldn't have thought so, but: /something's/
>> strange, and for some reason, perfectly valid uhd.tune_request
>> objects evaluate to False in this case.
>>
>> So: since there's hardly any case that you can mis-construct a tune
>> request (any frequency that is numerical should be fine, even
>> negative numbers), I'd say: drop your "if not tx_center_freq" clause
>> and just check whether the properties of the uhd.tune_result that
>> tx.set_center_freq() return match your expectation.
>>
>> Best regards,
>> Marcus
> What are the boolean semantics of a structured data type like a
> tune_request_t ? It's not immediately clear to me that there is a mapping
> in boolean for such structured data types.
>
>
>>
>> On 22.05.2016 17:32, Elvis Angelaccio via USRP-users wrote:
>>> Hi, can someone explain me why `uhd.tune_request` always returns 0 in
>>> the following Python code?
>>> I'm running this on Linux with a USRP1 attached via USB.
>>> The USRP has two 900 MHz daughterboards and two antennas attached to
>>> TX/RX ports.
>>>
>>> Gnuradio version = 3.7.9.2
>>> UHD version = 3.9.3
>>>
>>> ### CODE Snippet ####
>>>
>>> d = uhd.find_devices(uhd.device_addr(args.address_args))
>>> if d:
>>> print 'Available UHD devices: ' + str(d)
>>>
>>> try:
>>> uhd_type = d[0].get('type')
>>> except IndexError:
>>> print 'Fatal error. Did you connect the USRP to an USB port?'
>>> sys.exit(1)
>>>
>>> serial = d[0].get('serial')
>>> tx = uhd.usrp_sink(
>>> device_addr='serial=' + serial,
>>> stream_args=uhd.stream_args(
>>> 'fc32',
>>> channels=range(1)
>>> )
>>> )
>>>
>>> tx_center_freq = uhd.tune_request(freq)
>>>
>>> if not tx_center_freq: # <===== Always happening.
>>> print 'Could not set TX freq'
>>> sys.exit(1)
>>>
>>> tx.set_center_freq(tx_center_freq)
>>> ...
>>>
>>>
>>> Best regards,
>>> Elvis
>>>
>>> _______________________________________________
>>> USRP-users mailing list
>>> [email protected]
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>>
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected]
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
> _______________________________________________
> 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/20160522/69656090/attachment-0001.html>
------------------------------
Message: 2
Date: Sun, 22 May 2016 18:09:04 +0200
From: Marcus M?ller <[email protected]>
To: [email protected], GNURadio Discussion List
<[email protected]>
Subject: Re: [USRP-users] Non-uniform behaviour of swigged objects
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"
ha! uhd.tune_request (and others, like sensor_value) python objects have
a __nonzero__ method, which is inherently used for conversion to bool,
if present. And guess what: they return False.
Wondering where they come from.
Cheers,
Marcus
On 22.05.2016 18:02, Marcus M?ller wrote:
> Well, the python semantics, at least as I understand them, dictate
> that "not objectname" is True if objectname is of NoneType, or if
> objectname is actually False, or evaluates to something that is False
> (i.e. 0).
>
> A valid object "should be".
>
> Checking it against the typical swigged GNU Radio objects:
>
> $from gnuradio import blocks, uhd
> $vs = blocks_vector_sink_b()
> $f = uhd.tune_request(10)
> $bool(vs)
> True
> $bool(f)
> False
>
> That's non-uniform behaviour, and it surprises me!
>
> I'll have to meditate about this.
>
> Best regards,
> Marcus
>
> On 22.05.2016 17:51, Marcus D. Leech via USRP-users wrote:
>> On 05/22/2016 11:46 AM, Marcus M?ller via USRP-users wrote:
>>> Hm, interesting. I shouldn't have thought so, but: /something's/
>>> strange, and for some reason, perfectly valid uhd.tune_request
>>> objects evaluate to False in this case.
>>>
>>> So: since there's hardly any case that you can mis-construct a tune
>>> request (any frequency that is numerical should be fine, even
>>> negative numbers), I'd say: drop your "if not tx_center_freq" clause
>>> and just check whether the properties of the uhd.tune_result that
>>> tx.set_center_freq() return match your expectation.
>>>
>>> Best regards,
>>> Marcus
>> What are the boolean semantics of a structured data type like a
>> tune_request_t ? It's not immediately clear to me that there is a
>> mapping
>> in boolean for such structured data types.
>>
>>
>>>
>>> On 22.05.2016 17:32, Elvis Angelaccio via USRP-users wrote:
>>>> Hi, can someone explain me why `uhd.tune_request` always returns 0 in
>>>> the following Python code?
>>>> I'm running this on Linux with a USRP1 attached via USB.
>>>> The USRP has two 900 MHz daughterboards and two antennas attached to
>>>> TX/RX ports.
>>>>
>>>> Gnuradio version = 3.7.9.2
>>>> UHD version = 3.9.3
>>>>
>>>> ### CODE Snippet ####
>>>>
>>>> d = uhd.find_devices(uhd.device_addr(args.address_args))
>>>> if d:
>>>> print 'Available UHD devices: ' + str(d)
>>>>
>>>> try:
>>>> uhd_type = d[0].get('type')
>>>> except IndexError:
>>>> print 'Fatal error. Did you connect the USRP to an USB port?'
>>>> sys.exit(1)
>>>>
>>>> serial = d[0].get('serial')
>>>> tx = uhd.usrp_sink(
>>>> device_addr='serial=' + serial,
>>>> stream_args=uhd.stream_args(
>>>> 'fc32',
>>>> channels=range(1)
>>>> )
>>>> )
>>>>
>>>> tx_center_freq = uhd.tune_request(freq)
>>>>
>>>> if not tx_center_freq: # <===== Always happening.
>>>> print 'Could not set TX freq'
>>>> sys.exit(1)
>>>>
>>>> tx.set_center_freq(tx_center_freq)
>>>> ...
>>>>
>>>>
>>>> Best regards,
>>>> Elvis
>>>>
>>>> _______________________________________________
>>>> USRP-users mailing list
>>>> [email protected]
>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>
>>>
>>>
>>> _______________________________________________
>>> USRP-users mailing list
>>> [email protected]
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>>
>>
>> _______________________________________________
>> 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/20160522/7e74cd65/attachment-0001.html>
------------------------------
Message: 3
Date: Sun, 22 May 2016 18:15:30 +0200
From: Elvis Angelaccio <[email protected]>
To: Marcus M?ller <[email protected]>
Cc: [email protected], GNURadio Discussion List
<[email protected]>
Subject: Re: [USRP-users] Non-uniform behaviour of swigged objects
Message-ID:
<caln1cnviqqt-mfhu2xzbv_cug3fvo28wk6jiqvmtjwou2sr...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
2016-05-22 18:09 GMT+02:00 Marcus M?ller <[email protected]>:
> ha! uhd.tune_request (and others, like sensor_value) python objects have a
> __nonzero__ method, which is inherently used for conversion to bool, if
> present. And guess what: they return False.
> Wondering where they come from.
>
> Cheers,
> Marcus
>
> On 22.05.2016 18:02, Marcus M?ller wrote:
>
> Well, the python semantics, at least as I understand them, dictate that "not
> objectname" is True if objectname is of NoneType, or if objectname is
> actually False, or evaluates to something that is False (i.e. 0).
>
> A valid object "should be".
>
> Checking it against the typical swigged GNU Radio objects:
>
> $from gnuradio import blocks, uhd
> $vs = blocks_vector_sink_b()
> $f = uhd.tune_request(10)
> $bool(vs)
> True
> $bool(f)
> False
Not sure if related, but why does "str(f)" returns 0.0?
(I was assuming this was a float - rather than a structure - because of that)
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Message: 4
Date: Sun, 22 May 2016 18:21:20 +0200
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] The transimitter gain of USRP NI-2920
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"
Hi everyone,
I think Steven is absolutely right: amplifiers have linear ranges, and
towards their maximum gain, the linearity suffers (otherwise, it
wouldn't be the maximum gain).
NI-2920 is hardware-identical to Ettus USRP N210 + WBX , so the the
measurement data on [1] will give you an idea of the linear gain range
of TX for your frequency of operation, and measures like the
intermodulation strength with respect to gain.
Notice that BER of something that has packets containing QPSK symbols
might be a very specific and high-level description of the properties of
a channel ? for example, in your particular setup, the RX and TX
antennas are probably pretty close, so the "wanted" signal probably is
also the strongest reaching the input LNA, driving it into
non-linearity. In another scenario, receive signal power might be much
much less.
Best regards,
Marcus
[1] http://files.ettus.com/performance_data/wbx
On 22.05.2016 17:23, Steven Knudsen via USRP-users wrote:
> I am not familiar with the NI-2920 per se, but experience says that
> once you start pushing gain stages to their max, linearity starts to
> suffer. Take a look at the datasheets for the output stage and see
> what the gain and phase looks like at the top end.
>
> Others on the list will undoubtedly have better insight, I?m just
> going from experience?
>
> have fun!
>
>
> Steven Knudsen, Ph.D., P.Eng.
> www. techconficio.ca <http://techconficio.ca>
>
> www.linkedin.com/in/knudstevenknudsen
> <http://www.linkedin.com/in/knudstevenknudsen>
>
>
> All the wires are cut, my friends
> Live beyond the severed ends. Louis MacNeice
>
>
>> On May 22, 2016, at 09:09, Zhang, Wenyu via USRP-users
>> <[email protected] <mailto:[email protected]>> wrote:
>>
>> Dear all,
>> I am doing the QPSK transciever transmission with two USRPs
>> NI-2920. As I check from the datasheet, the maximum gain for the
>> transmitter usrp is 31 dB. When I set the transmitter gain at 27dB,
>> it gets the minimum BER. However, when I turn the gain to higher
>> values below the maximum, the BER gets worse. I wonder why this
>> happens. Is it due to higher SNR leading to more packets drop?Does
>> anyone know the answer? Many thanks.
>> Kindest regards,
>> Barbara
>> _______________________________________________
>> USRP-users mailing list
>> [email protected] <mailto:[email protected]>
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
> _______________________________________________
> 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/20160522/01db71c5/attachment-0001.html>
------------------------------
Message: 5
Date: Mon, 23 May 2016 07:25:03 +0000
From: Nik B. <[email protected]>
To: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] 'create the usrp device' fails==Unhandled
exception at 0x000007FEE74B14A8 (uhd.dll)
Message-ID:
<kl1pr02mb1368bf05dff5422ee66107c4d0...@kl1pr02mb1368.apcprd02.prod.outlook.com>
Content-Type: text/plain; charset="iso-2022-jp"
Solved.
Looks like it was because of the way my Visual Studio environment was set up. I
had 'debug' configuration. Changed to 'release'. Runtime library needs to
multithread (MT), not multityhread DLL (MD).
________________________________
???: Nik B.
????: 2016?5?21? 2:55:43
??: [email protected]
??: 'create the usrp device' fails==Unhandled exception at 0x000007FEE74B14A8
(uhd.dll)
All day today, I wanted to make the following program work, without success.
It is straight out of someone else's posting in the internet.
int main(int argc, char *argv[]) {
string args = "addr=192.168.10.2";
// create the usrp device
uhd::usrp::multi_usrp::sptr usrp = uhd::usrp::multi_usrp::make(args);
//<<-- this seems to create problem
some::other::codes
return 1;
}
When I build, I get an exe file (it's an Win32-ConsoleApplication) file, and
when I run that exe file, I got this error:
The thread 0x1870 has exited with code 0 (0x0).
Unhandled exception at 0x000007FEE74B14A8 (uhd.dll) in USRPReader4.exe:
0xC0000005: Access violation reading location 0x00000000003FC00.
Please check the attached picture.
Test environment:
Win 7-64
UHD driver: tried 4 different version: uhd_003.009.001-release_Win64_VS2015,
uhd_003.009.002-release_Win64_VS2015, uhd_003.009.003-release_Win64_VS2015 and
uhd_003.009.004-release_Win64_VS2015
all failed.
Boost library is in C:\boost_1_58_0.
The UHD/bin is in the 'path', so when I issue "uhd_find_devices", I get proper
response, like:
c:\UHD\bin>uhd_find_devices.exe
Win32; Microsoft Visual C++ version 14.0; Boost_105800; UHD_003.009.001-release
--------------------------------------------------
-- UHD Device 0
--------------------------------------------------
Device Address:
type: usrp2
addr: 192.168.10.2
name: sn014
serial: 1339
--------------------------------------------------
-- UHD Device 1
--------------------------------------------------
..looks like Device 0....
Working with other sample files from the internet, I get "Error:bad allocation"
error at the same place.
***
I have successfully built and run sample files like this under the same
environment.
https://github.com/EttusResearch/uhd/blob/master/host/examples/rx_samples_to_file.cpp
The above sample does not set ipaddr of the usrp device, like this:
("args", po::value<std::string>(&args)->default_value(""), "multi uhd device
address args")
But I want to be able to pass the ipaddr while creating the device.
If the conncted device's ipaddr is not "192.168.10.2", then I want to be told
"not found".
Thank you for reading.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160523/5e5849ae/attachment-0001.html>
------------------------------
Message: 6
Date: Mon, 23 May 2016 11:57:46 -0400
From: devin kelly <[email protected]>
To: usrp-users <[email protected]>
Subject: [USRP-users] Finding E310 Release Version
Message-ID:
<caanlyua5h2nzx9wn2y4syiq5dspq-xx5p7cyxz1lqvm3ng3...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
A co-worker (who's out this week) gave me an E310 to use. He didn't tell
me the release version/number on the SD card. Is there any way to figure
this out?
If it helps here's the output from uname -a
Linux e310-02 3.14.2-xilinx #1 SMP PREEMPT Tue Apr 21 06:51:07 EDT 2015
armv7l GNU/Linux
e310-02 is the hostname. Can I estimate the version based on the date
here? That doesn't seem like the most reliable way to do it.
Thanks,
Devin
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160523/498dc98c/attachment-0001.html>
------------------------------
Subject: Digest Footer
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
End of USRP-users Digest, Vol 69, Issue 23
******************************************
