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: E310 filter configuration (Yake Li)
2. Re: OpenOFDM: FPGA Implementation of 802.11a/g/n Decoder
(Jinghao Shi)
3. Cross compiling custom blocks on E310 (Jessica Iwamoto)
4. Re: Cross compiling custom blocks on E310 (Philip Balister)
5. Re: Cross compiling custom blocks on E310 (Jason Matusiak)
6. Re: E310 filter configuration (Kyeong Su Shin)
7. Re: Cross compiling custom blocks on E310 (Jessica Iwamoto)
8. Re: B200mini: Rx-Gain from uhd_usrp_probe and manual differ
(Nate Temple)
9. Re: Cross compiling custom blocks on E310 (Jason Matusiak)
10. Re: Cross compiling custom blocks on E310 (Jessica Iwamoto)
11. Re: Cross compiling custom blocks on E310 (Jason Matusiak)
12. Re: Cross compiling custom blocks on E310 (Jessica Iwamoto)
13. Cross correlation(xcorr) of two USRP Rx samples data of B210
and B205mini-i in MATLAB (Farial Nur Maysha)
14. High CPU usage (Vladica Sark)
15. Re: Cross correlation(xcorr) of two USRP Rx samples data of
B210 and B205mini-i in MATLAB (Mike McLernon)
16. Re: LFRX daughterboard with radio block (Barker, Douglas W.)
17. Re: High CPU usage (Gilad Beeri (ApolloShield))
18. Re: High CPU usage (Vladica Sark)
19. Re: High CPU usage (Claudio Cicconetti)
----------------------------------------------------------------------
Message: 1
Date: Tue, 9 May 2017 14:21:38 -0230
From: "Yake Li" <[email protected]>
To: "'Rob Kossler'" <[email protected]>, "'Marcus D. Leech'"
<[email protected]>
Cc: <[email protected]>
Subject: Re: [USRP-users] E310 filter configuration
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
Please see attached the results. I sent two identical pulses (1 us width in
time and roughly 2.5 MHz bandwidth in freq domain) which have 2.03 GHz center
frequency. The sampling rate is 6 MS/s. Fig1 is the result when I tuned the Rx
LO to 2.028 GHz (I notice the filter before ADC passes signal above 1 MHz, so I
set IF to be 2 MHz). Fig2 is the result if I tune the Rx LO to be 2.0 GHZ
(30MHz IF). I did not use set_bandwidth() command in both cases. In my
understanding, if the 30 MHz IF signal passed the filter before ADC, I should
be able to sample it using 6 MHz because the bandwidth is only 2.5MHz. But as
shown by the figure, the amplitude is suppressed, unbalanced and artificial is
presented. I guess the problem could be the filters.
From: Rob Kossler [mailto:[email protected]]
Sent: May 9, 2017 1:23 PM
To: Marcus D. Leech <[email protected]>
Cc: Yake Li <[email protected]>; [email protected]
Subject: Re: [USRP-users] E310 filter configuration
Typo in my message. I meant to say set the sample rate to 6e6 as you indicated
originally...
On Tue, May 9, 2017 at 11:14 AM, Rob Kossler <[email protected]
<mailto:[email protected]> > wrote:
Ignoring the set_bandwidth() command, if you set the center freq to 2e9 and the
sample rate to 3e6, your results will show signals in the range 1.997-2.003
GHz. This does not include your desired signal at 2.03 GHz, which is 30 MHz
away from 2 GHz.
Rob
On Tue, May 9, 2017 at 11:05 AM, Marcus D. Leech via USRP-users
<[email protected] <mailto:[email protected]> > wrote:
The "set_bandwidth" method sets the analog bandwidth in front of the ADC.
The RF filters are selected automatically based on your desired tuning
frequency.
It would help us if you describe how the result is "incorrect" -- perhaps an
FFT plot?
On 2017-05-09 10:50, Yake Li via USRP-users wrote:
Hello,
My question is could I set the filters separately in Ettus E310? I noticed
there are different filters in E310. First, there are filter banks right after
the receiving antenna. Second, the AD9361 has Rx low pass filters before ADC
(please refer to ?Rx SIGNAL PATH? of
http://www.farnell.com/datasheets/2007082.pdf). I noticed there is only one
command ?set_bandwidth? in gnuradio (or ?set_rx_bandwidth? in UHD) to set the
RF bandwidth of front end. What is the response of each filters mentioned above
after using this command? Could I set separately the response of different
filters?
I am asking because I want to, for example, sample a signal centered at 2.03
GHz with 3M Hz bandwidth. I tune the LO of Rx to 2 GHz, and I want to sample
this signal with 6 MHz sampling rate. What I did is that I use ?set_center_freq
(2e9,0)?, ?set_bandwidth (3e6,0)? and ?set_samp_rate (6e6,0)?. The result seems
to be incorrect. I tried different bandwidth, and under no settings I got the
right result. Is there something wrong with my settings?
Thanks!
Yake
<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient>
Virus-free.
<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient>
www.avast.com
_______________________________________________
USRP-users mailing list
<mailto:[email protected]> [email protected]
<http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com>
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
_______________________________________________
USRP-users mailing list
[email protected] <mailto:[email protected]>
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170509/51708163/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fig1.jpg
Type: image/jpeg
Size: 21728 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170509/51708163/attachment-0002.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fig2.jpg
Type: image/jpeg
Size: 18412 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170509/51708163/attachment-0003.jpg>
------------------------------
Message: 2
Date: Tue, 9 May 2017 13:06:51 -0400
From: Jinghao Shi <[email protected]>
To: Jonathon Pendlum <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] OpenOFDM: FPGA Implementation of 802.11a/g/n
Decoder
Message-ID:
<cakdw-hgrdfxa+xu2iyby95ae9fqv0hbsmy7aef98alj8ew6...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Thanks. For now, I do not have a plan to port it to RFNoC. The
OpenOFDM project originated from a project based on USRP N210, leading
to its current form. Looking back, if I were to do this again, I'd
probably go with RFNoC for better extensibility. I do hope this
project can help anybody working on RFNoC as well.
Thanks,
Jinghao
On Wed, May 3, 2017 at 3:44 PM, Jonathon Pendlum
<[email protected]> wrote:
> Very cool! Have you given any thought to doing a RFNoC implementation?
>
> On Wed, May 3, 2017 at 2:11 PM, Jinghao Shi via USRP-users
> <[email protected]> wrote:
>>
>> Hi USRP community,
>>
>> In one of our research projects, we have implemented a 802.11a/g/n
>> decoder on the FPGA of USRP N210 platform. It can decode 802.11
>> packets in real-time and pipe bytes (instead of I/Q samples) back to
>> host PC. The source code is available on Github at
>> https://github.com/jhshi/openofdm. For more details, please refer to
>> the documentation at http://openofdm.readthedocs.io/.
>>
>> We hope the project is useful to those who are working on real-time
>> 802.11 applications on USRP platforms. Please use Github issues for
>> comments and suggestions. All are welcome.
>>
>>
>> Thanks,
>> Jinghao
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected]
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
------------------------------
Message: 3
Date: Tue, 9 May 2017 17:24:02 +0000
From: Jessica Iwamoto <[email protected]>
To: usrp-users <[email protected]>
Subject: [USRP-users] Cross compiling custom blocks on E310
Message-ID:
<sn1pr09mb10088587218fdd7b72bed8989b...@sn1pr09mb1008.namprd09.prod.outlook.com>
Content-Type: text/plain; charset="us-ascii"
Hi all,
I am trying to build a custom C++ block with a message port and cross compile
it for the E310. I am using version 3.7.12 of GNU radio and the latest version
of the SDK/toolchain for the E310. I have built a simple message sink block
that just has a message input port and put it in a flowgraph with a message
strobe. My code runs fine on my PC but when I run it on the E310, I get the
error:
Could not find port: msg in:
system
Bus error
When I step through the code in a debugger, it seems to be getting stuck when
the block checks if there is a valid message port. However, when I run the
following in python, it seems like the block is being created correctly, with
the message port (named msg):
>import pmt
>import custom_module
>blk = custom_module.msg_sink()
>blk.message_ports_in()
#(msg system)
I am able to create custom python blocks with message ports with no issues. Any
suggestions on what could be causing this?
Thanks,
Jessica
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170509/5eb5d1a3/attachment-0001.html>
------------------------------
Message: 4
Date: Tue, 9 May 2017 11:33:02 -0600
From: Philip Balister <[email protected]>
To: Jessica Iwamoto <[email protected]>, usrp-users
<[email protected]>
Subject: Re: [USRP-users] Cross compiling custom blocks on E310
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
On 05/09/2017 11:24 AM, Jessica Iwamoto via USRP-users wrote:
> Hi all,
>
> I am trying to build a custom C++ block with a message port and cross compile
> it for the E310. I am using version 3.7.12 of GNU radio and the latest
> version of the SDK/toolchain for the E310. I have built a simple message sink
> block that just has a message input port and put it in a flowgraph with a
> message strobe. My code runs fine on my PC but when I run it on the E310, I
> get the error:
> Could not find port: msg in:
> system
> Bus error
>
> When I step through the code in a debugger, it seems to be getting stuck when
> the block checks if there is a valid message port. However, when I run the
> following in python, it seems like the block is being created correctly, with
> the message port (named msg):
>> import pmt
>> import custom_module
>> blk = custom_module.msg_sink()
>> blk.message_ports_in()
> #(msg system)
>
> I am able to create custom python blocks with message ports with no issues.
> Any suggestions on what could be causing this?
Does the C++ block work on a desktop? It might be easier to debug there.
Philip
>
> Thanks,
> Jessica
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Message: 5
Date: Tue, 9 May 2017 13:44:50 -0400
From: Jason Matusiak <[email protected]>
To: Jessica Iwamoto <[email protected]>, usrp-users
<[email protected]>
Subject: Re: [USRP-users] Cross compiling custom blocks on E310
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="windows-1252"; Format="flowed"
This means you have an issue with your GNURadio side of things. I ran
into a similar problem when doing an RFNoC block, but the answer was
fixing my C++ code (of which I did not touch at all). This post was
what helped me along:
http://lists.gnu.org/archive/html/discuss-gnuradio/2017-05/msg00015.html
On 05/09/2017 01:24 PM, Jessica Iwamoto via USRP-users wrote:
>
> Hi all,
>
> I am trying to build a custom C++ block with a message port and cross
> compile it for the E310. I am using version 3.7.12 of GNU radio and
> the latest version of the SDK/toolchain for the E310. I have built a
> simple message sink block that just has a message input port and put
> it in a flowgraph with a message strobe. My code runs fine on my PC
> but when I run it on the E310, I get the error:
>
> Could not find port: msg in:
>
> system
>
> Bus error
>
> When I step through the code in a debugger, it seems to be getting
> stuck when the block checks if there is a valid message port. However,
> when I run the following in python, it seems like the block is being
> created correctly, with the message port (named msg):
>
> >import pmt
>
> >import custom_module
>
> >blk = custom_module.msg_sink()
>
> >blk.message_ports_in()
>
> #(msg system)
>
> I am able to create custom python blocks with message ports with no
> issues. Any suggestions on what could be causing this?
>
> Thanks,
>
> Jessica
>
>
>
> _______________________________________________
> 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/20170509/c6deedfb/attachment-0001.html>
------------------------------
Message: 6
Date: Tue, 9 May 2017 10:59:12 -0700
From: Kyeong Su Shin <[email protected]>
To: Ettus mail list <[email protected]>
Subject: Re: [USRP-users] E310 filter configuration
Message-ID:
<CAGL0V3=0tar06tpbnpj3db-1-5v2dcpxgcf352gtag9ssq9...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Dear Yake Li:
How are you setting that IF stage? I don't use E310, so I am not sure what
E310 is capable of, but AD9361 is a homodyne transceiver, and your commands
in the earlier post do not suggest to me that you are setting the
low-frequency (DSP-level) IF stage either. I believe it is just receiving
2GHz +- 3MHz, as Rob Kossler suggested, not 2.030GHz.
Regards,
Kyeong Su Shin
On Tue, May 9, 2017 at 9:51 AM, Yake Li via USRP-users <
[email protected]> wrote:
> Please see attached the results. I sent two identical pulses (1 us width
> in time and roughly 2.5 MHz bandwidth in freq domain) which have 2.03 GHz
> center frequency. The sampling rate is 6 MS/s. Fig1 is the result when I
> tuned the Rx LO to 2.028 GHz (I notice the filter before ADC passes signal
> above 1 MHz, so I set IF to be 2 MHz). Fig2 is the result if I tune the Rx
> LO to be 2.0 GHZ (30MHz IF). I did not use set_bandwidth() command in both
> cases. In my understanding, if the 30 MHz IF signal passed the filter
> before ADC, I should be able to sample it using 6 MHz because the bandwidth
> is only 2.5MHz. But as shown by the figure, the amplitude is suppressed,
> unbalanced and artificial is presented. I guess the problem could be the
> filters.
>
>
>
> *From:* Rob Kossler [mailto:[email protected]]
> *Sent:* May 9, 2017 1:23 PM
> *To:* Marcus D. Leech <[email protected]>
> *Cc:* Yake Li <[email protected]>; [email protected]
> *Subject:* Re: [USRP-users] E310 filter configuration
>
>
>
> Typo in my message. I meant to say set the sample rate to 6e6 as you
> indicated originally...
>
>
>
>
>
> On Tue, May 9, 2017 at 11:14 AM, Rob Kossler <[email protected]> wrote:
>
> Ignoring the set_bandwidth() command, if you set the center freq to 2e9
> and the sample rate to 3e6, your results will show signals in the range
> 1.997-2.003 GHz. This does not include your desired signal at 2.03 GHz,
> which is 30 MHz away from 2 GHz.
>
>
>
> Rob
>
>
>
>
>
> On Tue, May 9, 2017 at 11:05 AM, Marcus D. Leech via USRP-users <
> [email protected]> wrote:
>
> The "set_bandwidth" method sets the analog bandwidth in front of the ADC.
>
> The RF filters are selected automatically based on your desired tuning
> frequency.
>
> It would help us if you describe how the result is "incorrect" -- perhaps
> an FFT plot?
>
>
>
>
>
>
>
> On 2017-05-09 10:50, Yake Li via USRP-users wrote:
>
> Hello,
>
>
>
> My question is could I set the filters separately in Ettus E310? I
> noticed there are different filters in E310. First, there are filter banks
> right after the receiving antenna. Second, the AD9361 has Rx low pass
> filters before ADC (please refer to ?*Rx SIGNAL PATH*? of
> http://www.farnell.com/datasheets/2007082.pdf). I noticed there is only
> one command ?set_bandwidth? in gnuradio (or ?set_rx_bandwidth? in UHD) to
> set the RF bandwidth of front end. What is the response of each filters
> mentioned above after using this command? Could I set separately the
> response of different filters?
>
>
>
> I am asking because I want to, for example, sample a signal centered at
> 2.03 GHz with 3M Hz bandwidth. I tune the LO of Rx to 2 GHz, and I want to
> sample this signal with 6 MHz sampling rate. What I did is that I use
> ?set_center_freq (2e9,0)?, ?set_bandwidth (3e6,0)? and ?set_samp_rate
> (6e6,0)?. The result seems to be incorrect. I tried different bandwidth,
> and under no settings I got the right result. Is there something wrong with
> my settings?
>
>
>
> Thanks!
>
>
>
> Yake
>
>
>
> [image:
> https://ipmcdn.avast.com/images/icons/icon-envelope-tick-round-orange-animated-no-repeat-v1.gif]
> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient>
>
> Virus-free. www.avast.com
> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient>
>
>
>
> _______________________________________________
> 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/20170509/48852b55/attachment-0001.html>
------------------------------
Message: 7
Date: Tue, 9 May 2017 18:08:45 +0000
From: Jessica Iwamoto <[email protected]>
To: Philip Balister <[email protected]>, usrp-users
<[email protected]>
Subject: Re: [USRP-users] Cross compiling custom blocks on E310
Message-ID:
<sn1pr09mb100885568b7125379d7459df9b...@sn1pr09mb1008.namprd09.prod.outlook.com>
Content-Type: text/plain; charset="us-ascii"
Yes, the C++ block works on my desktop. The problem occurs only when I try to
use the C++ block on the E310.
Jessica
-----Original Message-----
From: Philip Balister [mailto:[email protected]]
Sent: Tuesday, May 9, 2017 10:33 AM
To: Jessica Iwamoto <[email protected]>; usrp-users
<[email protected]>
Subject: Re: [USRP-users] Cross compiling custom blocks on E310
On 05/09/2017 11:24 AM, Jessica Iwamoto via USRP-users wrote:
> Hi all,
>
> I am trying to build a custom C++ block with a message port and cross compile
> it for the E310. I am using version 3.7.12 of GNU radio and the latest
> version of the SDK/toolchain for the E310. I have built a simple message sink
> block that just has a message input port and put it in a flowgraph with a
> message strobe. My code runs fine on my PC but when I run it on the E310, I
> get the error:
> Could not find port: msg in:
> system
> Bus error
>
> When I step through the code in a debugger, it seems to be getting stuck when
> the block checks if there is a valid message port. However, when I run the
> following in python, it seems like the block is being created correctly, with
> the message port (named msg):
>> import pmt
>> import custom_module
>> blk = custom_module.msg_sink()
>> blk.message_ports_in()
> #(msg system)
>
> I am able to create custom python blocks with message ports with no issues.
> Any suggestions on what could be causing this?
Does the C++ block work on a desktop? It might be easier to debug there.
Philip
>
> Thanks,
> Jessica
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Message: 8
Date: Tue, 9 May 2017 11:23:11 -0700
From: Nate Temple <[email protected]>
To: [email protected]
Cc: Zhihong Luo via USRP-users <[email protected]>
Subject: Re: [USRP-users] B200mini: Rx-Gain from uhd_usrp_probe and
manual differ
Message-ID:
<CAL263iwBGk8Y6mffLEqtJ1NAnqch=udvcuswy2uhkl-k7qq...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Emanuel,
Yes, that was a typo.The KB has been updated. Thank you for highlighting it.
Regards,
Nate Temple
On Mon, May 8, 2017 at 2:38 AM, Emanuel via USRP-users <
[email protected]> wrote:
> Hello to everyone,
>
>
>
> I had a look at the B200mini manual and knowledge base (KB) for the
> maximum RX-Gain: the manual states +73dB as maximum, as well as the KB.
> However, uhd_usrp_probe returns a maximum RX-gain of +76dB.
>
> Does someone know where this difference comes from? Maybe a typo?
>
>
>
> Regards,
>
> Emanuel
>
> _______________________________________________
> 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/20170509/18c3972e/attachment-0001.html>
------------------------------
Message: 9
Date: Tue, 9 May 2017 14:39:13 -0400
From: Jason Matusiak <[email protected]>
To: Jessica Iwamoto <[email protected]>, usrp-users
<[email protected]>
Subject: Re: [USRP-users] Cross compiling custom blocks on E310
Message-ID:
<[email protected]>
Content-Type: text/plain; charset=windows-1252; format=flowed
Jessica, when you cross-compiled your C++ code, did you install it into
the proper directory on the E310?
~Jason
On 05/09/2017 02:08 PM, Jessica Iwamoto via USRP-users wrote:
> Yes, the C++ block works on my desktop. The problem occurs only when I try to
> use the C++ block on the E310.
>
> Jessica
>
> -----Original Message-----
> From: Philip Balister [mailto:[email protected]]
> Sent: Tuesday, May 9, 2017 10:33 AM
> To: Jessica Iwamoto <[email protected]>; usrp-users
> <[email protected]>
> Subject: Re: [USRP-users] Cross compiling custom blocks on E310
>
> On 05/09/2017 11:24 AM, Jessica Iwamoto via USRP-users wrote:
>> Hi all,
>>
>> I am trying to build a custom C++ block with a message port and cross
>> compile it for the E310. I am using version 3.7.12 of GNU radio and the
>> latest version of the SDK/toolchain for the E310. I have built a simple
>> message sink block that just has a message input port and put it in a
>> flowgraph with a message strobe. My code runs fine on my PC but when I run
>> it on the E310, I get the error:
>> Could not find port: msg in:
>> system
>> Bus error
>>
>> When I step through the code in a debugger, it seems to be getting stuck
>> when the block checks if there is a valid message port. However, when I run
>> the following in python, it seems like the block is being created correctly,
>> with the message port (named msg):
>>> import pmt
>>> import custom_module
>>> blk = custom_module.msg_sink()
>>> blk.message_ports_in()
>> #(msg system)
>>
>> I am able to create custom python blocks with message ports with no issues.
>> Any suggestions on what could be causing this?
> Does the C++ block work on a desktop? It might be easier to debug there.
>
> Philip
>
>> Thanks,
>> Jessica
>>
>>
>>
>> _______________________________________________
>> 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: 10
Date: Tue, 9 May 2017 18:47:45 +0000
From: Jessica Iwamoto <[email protected]>
To: Jason Matusiak <[email protected]>, usrp-users
<[email protected]>
Subject: Re: [USRP-users] Cross compiling custom blocks on E310
Message-ID:
<sn1pr09mb10080ca58ee06e106e6f50b39b...@sn1pr09mb1008.namprd09.prod.outlook.com>
Content-Type: text/plain; charset="us-ascii"
Yes, I think so. I've just been following the instructions here:
https://kb.ettus.com/Software_Development_on_the_E310_and_E312. I created a
prefix on my desktop, installed it to that prefix, and then mounted the prefix
on the E310.
Jessica
-----Original Message-----
From: Jason Matusiak [mailto:[email protected]]
Sent: Tuesday, May 9, 2017 11:39 AM
To: Jessica Iwamoto <[email protected]>; usrp-users
<[email protected]>
Subject: Re: [USRP-users] Cross compiling custom blocks on E310
Jessica, when you cross-compiled your C++ code, did you install it into the
proper directory on the E310?
~Jason
On 05/09/2017 02:08 PM, Jessica Iwamoto via USRP-users wrote:
> Yes, the C++ block works on my desktop. The problem occurs only when I try to
> use the C++ block on the E310.
>
> Jessica
>
> -----Original Message-----
> From: Philip Balister [mailto:[email protected]]
> Sent: Tuesday, May 9, 2017 10:33 AM
> To: Jessica Iwamoto <[email protected]>; usrp-users
> <[email protected]>
> Subject: Re: [USRP-users] Cross compiling custom blocks on E310
>
> On 05/09/2017 11:24 AM, Jessica Iwamoto via USRP-users wrote:
>> Hi all,
>>
>> I am trying to build a custom C++ block with a message port and cross
>> compile it for the E310. I am using version 3.7.12 of GNU radio and the
>> latest version of the SDK/toolchain for the E310. I have built a simple
>> message sink block that just has a message input port and put it in a
>> flowgraph with a message strobe. My code runs fine on my PC but when I run
>> it on the E310, I get the error:
>> Could not find port: msg in:
>> system
>> Bus error
>>
>> When I step through the code in a debugger, it seems to be getting stuck
>> when the block checks if there is a valid message port. However, when I run
>> the following in python, it seems like the block is being created correctly,
>> with the message port (named msg):
>>> import pmt
>>> import custom_module
>>> blk = custom_module.msg_sink()
>>> blk.message_ports_in()
>> #(msg system)
>>
>> I am able to create custom python blocks with message ports with no issues.
>> Any suggestions on what could be causing this?
> Does the C++ block work on a desktop? It might be easier to debug there.
>
> Philip
>
>> Thanks,
>> Jessica
>>
>>
>>
>> _______________________________________________
>> 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: 11
Date: Tue, 9 May 2017 14:49:55 -0400
From: Jason Matusiak <[email protected]>
To: Jessica Iwamoto <[email protected]>, usrp-users
<[email protected]>
Subject: Re: [USRP-users] Cross compiling custom blocks on E310
Message-ID:
<[email protected]>
Content-Type: text/plain; charset=windows-1252; format=flowed
And you are sourcing gnuradio on your E310 to use that new directory
that you mounted? (if so, I might be out of ideas....)
On 05/09/2017 02:47 PM, Jessica Iwamoto wrote:
> Yes, I think so. I've just been following the instructions here:
> https://kb.ettus.com/Software_Development_on_the_E310_and_E312. I created a
> prefix on my desktop, installed it to that prefix, and then mounted the
> prefix on the E310.
>
> Jessica
>
> -----Original Message-----
> From: Jason Matusiak [mailto:[email protected]]
> Sent: Tuesday, May 9, 2017 11:39 AM
> To: Jessica Iwamoto <[email protected]>; usrp-users
> <[email protected]>
> Subject: Re: [USRP-users] Cross compiling custom blocks on E310
>
> Jessica, when you cross-compiled your C++ code, did you install it into the
> proper directory on the E310?
>
> ~Jason
>
> On 05/09/2017 02:08 PM, Jessica Iwamoto via USRP-users wrote:
>> Yes, the C++ block works on my desktop. The problem occurs only when I try
>> to use the C++ block on the E310.
>>
>> Jessica
>>
>> -----Original Message-----
>> From: Philip Balister [mailto:[email protected]]
>> Sent: Tuesday, May 9, 2017 10:33 AM
>> To: Jessica Iwamoto <[email protected]>; usrp-users
>> <[email protected]>
>> Subject: Re: [USRP-users] Cross compiling custom blocks on E310
>>
>> On 05/09/2017 11:24 AM, Jessica Iwamoto via USRP-users wrote:
>>> Hi all,
>>>
>>> I am trying to build a custom C++ block with a message port and cross
>>> compile it for the E310. I am using version 3.7.12 of GNU radio and the
>>> latest version of the SDK/toolchain for the E310. I have built a simple
>>> message sink block that just has a message input port and put it in a
>>> flowgraph with a message strobe. My code runs fine on my PC but when I run
>>> it on the E310, I get the error:
>>> Could not find port: msg in:
>>> system
>>> Bus error
>>>
>>> When I step through the code in a debugger, it seems to be getting stuck
>>> when the block checks if there is a valid message port. However, when I run
>>> the following in python, it seems like the block is being created
>>> correctly, with the message port (named msg):
>>>> import pmt
>>>> import custom_module
>>>> blk = custom_module.msg_sink()
>>>> blk.message_ports_in()
>>> #(msg system)
>>>
>>> I am able to create custom python blocks with message ports with no issues.
>>> Any suggestions on what could be causing this?
>> Does the C++ block work on a desktop? It might be easier to debug there.
>>
>> Philip
>>
>>> Thanks,
>>> Jessica
>>>
>>>
>>>
>>> _______________________________________________
>>> 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: 12
Date: Tue, 9 May 2017 18:55:44 +0000
From: Jessica Iwamoto <[email protected]>
To: Jason Matusiak <[email protected]>, usrp-users
<[email protected]>
Subject: Re: [USRP-users] Cross compiling custom blocks on E310
Message-ID:
<sn1pr09mb1008f8dc5fdcba751e9a24939b...@sn1pr09mb1008.namprd09.prod.outlook.com>
Content-Type: text/plain; charset="us-ascii"
Yes, I am.
-----Original Message-----
From: Jason Matusiak [mailto:[email protected]]
Sent: Tuesday, May 9, 2017 11:50 AM
To: Jessica Iwamoto <[email protected]>; usrp-users
<[email protected]>
Subject: Re: [USRP-users] Cross compiling custom blocks on E310
And you are sourcing gnuradio on your E310 to use that new directory that you
mounted? (if so, I might be out of ideas....)
On 05/09/2017 02:47 PM, Jessica Iwamoto wrote:
> Yes, I think so. I've just been following the instructions here:
> https://kb.ettus.com/Software_Development_on_the_E310_and_E312. I created a
> prefix on my desktop, installed it to that prefix, and then mounted the
> prefix on the E310.
>
> Jessica
>
> -----Original Message-----
> From: Jason Matusiak [mailto:[email protected]]
> Sent: Tuesday, May 9, 2017 11:39 AM
> To: Jessica Iwamoto <[email protected]>; usrp-users
> <[email protected]>
> Subject: Re: [USRP-users] Cross compiling custom blocks on E310
>
> Jessica, when you cross-compiled your C++ code, did you install it into the
> proper directory on the E310?
>
> ~Jason
>
> On 05/09/2017 02:08 PM, Jessica Iwamoto via USRP-users wrote:
>> Yes, the C++ block works on my desktop. The problem occurs only when I try
>> to use the C++ block on the E310.
>>
>> Jessica
>>
>> -----Original Message-----
>> From: Philip Balister [mailto:[email protected]]
>> Sent: Tuesday, May 9, 2017 10:33 AM
>> To: Jessica Iwamoto <[email protected]>; usrp-users
>> <[email protected]>
>> Subject: Re: [USRP-users] Cross compiling custom blocks on E310
>>
>> On 05/09/2017 11:24 AM, Jessica Iwamoto via USRP-users wrote:
>>> Hi all,
>>>
>>> I am trying to build a custom C++ block with a message port and cross
>>> compile it for the E310. I am using version 3.7.12 of GNU radio and the
>>> latest version of the SDK/toolchain for the E310. I have built a simple
>>> message sink block that just has a message input port and put it in a
>>> flowgraph with a message strobe. My code runs fine on my PC but when I run
>>> it on the E310, I get the error:
>>> Could not find port: msg in:
>>> system
>>> Bus error
>>>
>>> When I step through the code in a debugger, it seems to be getting stuck
>>> when the block checks if there is a valid message port. However, when I run
>>> the following in python, it seems like the block is being created
>>> correctly, with the message port (named msg):
>>>> import pmt
>>>> import custom_module
>>>> blk = custom_module.msg_sink()
>>>> blk.message_ports_in()
>>> #(msg system)
>>>
>>> I am able to create custom python blocks with message ports with no issues.
>>> Any suggestions on what could be causing this?
>> Does the C++ block work on a desktop? It might be easier to debug there.
>>
>> Philip
>>
>>> Thanks,
>>> Jessica
>>>
>>>
>>>
>>> _______________________________________________
>>> 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: 13
Date: Tue, 9 May 2017 10:06:52 -0400
From: Farial Nur Maysha <[email protected]>
To: [email protected]
Subject: [USRP-users] Cross correlation(xcorr) of two USRP Rx samples
data of B210 and B205mini-i in MATLAB
Message-ID:
<cani1ikagbezdcusoez-wdm1wrfgdm9sgpcegfnxebvp6vzg...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hello,
I would like to xcorr of the two values of Rx sample data. I have already
opened the binary file of two Rx samples data in Matlab and plotted the
signals. When I tried to xcorr the value of two Rx sample data it cannot
generate the code of xcorr due to the high value of the data. It will be
helpful if anyone can give the right code for xcorr step by step.
Sincerely,
Maysha
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170509/7d0b05f3/attachment-0001.html>
------------------------------
Message: 14
Date: Wed, 10 May 2017 13:50:15 +0200
From: Vladica Sark <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] High CPU usage
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi,
I have an app which transmits 8192 samples each 10 ms on two N210s which
are combined together and seen as 2 channels. The samples are
transmitted as timed samples. After the send command, I wait in
recv_async_msg command, till the samples get transmitted and than I
schedule a new transmission in 10 ms.
The issue is that the CPU utilization is 200%, i.e. 2 cores at 100%.
It does not depend on the sample rate. Tried 10, 25 and 50 MSps.
Of course, no signal processing is involved at this point, only ready
samples are being transmitted.
The machine has a i5 vPro processor with 4 cores.
Any way to reduce this?
BR,
Vladica
------------------------------
Message: 15
Date: Wed, 10 May 2017 12:04:52 +0000
From: Mike McLernon <[email protected]>
To: Farial Nur Maysha <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Cross correlation(xcorr) of two USRP Rx
samples data of B210 and B205mini-i in MATLAB
Message-ID:
<dm2pr05mb4482f7cb3e102078a2c9cc8e9...@dm2pr05mb448.namprd05.prod.outlook.com>
Content-Type: text/plain; charset="iso-8859-1"
Hi Maysha,
I'm not quite sure how to interpret your question, but you can edit the xcorr
file in MATLAB, and debug through the MATLAB code to see how it is calculating
your result.
Hth,
Mike
________________________________
From: USRP-users <[email protected]> on behalf of Farial Nur
Maysha via USRP-users <[email protected]>
Sent: Tuesday, May 09, 2017 10:06 AM
To: [email protected]
Subject: [USRP-users] Cross correlation(xcorr) of two USRP Rx samples data of
B210 and B205mini-i in MATLAB
Hello,
I would like to xcorr of the two values of Rx sample data. I have already
opened the binary file of two Rx samples data in Matlab and plotted the
signals. When I tried to xcorr the value of two Rx sample data it cannot
generate the code of xcorr due to the high value of the data. It will be
helpful if anyone can give the right code for xcorr step by step.
Sincerely,
Maysha
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170510/3fd16cd7/attachment-0001.html>
------------------------------
Message: 16
Date: Wed, 10 May 2017 13:01:17 +0000
From: "Barker, Douglas W." <[email protected]>
To: Jason Matusiak <[email protected]>, Jonathon Pendlum
<[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] LFRX daughterboard with radio block
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
More information - If I change the number of output ports to just 2 it works
just fine. Increasing the ports to 3 and it craps-out as described below. Has
anyone used more than two block ports? This seems to be a UHD/RFNoC bug.
Thanks
Doug
From: Barker, Douglas W.
Sent: Tuesday, May 09, 2017 11:20 AM
To: 'Jason Matusiak'; Jonathon Pendlum
Cc: [email protected]
Subject: RE: [USRP-users] LFRX daughterboard with radio block
Ok, now I get a new error (from gnuradio console output):
...
DEBUG: creating rx streamer with: block_id=0/xxx_0, block_port=0
DEBUG: creating rx streamer with: block_id=0/xxx_0, block_port=1
DEBUG: creating rx streamer with: block_id=0/xxx_0, block_port=2
Thread[thread-per-block(0):<block_uhd_rfnoc_xxx(2)>]:LookupError:keyError:-0/Radio_0[
sr_write():No such port: 2
>>>Done
Does this have something to do with the fact that the software thinks there are
9 input ports?? Is it another xml error?
Doug
From: Jason Matusiak [mailto:[email protected]]
Sent: Tuesday, May 09, 2017 10:48 AM
To: Barker, Douglas W.; Jonathon Pendlum
Cc: [email protected]
Subject: Re: [USRP-users] LFRX daughterboard with radio block
Agreed (on thinking it doesn't actually affect anything). In fact, I know I've
seen it show up on some of the ettus's designed blocks (like fosphor). I was
just hoping you figured out how to make it happy so I could get it to stop
popping up :).
~Jason
On 05/09/2017 10:24 AM, Barker, Douglas W. wrote:
Jason,
No, that warning is still there. I don't think it affects anything though. I
suspect it may come from the way noc_shell is configured with INPUT_PORTS, and
OUTPUT_PORTS and BLOCK_PORTS parameters.
Doug
From: Jason Matusiak [mailto:[email protected]]
Sent: Tuesday, May 09, 2017 10:20 AM
To: Barker, Douglas W.; Jonathon Pendlum
Cc: [email protected]<mailto:[email protected]>
Subject: Re: [USRP-users] LFRX daughterboard with radio block
Doug, were you able to get rid of the ""[WARNING] [RFNOC] [0/xxx_0] defines 9
input buffer sizes, but 1 input ports"" warning? I get it too, but last I saw
it was a pseudo-bug and we just need to ignore it for now.
~Jason
On 05/08/2017 02:37 PM, Barker, Douglas W. via USRP-users wrote:
Hi Jonathon,
Thanks for the reply. uhd_usrp_probe outputs "...
UHD_4.0.0.rfnoc-devel-316-g24b98579 My flowgraph is Radio Block -> Custom Block
-> host. Actually, the custom block has 9 output ports, each of which connect
to the host. I do get a warning when I run the uhd_usrp_probe that indicates
the following:
"[WARNING] [RFNOC] [0/xxx_0] defines 9 input buffer sizes, but 1 input ports"
I don't know why I get this warning or how to make it go away. Could this be
a problem with the xml files? I'm putting some debug in the
noc_block_radio_core to see if I can track down where the data is being lost.
I've included the Verilog for the noc_block below if anyone is so inclined to
look it over.
Thanks
Doug
module noc_block_xxx
#(
parameter NOC_ID = 64'h0930_1997_0000_0000,
parameter STR_SINK_FIFOSIZE = 11,
parameter NUM_OUTPUTS = 9
)
(
input bus_clk,
input bus_rst,
input ce_clk,
input ce_rst,
input [63:0] i_tdata,
input i_tlast,
input i_tvalid,
output i_tready,
output [63:0] o_tdata,
output o_tlast,
output o_tvalid,
input o_tready,
output [63:0] debug
);
// Block Configuration
localparam NUM_DDC = 8; // Number of receiver DDC channels to
instantiate
localparam NUM_DET = NUM_OUTPUTS - NUM_DDC - 1; // Number of detector
channels
localparam SR_BASE = 128; // Settings register
address base
// Interconnect
wire [32*NUM_OUTPUTS-1:0] set_data;
wire [8*NUM_OUTPUTS-1:0] set_addr;
wire [NUM_OUTPUTS-1:0] set_stb;
wire [64*NUM_OUTPUTS-1:0] rb_data;
wire [63:0] str_sink_tdata;
wire str_sink_tlast, str_sink_tvalid, str_sink_tready;
wire [64*NUM_OUTPUTS-1:0] str_src_tdata;
wire [NUM_OUTPUTS-1:0] str_src_tlast, str_src_tvalid, str_src_tready;
wire [31:0] in_tdata;
wire [127:0] in_tuser;
wire in_tvalid;
wire [NUM_OUTPUTS-1:0] out_tvalid, out_tlast, out_tready;
wire [32*NUM_OUTPUTS-1:0] out_tdata;
wire [128*NUM_OUTPUTS-1:0] out_tuser;
wire [NUM_OUTPUTS-1:0] clear_tx_seqnum;
wire [16*NUM_OUTPUTS-1:0] src_sid, nxt_dst_sid;
// RFNoC Shell
noc_shell #(
.NOC_ID(NOC_ID),
.STR_SINK_FIFOSIZE(STR_SINK_FIFOSIZE),
.INPUT_PORTS(1),
.OUTPUT_PORTS(NUM_OUTPUTS))
noc_shell (
.bus_clk(bus_clk), .bus_rst(bus_rst),
.i_tdata(i_tdata), .i_tlast(i_tlast), .i_tvalid(i_tvalid),
.i_tready(i_tready),
.o_tdata(o_tdata), .o_tlast(o_tlast), .o_tvalid(o_tvalid),
.o_tready(o_tready),
// Compute Engine Clock Domain
.clk(ce_clk), .reset(ce_rst),
// Control Sink
.set_data(set_data), .set_addr(set_addr), .set_stb(set_stb),
.set_time(), .set_has_time(),
.rb_stb({NUM_OUTPUTS{1'b1}}), .rb_data(64'd0), .rb_addr(),
// Control Source
.cmdout_tdata(64'd0), .cmdout_tlast(1'b0), .cmdout_tvalid(1'b0),
.cmdout_tready(),
.ackin_tdata(), .ackin_tlast(), .ackin_tvalid(), .ackin_tready(1'b1),
// Stream Sink
.str_sink_tdata(str_sink_tdata), .str_sink_tlast(str_sink_tlast),
.str_sink_tvalid(str_sink_tvalid), .str_sink_tready(str_sink_tready),
// Stream Source
.str_src_tdata(str_src_tdata), .str_src_tlast(str_src_tlast),
.str_src_tvalid(str_src_tvalid), .str_src_tready(str_src_tready),
.vita_time(64'd0),
.clear_tx_seqnum(clear_tx_seqnum), .src_sid(src_sid),
.next_dst_sid(nxt_dst_sid),
.resp_in_dst_sid(), .resp_out_dst_sid(),
.debug(debug));
// CHDR deframer for incomming packets from the radio front end at 200 Msps.
The output signal
// here is a steady stream sampled at 200 Msps with no gaps in the 'valid'
signal. The AXI
// framing signals can be ignored.
chdr_deframer chdr_deframer (
.clk(ce_clk), .reset(ce_rst), .clear(1'b0),
.i_tdata(str_sink_tdata), .i_tlast(str_sink_tlast),
.i_tvalid(str_sink_tvalid), .i_tready(str_sink_tready),
.o_tdata(in_tdata), .o_tuser(in_tuser), .o_tlast(), .o_tvalid(in_tvalid),
.o_tready(1'b1));
// xxx core. WARNING: NUM_OUTPUTS must equal NUM_DDC+NUM_DET+1 !!!!!!!
xxx_core
#(.NUM_DDC(NUM_DDC), .NUM_DET(NUM_DET), .SR_BASE(SR_BASE))
xxx_core_inst
(.clk(ce_clk), .rst_n(~ce_rst), .set_stb(set_stb), .set_addr(set_addr),
.set_data(set_data), .rb_data(rb_data),
.valid_in(in_tvalid), .i_in(in_tdata[31:16]), .q_in(16'd0),
.out_tvalid(out_tvalid), .out_tlast(out_tlast), .out_tready(out_tready),
.out_tdata(out_tdata));
// Prepend the CHDR header to all packets, and connect these streams to block
output ports
localparam MTU = 10;
genvar m;
generate
for (m = 0; m < NUM_OUTPUTS; m = m + 1) begin : framer_inst
assign out_tuser[128*(m+1)-1:128*m] = {in_tuser[127:96],
src_sid[16*(m+1)-1:16*m], nxt_dst_sid[16*(m+1)-1:16*m], in_tuser[63:0]};
chdr_framer #(.SIZE(MTU)) chdr_framer (
.clk(ce_clk), .reset(ce_rst), .clear(clear_tx_seqnum[m]),
.i_tdata(out_tdata[32*(m+1)-1:32*m]),
.i_tuser(out_tuser[128*(m+1)-1:128*m]), .i_tlast(out_tlast[m]),
.i_tvalid(out_tvalid[m]), .i_tready(out_tready[m]),
.o_tdata(str_src_tdata[64*(m+1)-1:64*m]), .o_tlast(str_src_tlast[m]),
.o_tvalid(str_src_tvalid[m]), .o_tready(str_src_tready[m]));
end
endgenerate
endmodule // noc_block_xxx
From: Jonathon Pendlum [mailto:[email protected]]
Sent: Monday, May 08, 2017 1:24 PM
To: Barker, Douglas W.
Cc: [email protected]<mailto:[email protected]>
Subject: Re: [USRP-users] LFRX daughterboard with radio block
Hi Doug,
That is very odd. Are you using the latest rfnoc-devel commit and not something
like rfnoc-devel-predo right? What is ce_clk hooked up to in your custom block?
Is your flowgraph Radio Block -> Custom Block or Radio Block -> DDC -> Custom
Block?
Jonathon
On Mon, May 8, 2017 at 9:25 AM, Barker, Douglas W. via USRP-users
<[email protected]<mailto:[email protected]>> wrote:
Hello,
I'm using the LFRX daughterboard on the X310. In gnuradio I connect the rfnoc
radio block to my custom rfnoc block and from there to the host. The sample
rate of the radio block is set to 200M. In my custom noc block I connect the
output of noc_shell -> chdr_deframer. On the output of the chdr_deframer I'm
expecting 200 Msps data, thus the 'o_tvalid' signal should be continuously high
(I've got the 'o_tready' tied high).
That's not what I get though. The rate coming in is only a small fraction of
200 Msps. When I monitor the transactions at the input to the noc block
(i_tdata, i_tvalid, etc) I see the same behavior. The AXI packets are all in
sequence so none are discarded. Can anyone tell me what is going on??
Thanks
Doug
_______________________________________________
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]<mailto:[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/20170510/5686d970/attachment-0001.html>
------------------------------
Message: 17
Date: Wed, 10 May 2017 14:08:54 +0000
From: "Gilad Beeri (ApolloShield)" <[email protected]>
To: Vladica Sark <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [USRP-users] High CPU usage
Message-ID:
<caf4uvpcjhr_uzldxmxsgu1pgkctoqagdf_i+nmzrgy1sjqa...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
What happens if you reduce the sample rate, say, to 10e3 samples per second?
And what happens if you reduce the # of generated samples to a very low
number, e.g., 8?
On Wed, May 10, 2017 at 2:51 PM Vladica Sark via USRP-users <
[email protected]> wrote:
> Hi,
>
> I have an app which transmits 8192 samples each 10 ms on two N210s which
> are combined together and seen as 2 channels. The samples are
> transmitted as timed samples. After the send command, I wait in
> recv_async_msg command, till the samples get transmitted and than I
> schedule a new transmission in 10 ms.
>
> The issue is that the CPU utilization is 200%, i.e. 2 cores at 100%.
> It does not depend on the sample rate. Tried 10, 25 and 50 MSps.
> Of course, no signal processing is involved at this point, only ready
> samples are being transmitted.
>
> The machine has a i5 vPro processor with 4 cores.
>
> Any way to reduce this?
>
> BR,
> Vladica
>
> _______________________________________________
> 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/20170510/1c7b7636/attachment-0001.html>
------------------------------
Message: 18
Date: Wed, 10 May 2017 16:16:34 +0200
From: Vladica Sark <[email protected]>
To: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] High CPU usage
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi,
With 8 samples per burst and 0.195312 MSps, again 200% of processor usage.
Lower sample rate is not supported by the N210s.
BR,
Vladica
On 10.05.2017 16:08, Gilad Beeri (ApolloShield) wrote:
> What happens if you reduce the sample rate, say, to 10e3 samples per second?
> And what happens if you reduce the # of generated samples to a very low
> number, e.g., 8?
>
> On Wed, May 10, 2017 at 2:51 PM Vladica Sark via USRP-users
> <[email protected] <mailto:[email protected]>> wrote:
>
> Hi,
>
> I have an app which transmits 8192 samples each 10 ms on two N210s which
> are combined together and seen as 2 channels. The samples are
> transmitted as timed samples. After the send command, I wait in
> recv_async_msg command, till the samples get transmitted and than I
> schedule a new transmission in 10 ms.
>
> The issue is that the CPU utilization is 200%, i.e. 2 cores at 100%.
> It does not depend on the sample rate. Tried 10, 25 and 50 MSps.
> Of course, no signal processing is involved at this point, only ready
> samples are being transmitted.
>
> The machine has a i5 vPro processor with 4 cores.
>
> Any way to reduce this?
>
> BR,
> Vladica
>
> _______________________________________________
> USRP-users mailing list
> [email protected] <mailto:[email protected]>
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Message: 19
Date: Wed, 10 May 2017 17:17:50 +0200
From: Claudio Cicconetti <[email protected]>
To: [email protected], [email protected]
Subject: Re: [USRP-users] High CPU usage
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
Dear Vladica,
It sounds like you have an active wait in the tx threads.
I suggest you double-check all loops and make sure they do not spin
faster than intended.
For instance, if you have something like:
while (true) {
// do something without blocking
recv_async_msg(/* ... */); // [1]
// do something without blocking
}
As I understand, you are assuming that [1] blocks, but if it does not
then you have a problem because the CPU will be 100% on the loop.
Same if you have other library/system calls that _should_ block but
_may_ not due to any reason.
Adding some log lines with a timestamp or measuring the function call
times should point you straight to the issue.
Best regards,
Claudio
On 05/10/2017 04:16 PM, Vladica Sark via USRP-users wrote:
> Hi,
>
> With 8 samples per burst and 0.195312 MSps, again 200% of processor usage.
> Lower sample rate is not supported by the N210s.
>
> BR,
> Vladica
>
>
> On 10.05.2017 16:08, Gilad Beeri (ApolloShield) wrote:
>> What happens if you reduce the sample rate, say, to 10e3 samples per
>> second?
>> And what happens if you reduce the # of generated samples to a very low
>> number, e.g., 8?
>>
>> On Wed, May 10, 2017 at 2:51 PM Vladica Sark via USRP-users
>> <[email protected] <mailto:[email protected]>> wrote:
>>
>> Hi,
>>
>> I have an app which transmits 8192 samples each 10 ms on two N210s
>> which
>> are combined together and seen as 2 channels. The samples are
>> transmitted as timed samples. After the send command, I wait in
>> recv_async_msg command, till the samples get transmitted and than I
>> schedule a new transmission in 10 ms.
>>
>> The issue is that the CPU utilization is 200%, i.e. 2 cores at 100%.
>> It does not depend on the sample rate. Tried 10, 25 and 50 MSps.
>> Of course, no signal processing is involved at this point, only ready
>> samples are being transmitted.
>>
>> The machine has a i5 vPro processor with 4 cores.
>>
>> Any way to reduce this?
>>
>> BR,
>> Vladica
>>
>> _______________________________________________
>> 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
------------------------------
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 81, Issue 10
******************************************
