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: Building git next ([email protected])
2. Re: uhd_rx_cfile.py sample size (Sebastian D?ring )
3. Re: uhd_rx_cfile.py sample size ([email protected])
4. Re: Building git next ([email protected])
5. Re: uhd_rx_cfile.py sample size (Haris KREMO)
6. Re: uhd_rx_cfile.py sample size (Sebastian D?ring )
7. Re: uhd_rx_cfile.py sample size (Haris KREMO)
----------------------------------------------------------------------
Message: 1
Date: Wed, 28 Mar 2012 12:22:24 -0400
From: [email protected]
To: <[email protected]>
Subject: Re: [USRP-users] Building git next
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
You host-side UHD version is about 1 month behind. The latest
commit on "next" is tagged:
40884c9411bf7d4bc91d24c939c22a3a04193d82
On Wed, 28 Mar 2012 17:50:00 +0200, [email protected] wrote:
>
Hi,
>
> I'm trying to build git next and have sucessfully build
firmware/fpga/host driver
> but hitting a roadblock when trying to
interact with the device.
>
> For some reason I can't get the versions
to match up. I'm using branch next.
> The FPGA code is built on windows,
everything else on linux.
>
> This is the Error from kal:
>
> linux;
GNU C++ version 4.6.1; Boost_104601; UHD_003.004.000-307-gb61f4ad6
>
>
-- Opening a USRP2/N-Series device...
> terminate called after throwing
an instance of 'uhd::runtime_error'
> what(): RuntimeError:
> Please
update the firmware and FPGA images for your device.
> See the
application notes for USRP2/N-Series for instructions.
> Expected
protocol compatibility number [7 to 11], but got 12:
> The firmware
build is not compatible with the host code build.
>
> Any insight on
what I'm missing?
>
> _______________________________________________
>
USRP-users mailing list
> [email protected] [1]
>
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com [2]
Links:
------
[1] mailto:[email protected]
[2]
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/20120328/5c1f55ce/attachment-0001.html>
------------------------------
Message: 2
Date: Wed, 28 Mar 2012 18:30:24 +0200
From: "Sebastian D?ring " <[email protected]>
To: <[email protected]>, <[email protected]>
Subject: Re: [USRP-users] uhd_rx_cfile.py sample size
Message-ID: <[email protected]>
Content-Type: text/plain;charset=utf-8; format="flowed"
On Wed, 28 Mar 2012 09:59:48 -0400
[email protected] wrote:
>
>
> On Wed, 28 Mar 2012 15:18:42 +0200, Sebastian D?ring
>wrote:
>
>>
> Hello,
>>
>> I discovered that uhd_rx_cfile.py is giving me different
>>
> data depending on the number of samples I take from a
>> certain
> constant bandwidth of noise only samples.
>> In theory the noise power
> calculated from these samples is
>> supposed to get more accurate the
> more samples I take,
>> but the more samples I take, the higher the noise
> power
>> value gets ( for example several dB after doubling the
>>
> number of samples).
>>
>> Any hints are highly appreciated.
>> Thanks.
>>
>
>> -Sebastian
>>
>> _______________________________________________
>>
> USRP-users mailing list
>> [email protected] [1]
>>
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> [2]
>
> uhd_rx_cfile.py by default writes complex-float samples,
>so that's
> the first thing you need to make sure you're handling
>correctly.
>
>
> Secondly, how are you computing the noise power across
>the bandwidth
> represented by the samples?
>
> Since they're complex samples, you should
> be calculating, roughly:
>
> power = AVG(I**2 + Q**2)
>
That?s exactly what I am doing except I am also computing
the FFT before computing the suared magnitude to get the
spectral power.
>
>
>
> Links:
> ------
> [1] mailto:[email protected]
> [2]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
Message: 3
Date: Wed, 28 Mar 2012 12:33:32 -0400
From: [email protected]
To: Sebastian D?ring <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] uhd_rx_cfile.py sample size
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
If you're averaging, (like with a single-pole IIR filter), then it
takes a while for the average to "grow" to a stable value before it
stabilizes.
I do received-power calculations all the time, and they
don't grow without bound. You're just processing something incorrectly.
-Marcus
On Wed, 28 Mar 2012 18:30:24 +0200, Sebastian D?ring wrote:
> On Wed, 28 Mar 2012 09:59:48 -0400
> [email protected] [3] wrote:
>>
On Wed, 28 Mar 2012 15:18:42 +0200, Sebastian D?ring wrote:
>>
>>>
>>
Hello,
>>
>>> I discovered that uhd_rx_cfile.py is giving me
different
>> data depending on the number of samples I take from a :5px;
bor
>> 0ff 2px solid; margin-left:5px; width:100%">In theory the noise
power calculated from these samples is va
>> r example several dB after
doubling the number of samples). -Sebastian
_______________________________
>>
>>> rder-left:#1010ff 2px solid;
margin-left:5px; width:100%">
>>
o:[email protected]">[email protected] [1]
http://lists.ettus.c
>>
>>> mples, so that's the first thing you need
to
>> 're handling correctly. Secondly, how are you computing the noise
power across the bandwidth
>>
>>> er = AVG(I**2 + Q**2)
>>
>>>
>
That?s exactly what I am doing except I am also computing the FFT before
computing the suared magnitude to get the spectral power.
>
>> Links:
------ [1] mailto:[email protected] [1] [2]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com [2]
Links:
------
[1] mailto:[email protected]
[2]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
[3]
mailto:[email protected]
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120328/b00e1c0a/attachment-0001.html>
------------------------------
Message: 4
Date: Wed, 28 Mar 2012 22:35:41 +0200
From: "[email protected]" <[email protected]>
To: [email protected], [email protected]
Subject: Re: [USRP-users] Building git next
Message-ID: <[email protected]>
Content-Type: text/plain; charset="UTF-8"
Thanks.
I've finally found a stale copy of the uhd library that was lurking and waiting
to troll me.
-----Original-Nachricht-----
Von: [email protected]
An: <[email protected]>
Betreff: Re: [USRP-users] Building git next
Datum: Wed, 28 Mar 2012 18:22:24 +0200
You host-side UHD version is about 1 month behind. The latest commit
on "next" is tagged:
40884c9411bf7d4bc91d24c939c22a3a04193d82
On Wed, 28 Mar 2012 17:50:00 +0200, [email protected] wrote:
Hi, I'm trying to build git next and have sucessfully build
firmware/fpga/host driver but hitting a roadblock when trying to
interact with the device. For some reason I can't get the versions to
match up. I'm using branch next. The FPGA code is built on windows,
everything else on linux. This is the Error from kal: linux; GNU C++
version 4.6.1; Boost_104601; UHD_003.004.000-307-gb61f4ad6 -- Opening
a USRP2/N-Series device... terminate called after throwing an instance
of 'uhd::runtime_error' what(): RuntimeError: Please update the
firmware and FPGA images for your device. See the application notes
for USRP2/N-Series for instructions. Expected protocol compatibility
number [7 to 11], but got 12: The firmware build is not compatible
with the host code build. Any insight on what I'm missing?
_______________________________________________ USRP-users mailing
list [email protected] [1]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com [2]
Links:
------
[1] mailto:[email protected]
[2] http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
Message: 5
Date: Thu, 29 Mar 2012 14:40:33 +0900
From: Haris KREMO <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] uhd_rx_cfile.py sample size
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
Sebastian,
Are you sure that the bandwidth is not changed when you change the
sample rate?
I hope I am looking into a proper version here, but note the parentheses
below:
http://gnuradio.org/redmine/projects/gnuradio/repository/revisions/50646fa13731ce8dd6382a0f54766d839e634fc5/entry/gr-uhd/apps/uhd_rx_cfile.py#L113
parser.add_option("", "--samp-rate", type="eng_float", default=1e6,
help="set sample rate (bandwidth) [default=%default]")
In any case, is there any consistency in the increase? If the noise
power grows by 3 dB when you double the sampling rate (kTB formula) than
the bandwidth is somehow doubled as well.
Hope it helps,
H.
On 3/29/2012 1:33 AM, [email protected] wrote:
>
> If you're averaging, (like with a single-pole IIR filter), then it
> takes a while for the average to "grow" to a stable value before it
> stabilizes.
>
> I do received-power calculations all the time, and they don't grow
> without bound. You're just processing something incorrectly.
>
> -Marcus
>
> On Wed, 28 Mar 2012 18:30:24 +0200, Sebastian D?ring wrote:
>
>> On Wed, 28 Mar 2012 09:59:48 -0400
>> [email protected] <mailto:[email protected]> wrote:
>>> On Wed, 28 Mar 2012 15:18:42 +0200, Sebastian D?ring wrote:
>>> Hello,
>>>> I discovered that uhd_rx_cfile.py is giving me different
>>> data depending on the number of samples I take from a
>>>> certain
>>> constant bandwidth of noise only samples.
>>>> In theory the noise power
>>> calculated from these samples is
>>>> supposed to get more accurate the
>>> more samples I take,
>>>> but the more samples I take, the higher the noise
>>> power
>>>> value gets ( for example several dB after doubling the
>>> number of samples).
>>>> Any hints are highly appreciated. Thanks.
>>>> -Sebastian _______________________________________________
>>> USRP-users mailing list
>>>> [email protected] <mailto:[email protected]> [1]
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>> [2] uhd_rx_cfile.py by default writes complex-float samples, so
>>> that's the first thing you need to make sure you're handling
>>> correctly. Secondly, how are you computing the noise power across
>>> the bandwidth represented by the samples? Since they're complex
>>> samples, you should be calculating, roughly: power = AVG(I**2 + Q**2)
>>
>> That?s exactly what I am doing except I am also computing
>> the FFT before computing the suared magnitude to get the
>> spectral power.
>>
>>> Links: ------ [1] mailto:[email protected]
>>> <mailto:[email protected]> [2]
>>> 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/20120329/f94a21ce/attachment-0001.html>
------------------------------
Message: 6
Date: Thu, 29 Mar 2012 08:19:21 +0200
From: "Sebastian D?ring " <[email protected]>
To: "Haris KREMO" <[email protected]>,
<[email protected]>
Subject: Re: [USRP-users] uhd_rx_cfile.py sample size
Message-ID: <[email protected]>
Content-Type: text/plain;charset=iso-8859-1; format="flowed"
On Thu, 29 Mar 2012 14:40:33 +0900
Haris KREMO <[email protected]> wrote:
> Sebastian,
>
> Are you sure that the bandwidth is not changed when you
>change the sample rate?
I am not talking about the sample rate but number of
samples taken (N).
The sample rate stays the same. It's just the resolution
of the spectrum that changes.
>
> I hope I am looking into a proper version here, but note
>the parentheses below:
>
> http://gnuradio.org/redmine/projects/gnuradio/repository/revisions/50646fa13731ce8dd6382a0f54766d839e634fc5/entry/gr-uhd/apps/uhd_rx_cfile.py#L113
>
> parser.add_option("", "--samp-rate", type="eng_float",
>default=1e6,
> help="set sample rate (bandwidth)
>[default=%default]")
>
> In any case, is there any consistency in the increase?
>If the noise power grows by 3 dB when you double the
>sampling rate (kTB formula) than the bandwidth is somehow
>doubled as well.
>
> Hope it helps,
>
> H.
>
> On 3/29/2012 1:33 AM, [email protected] wrote:
>>
>> If you're averaging, (like with a single-pole IIR
>>filter), then it takes a while for the average to "grow"
>>to a stable value before it stabilizes.
>>
>> I do received-power calculations all the time, and they
>>don't grow without bound. You're just processing
>>something incorrectly.
>>
>> -Marcus
>>
>> On Wed, 28 Mar 2012 18:30:24 +0200, Sebastian D?ring
>>wrote:
>>
>>> On Wed, 28 Mar 2012 09:59:48 -0400
>>> [email protected] <mailto:[email protected]> wrote:
>>>> On Wed, 28 Mar 2012 15:18:42 +0200, Sebastian D?ring
>>>>wrote:
>>>> Hello,
>>>>> I discovered that uhd_rx_cfile.py is giving me different
>>>> data depending on the number of samples I take from a
>>>>> certain
>>>> constant bandwidth of noise only samples.
>>>>> In theory the noise power
>>>> calculated from these samples is
>>>>> supposed to get more accurate the
>>>> more samples I take,
>>>>> but the more samples I take, the higher the noise
>>>> power
>>>>> value gets ( for example several dB after doubling the
>>>> number of samples).
>>>>> Any hints are highly appreciated. Thanks. -Sebastian
>>>>>_______________________________________________
>>>> USRP-users mailing list
>>>>> [email protected]
>>>>><mailto:[email protected]> [1]
>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>[2] uhd_rx_cfile.py by default writes complex-float
>>>>samples, so that's the first thing you need to make sure
>>>>you're handling correctly. Secondly, how are you
>>>>computing the noise power across the bandwidth
>>>>represented by the samples? Since they're complex
>>>>samples, you should be calculating, roughly: power =
>>>>AVG(I**2 + Q**2)
>>>
>>> That?s exactly what I am doing except I am also
>>>computing
>>> the FFT before computing the suared magnitude to get the
>>> spectral power.
>>>
>>>> Links: ------ [1] mailto:[email protected]
>>>><mailto:[email protected]> [2]
>>>>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: 7
Date: Thu, 29 Mar 2012 15:33:13 +0900
From: Haris KREMO <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] uhd_rx_cfile.py sample size
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
In that case I have one more guess:
Discrete version of the Parseval's theorem has factor of 1/N on the
frequency side. If you are averaging over FFT and dividing only with the
number of samples N instead of 1/N^2 that might be the problem.
H.
On 3/29/2012 3:19 PM, Sebastian D?ring wrote:
> On Thu, 29 Mar 2012 14:40:33 +0900
> Haris KREMO <[email protected]> wrote:
>> Sebastian,
>>
>> Are you sure that the bandwidth is not changed when you change the
>> sample rate?
>
> I am not talking about the sample rate but number of samples taken (N).
> The sample rate stays the same. It's just the resolution of the
> spectrum that changes.
>
>>
>> I hope I am looking into a proper version here, but note the
>> parentheses below:
>>
>> http://gnuradio.org/redmine/projects/gnuradio/repository/revisions/50646fa13731ce8dd6382a0f54766d839e634fc5/entry/gr-uhd/apps/uhd_rx_cfile.py#L113
>>
>>
>>
>> parser.add_option("", "--samp-rate", type="eng_float", default=1e6,
>> help="set sample rate (bandwidth) [default=%default]")
>>
>> In any case, is there any consistency in the increase? If the noise
>> power grows by 3 dB when you double the sampling rate (kTB formula)
>> than the bandwidth is somehow doubled as well.
>>
>> Hope it helps,
>>
>> H.
>>
>> On 3/29/2012 1:33 AM, [email protected] wrote:
>>>
>>> If you're averaging, (like with a single-pole IIR filter), then it
>>> takes a while for the average to "grow" to a stable value before it
>>> stabilizes.
>>>
>>> I do received-power calculations all the time, and they don't grow
>>> without bound. You're just processing something incorrectly.
>>>
>>> -Marcus
>>>
>>> On Wed, 28 Mar 2012 18:30:24 +0200, Sebastian D?ring wrote:
>>>
>>>> On Wed, 28 Mar 2012 09:59:48 -0400
>>>> [email protected] <mailto:[email protected]> wrote:
>>>>> On Wed, 28 Mar 2012 15:18:42 +0200, Sebastian D?ring wrote:
>>>>> Hello,
>>>>>> I discovered that uhd_rx_cfile.py is giving me different
>>>>> data depending on the number of samples I take from a
>>>>>> certain
>>>>> constant bandwidth of noise only samples.
>>>>>> In theory the noise power
>>>>> calculated from these samples is
>>>>>> supposed to get more accurate the
>>>>> more samples I take,
>>>>>> but the more samples I take, the higher the noise
>>>>> power
>>>>>> value gets ( for example several dB after doubling the
>>>>> number of samples).
>>>>>> Any hints are highly appreciated. Thanks. -Sebastian
>>>>>> _______________________________________________
>>>>> USRP-users mailing list
>>>>>> [email protected] <mailto:[email protected]> [1]
>>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>> [2] uhd_rx_cfile.py by default writes complex-float samples, so
>>>>> that's the first thing you need to make sure you're handling
>>>>> correctly. Secondly, how are you computing the noise power across
>>>>> the bandwidth represented by the samples? Since they're complex
>>>>> samples, you should be calculating, roughly: power = AVG(I**2 + Q**2)
>>>>
>>>> That?s exactly what I am doing except I am also computing
>>>> the FFT before computing the suared magnitude to get the
>>>> spectral power.
>>>>
>>>>> Links: ------ [1] mailto:[email protected]
>>>>> <mailto:[email protected]> [2]
>>>>> 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
End of USRP-users Digest, Vol 19, Issue 29
******************************************
