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. E1XX updates, strike 2 (Philip Balister)
2. Re: Purpose of 24-bit CORDIC in DDC chain? (Florian Schlembach)
3. Re: High CPU utilization (100%) when streaming two concurrent
channels regardless of sample rate (Tom Hartley)
4. Re: High CPU utilization (100%) when streaming twoconcurrent
channels regardless of sample rate (Pruitt, Paul N.)
5. Re: Custom Block in FPGA code of USRP N210 (Tom Hartley)
6. Re: Purpose of 24-bit CORDIC in DDC chain? (Ian Buckley)
----------------------------------------------------------------------
Message: 1
Date: Wed, 03 Apr 2013 15:58:52 -0400
From: Philip Balister <[email protected]>
To: "[email protected]" <[email protected]>,
GNURadio Discussion List <[email protected]>
Subject: [USRP-users] E1XX updates, strike 2
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
OK, the bad file causing E110's to hang after updating has been fixed.
You should be able to opkg update; opkg upgrade on both e100 and e110's now.
Sorry for the trouble.
Philip
------------------------------
Message: 2
Date: Thu, 04 Apr 2013 10:00:46 +0200
From: Florian Schlembach <[email protected]>
To: [email protected]
Cc: "[email protected] forum"
<public-public-usrp-users-p6fHTpcPDZaz3Dx2OeFgIA-wOFGN7rlS/M9smdsby/[email protected]>,
Florian Schlembach
<[email protected]>,
public-usrp-users-p6fhtpcpdzaz3dx2oefgia-xmd5yjdbdmrexy1tmh2...@plane.gmane.org
Subject: Re: [USRP-users] Purpose of 24-bit CORDIC in DDC chain?
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
On 04/03/2013 05:40 PM, Johnathan Corgan wrote:
> On Wed, Apr 3, 2013 at 4:48 AM, Florian Schlembach
> <[email protected]> wrote:
>
>> It seems both HB filters are activated by the UHD interface (enable_hb1/2),
>> how is the actual decimation rate fed to both decim_i and hb_i if both are
>> fed through a common wire cic_decim_rate?
>>
>> Is the CIC then actually be activated using decim_rate with multiples of 4?
>
> See the logic in the UHD host code:
>
> https://github.com/EttusResearch/uhd/blob/master/host/lib/usrp/cores/rx_dsp_core_200.cpp#L170
>
> ...to understand how the host code decides how the half-band filters
> and CIC filter are configured.
>
the code in rx_dsp_core_200 (l.174-185) is actually what I was wondering
about. So far, I understood the logic that the first halfband decimates
by a fixed factor and the second takes over the residual decimation of
multiples of two, e.g. decim_rate=8->hb1->4->hb2->1, which is WRONG (I
misunderstood the term second (large) hb which is actually related to
the filter order of the second hb).
In fact, the second half-band is only decimating by another factor of 2.
Hence, the second HB2 serves the purpose of making the passband response
more linear and further suppresses aliasing spectral components implied
by the decimation.
I would now conclude with the following to sum this thread up for others
;-) :
-CIC decimation filter is always activated
-decim_rate equals 4: HB1 enabled, HB2 enabled, CIC-decim=1 (no decimation)
-decim_rate equals 2 (not possible actually): HB1 enabled, HB2 disabled,
CIC-decim=1
-decim_rate multiple of 4: HB1 enabled, HB2 enabled, CIC-decim=decim_rate/4
-decim_rate multiple of 2: HB1 enabled, HB2 disabled, CIC-decim=decim_rate/2
Hence, decim_rate should always be of multiples of four, otherwise you
will get a poor roll-off. Further decimation should take place in software.
Please correct me if I am wrong.
------------------------------
Message: 3
Date: Thu, 4 Apr 2013 09:12:54 -0400
From: Tom Hartley <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] High CPU utilization (100%) when streaming
two concurrent channels regardless of sample rate
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
On Apr 1, 2013, at 11:06 PM, Josh Blum wrote:
>> [...]
>
> This is a four line patch to serialize the conversions, no extra
> threads: http://pastebin.com/0Q2UDB8x
>
> I will try to get back to you in the morning using something with
> condition variables.
>
> -josh
Josh,
This patch appeared within a few hours of the moment I upgraded my prototype to
2-channels and encountered the same problem. The patch solved the problem
immediately for me as well. Is this is the last word about it, or are you
planning to fix it with condition variables or something else?
(Setup: N210R4, BasicRX, Centos 6.1, core 2 duo 2.53GHz, Xilinx 13.4,
custom logic between DDC and packetizer, custom app based on rx_multi_samples,
5MSPS.
GNU C++ version 4.4.6 20110731 (Red Hat 4.4.6-3); Boost_104100;
UHD_003.005.002-41-g587a9586)
Thanks for your vigilance on all these things!
Tom Hartley
University of Massachusetts - Amherst
------------------------------
Message: 4
Date: Thu, 4 Apr 2013 09:22:46 -0400
From: "Pruitt, Paul N." <[email protected]>
To: "Tom Hartley" <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] High CPU utilization (100%) when streaming
twoconcurrent channels regardless of sample rate
Message-ID:
<f82ab11a5a3e584b8a5148146c5475410672e...@0015-its-exmb14.us.saic.com>
Content-Type: text/plain; charset="us-ascii"
> -----Original Message-----
> From: USRP-users [mailto:[email protected]] On Behalf
> Of Tom Hartley
> Josh,
>
> This patch appeared within a few hours of the moment I upgraded my
> prototype to 2-channels and encountered the same problem. The patch
> solved the problem immediately for me as well. Is this is the last
word
> about it, or are you planning to fix it with condition variables or
something
> else?
Tom,
Josh made a branch
https://github.com/EttusResearch/uhd/tree/quiet_reusable_barrier
that contains another, condition variable-based, fix:
https://github.com/EttusResearch/uhd/commit/ac43353e2dc76c22b92d5176eea7
31fe80070fbc
I attempted a very quick test of that yesterday. My results were
inconclusive, but I am not certain that I properly merged the changes
into our baseline. I plan to re-test when I get some spare time.
Josh: Thanks again for your support and responding so quickly with a
fix!
Best regards,
Paul
------------------------------
Message: 5
Date: Thu, 4 Apr 2013 09:35:57 -0400
From: Tom Hartley <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Custom Block in FPGA code of USRP N210
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
I am working on a more detailed document on N210 customization from the
perspective of radar (or any system needing triggering/gating, integration of
digital inputs & outputs). People are welcome to ask me for help or a draft.
Tom Hartley
University of Massachusetts
------------------------------
Message: 6
Date: Thu, 4 Apr 2013 08:31:51 -0700
From: Ian Buckley <[email protected]>
To: Florian Schlembach <[email protected]>
Cc: [email protected], Florian Schlembach
<[email protected]>,
"[email protected] forum"
<public-public-usrp-users-p6fHTpcPDZaz3Dx2OeFgIA-wOFGN7rlS/M9smdsby/[email protected]>,
public-usrp-users-p6fhtpcpdzaz3dx2oefgia-xmd5yjdbdmrexy1tmh2...@plane.gmane.org
Subject: Re: [USRP-users] Purpose of 24-bit CORDIC in DDC chain?
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
On Apr 4, 2013, at 1:00 AM, Florian Schlembach
<[email protected]> wrote:
> On 04/03/2013 05:40 PM, Johnathan Corgan wrote:
>> On Wed, Apr 3, 2013 at 4:48 AM, Florian Schlembach
>> <[email protected]> wrote:
>>
>>> It seems both HB filters are activated by the UHD interface (enable_hb1/2),
>>> how is the actual decimation rate fed to both decim_i and hb_i if both are
>>> fed through a common wire cic_decim_rate?
>>>
>>> Is the CIC then actually be activated using decim_rate with multiples of 4?
>>
>> See the logic in the UHD host code:
>>
>> https://github.com/EttusResearch/uhd/blob/master/host/lib/usrp/cores/rx_dsp_core_200.cpp#L170
>>
>> ...to understand how the host code decides how the half-band filters
>> and CIC filter are configured.
>>
>
>
> the code in rx_dsp_core_200 (l.174-185) is actually what I was wondering
> about. So far, I understood the logic that the first halfband decimates by a
> fixed factor and the second takes over the residual decimation of multiples
> of two, e.g. decim_rate=8->hb1->4->hb2->1, which is WRONG (I misunderstood
> the term second (large) hb which is actually related to the filter order of
> the second hb).
> In fact, the second half-band is only decimating by another factor of 2.
> Hence, the second HB2 serves the purpose of making the passband response more
> linear and further suppresses aliasing spectral components implied by the
> decimation.
> I would now conclude with the following to sum this thread up for others ;-) :
>
> -CIC decimation filter is always activated
> -decim_rate equals 4: HB1 enabled, HB2 enabled, CIC-decim=1 (no decimation)
> -decim_rate equals 2 (not possible actually): HB1 enabled, HB2 disabled,
> CIC-decim=1
> -decim_rate multiple of 4: HB1 enabled, HB2 enabled, CIC-decim=decim_rate/4
> -decim_rate multiple of 2: HB1 enabled, HB2 disabled, CIC-decim=decim_rate/2
>
> Hence, decim_rate should always be of multiples of four, otherwise you will
> get a poor roll-off. Further decimation should take place in software.
>
> Please correct me if I am wrong.
>
>
Florian,
That's a perfectly accurate summary.
------------------------------
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 32, Issue 3
*****************************************
