date:20181218

Re: [USRP-users] Creating RFNOC block that changes stream rate

2018-12-18 Thread Jon Pendlum via USRP-users

Hi Andrew,

Have you tried using Chipscope to see where the issue is at in your code?
You want to look at the tvalid and tready AXI stream control signals to
pinpoint where your data flow stalls (i.e. tvalid = 1 and tready = 0). Once
you know where the stall is located, I can provide more advice.

Jonathon

On Wed, Dec 19, 2018 at 8:20 AM Andrew Danowitz via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Thanks for the reply. I do set simple_mode and I propagate tuser into and
> out of axi_rate_change the same way noc_block_ddc does. I also have my
> block running properly in Vivado simulation. Is there anything else I
> should check? I also included axi_tag_time. Could that be causing an issue?
>
> Thanks!
> Andrew
>
> On Tue, Dec 18, 2018 at 10:11 AM EJ Kreinar  wrote:
>
>> Hi Andrew,
>>
>> Quick thoughts:
>> - Are you setting SIMPLE_MODE(0) in the axi_wrapper?
>> - Are you propagating tuser into and out of the axi_rate_change block?
>>
>> The axi_rate_change block updates tuser, which the axi_wrapper uses to
>> create output packets when SIMPLE_MODE is disabled.
>>
>> Also, have you run in a simulation testbench? Simulation should be able
>> to expose these issues before targetting hardware to make debugging a bit
>> easier.
>>
>> EJ
>>
>>
>>
>> On Tue, Dec 18, 2018 at 1:04 PM Andrew Danowitz via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>>> Hi all,
>>>
>>> I'm trying to create an rfnoc block that takes in a stream of data at
>>> Sample rate n, does some processing to turn i-q values into real samples,
>>> and outputs data at a rate of n/2 by packing real values into both i and q
>>> channels of the output stream. I've tried to incorporate the
>>> axi_rate_change block and the axi_tag_time block a-la noc_block_ddc, but
>>> whenever I try to run it I keep getting a timeout error. If I take out the
>>> channel packing block and keep the rate n-to-n, the module works fine.
>>>
>>> Does anyone have any advice?
>>>
>>> Thanks,
>>> Andrew
>>>
>>> --
>>> Information contained, linked, or attached to this email and all verbal
>>> communications from WhiteFox Defense to your entity in the prior 30 days
>>> constitute proprietary and confidential information unless otherwise
>>> indicated and is therefore subject to obligations in any executed
>>> confidentiality agreements. Further, this email is intended solely for the
>>> use of the individual or entity to whom they are addressed. If you are not
>>> the intended recipient and this message has been addressed to you in error,
>>> please promptly notify i...@whitefoxdefense.com and destroy all copies
>>> of the message and any attachments. This email and attachments may contain
>>> technical data as defined in the International Traffic In Arms Regulations
>>> (ITAR) 22 CFR 120.10 or the Export Administration Regulations (EAR) 15 CFR
>>> Parts 730 – 780.  Export of this material may be controlled by these
>>> regulations and may not be exported or transferred to non-U.S. persons
>>> without prior written approval from the U.S. government.
>>> ___
>>> USRP-users mailing list
>>> USRP-users@lists.ettus.com
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>
>>
> --
> Information contained, linked, or attached to this email and all verbal
> communications from WhiteFox Defense to your entity in the prior 30 days
> constitute proprietary and confidential information unless otherwise
> indicated and is therefore subject to obligations in any executed
> confidentiality agreements. Further, this email is intended solely for the
> use of the individual or entity to whom they are addressed. If you are not
> the intended recipient and this message has been addressed to you in error,
> please promptly notify i...@whitefoxdefense.com and destroy all copies of
> the message and any attachments. This email and attachments may contain
> technical data as defined in the International Traffic In Arms Regulations
> (ITAR) 22 CFR 120.10 or the Export Administration Regulations (EAR) 15 CFR
> Parts 730 – 780.  Export of this material may be controlled by these
> regulations and may not be exported or transferred to non-U.S. persons
> without prior written approval from the U.S. government.
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Creating RFNOC block that changes stream rate

2018-12-18 Thread EJ Kreinar via USRP-users

Some more thoughts...

Are you programming the axi_rate_change SR_N, SR_M, and SR_CONFIG registers
when you run on hardware? You might be able to do this with the XML
definition, but you may also need a block controller like the
ddc_block_ctrl_impl in uhd. Don't forgot the config register-- this seems
to latch in the N & M values.

I probably wouldn't worry about the axi_tag_time unless timed commands are
really important to your application... For most "run of the mill" rfnoc
applications with gnuradio it's usually safe to ignore timed commands, so
you might be able to simplify some logic if you wanted to take out the
axi_tag_time.


As another example you can reference, see this unmerged PR from a month or
so ago that combines a DUC and DDC into a single rfnoc block:
https://github.com/EttusResearch/fpga/pull/32 Also the corresponding uhd PR
with the software controller:
https://github.com/EttusResearch/uhd/pull/219/files

(These PRs didn't make it into the main branches but they will live on,
soon, in a new consolidated OOT repo)

EJ

On Tue, Dec 18, 2018, 6:19 PM Andrew Danowitz  Thanks for the reply. I do set simple_mode and I propagate tuser into and
> out of axi_rate_change the same way noc_block_ddc does. I also have my
> block running properly in Vivado simulation. Is there anything else I
> should check? I also included axi_tag_time. Could that be causing an issue?
>
> Thanks!
> Andrew
>
> On Tue, Dec 18, 2018 at 10:11 AM EJ Kreinar  wrote:
>
>> Hi Andrew,
>>
>> Quick thoughts:
>> - Are you setting SIMPLE_MODE(0) in the axi_wrapper?
>> - Are you propagating tuser into and out of the axi_rate_change block?
>>
>> The axi_rate_change block updates tuser, which the axi_wrapper uses to
>> create output packets when SIMPLE_MODE is disabled.
>>
>> Also, have you run in a simulation testbench? Simulation should be able
>> to expose these issues before targetting hardware to make debugging a bit
>> easier.
>>
>> EJ
>>
>>
>>
>> On Tue, Dec 18, 2018 at 1:04 PM Andrew Danowitz via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>>> Hi all,
>>>
>>> I'm trying to create an rfnoc block that takes in a stream of data at
>>> Sample rate n, does some processing to turn i-q values into real samples,
>>> and outputs data at a rate of n/2 by packing real values into both i and q
>>> channels of the output stream. I've tried to incorporate the
>>> axi_rate_change block and the axi_tag_time block a-la noc_block_ddc, but
>>> whenever I try to run it I keep getting a timeout error. If I take out the
>>> channel packing block and keep the rate n-to-n, the module works fine.
>>>
>>> Does anyone have any advice?
>>>
>>> Thanks,
>>> Andrew
>>>
>>> --
>>> Information contained, linked, or attached to this email and all verbal
>>> communications from WhiteFox Defense to your entity in the prior 30 days
>>> constitute proprietary and confidential information unless otherwise
>>> indicated and is therefore subject to obligations in any executed
>>> confidentiality agreements. Further, this email is intended solely for the
>>> use of the individual or entity to whom they are addressed. If you are not
>>> the intended recipient and this message has been addressed to you in error,
>>> please promptly notify i...@whitefoxdefense.com and destroy all copies
>>> of the message and any attachments. This email and attachments may contain
>>> technical data as defined in the International Traffic In Arms Regulations
>>> (ITAR) 22 CFR 120.10 or the Export Administration Regulations (EAR) 15 CFR
>>> Parts 730 – 780.  Export of this material may be controlled by these
>>> regulations and may not be exported or transferred to non-U.S. persons
>>> without prior written approval from the U.S. government.
>>> ___
>>> USRP-users mailing list
>>> USRP-users@lists.ettus.com
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>
>>
> --
> Information contained, linked, or attached to this email and all verbal
> communications from WhiteFox Defense to your entity in the prior 30 days
> constitute proprietary and confidential information unless otherwise
> indicated and is therefore subject to obligations in any executed
> confidentiality agreements. Further, this email is intended solely for the
> use of the individual or entity to whom they are addressed. If you are not
> the intended recipient and this message has been addressed to you in error,
> please promptly notify i...@whitefoxdefense.com and destroy all copies of
> the message and any attachments. This email and attachments may contain
> technical data as defined in the International Traffic In Arms Regulations
> (ITAR) 22 CFR 120.10 or the Export Administration Regulations (EAR) 15 CFR
> Parts 730 – 780.  Export of this material may be controlled by these
> regulations and may not be exported or transferred to non-U.S. persons
> without prior written approval from

Re: [USRP-users] Creating RFNOC block that changes stream rate

2018-12-18 Thread Andrew Danowitz via USRP-users

Thanks for the reply. I do set simple_mode and I propagate tuser into and
out of axi_rate_change the same way noc_block_ddc does. I also have my
block running properly in Vivado simulation. Is there anything else I
should check? I also included axi_tag_time. Could that be causing an issue?

Thanks!
Andrew

On Tue, Dec 18, 2018 at 10:11 AM EJ Kreinar  wrote:

> Hi Andrew,
>
> Quick thoughts:
> - Are you setting SIMPLE_MODE(0) in the axi_wrapper?
> - Are you propagating tuser into and out of the axi_rate_change block?
>
> The axi_rate_change block updates tuser, which the axi_wrapper uses to
> create output packets when SIMPLE_MODE is disabled.
>
> Also, have you run in a simulation testbench? Simulation should be able to
> expose these issues before targetting hardware to make debugging a bit
> easier.
>
> EJ
>
>
>
> On Tue, Dec 18, 2018 at 1:04 PM Andrew Danowitz via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> Hi all,
>>
>> I'm trying to create an rfnoc block that takes in a stream of data at
>> Sample rate n, does some processing to turn i-q values into real samples,
>> and outputs data at a rate of n/2 by packing real values into both i and q
>> channels of the output stream. I've tried to incorporate the
>> axi_rate_change block and the axi_tag_time block a-la noc_block_ddc, but
>> whenever I try to run it I keep getting a timeout error. If I take out the
>> channel packing block and keep the rate n-to-n, the module works fine.
>>
>> Does anyone have any advice?
>>
>> Thanks,
>> Andrew
>>
>> --
>> Information contained, linked, or attached to this email and all verbal
>> communications from WhiteFox Defense to your entity in the prior 30 days
>> constitute proprietary and confidential information unless otherwise
>> indicated and is therefore subject to obligations in any executed
>> confidentiality agreements. Further, this email is intended solely for the
>> use of the individual or entity to whom they are addressed. If you are not
>> the intended recipient and this message has been addressed to you in error,
>> please promptly notify i...@whitefoxdefense.com and destroy all copies
>> of the message and any attachments. This email and attachments may contain
>> technical data as defined in the International Traffic In Arms Regulations
>> (ITAR) 22 CFR 120.10 or the Export Administration Regulations (EAR) 15 CFR
>> Parts 730 – 780.  Export of this material may be controlled by these
>> regulations and may not be exported or transferred to non-U.S. persons
>> without prior written approval from the U.S. government.
>> ___
>> USRP-users mailing list
>> USRP-users@lists.ettus.com
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>

-- 

Information contained, linked, or attached to this email and all verbal 
communications from WhiteFox Defense to your entity in the prior 30 days 
constitute proprietary and confidential information unless otherwise 
indicated and is therefore subject to obligations in any executed 
confidentiality agreements. Further, this email is intended solely for the 
use of the individual or entity to whom they are addressed. If you are not 
the intended recipient and this message has been addressed to you in error, 
please promptly notify i...@whitefoxdefense.com 
 and destroy all copies of the message and 
any attachments. This email and attachments may contain technical data as 
defined in the International Traffic In Arms Regulations (ITAR) 22 CFR 
120.10 or the Export Administration Regulations (EAR) 15 CFR Parts 730 – 
780.  Export of this material may be controlled by these regulations and 
may not be exported or transferred to non-U.S. persons without prior 
written approval from the U.S. government.
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] X310 xpr Files

2018-12-18 Thread Nick Foster via USRP-users

You can do "make GUI=1 X310_HG" to open the Vivado GUI and build the
project.

Nick

On Tue, Dec 18, 2018 at 1:33 PM Alexander Olihovik via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi all,
>
> Will running "make X310_HG" generate a .xpr file that I can open with
> Vivado? I have a .xpr for the E310 from a previous effort so I think it can
> be done, but I wasn't the originator of this file.
> I was following this guide:
> http://files.ettus.com/manual/md_usrp3_build_instructions.html
>
> Best,
> Alex
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] X310 xpr Files

2018-12-18 Thread Alexander Olihovik via USRP-users

Hi all,

Will running "make X310_HG" generate a .xpr file that I can open with
Vivado? I have a .xpr for the E310 from a previous effort so I think it can
be done, but I wasn't the originator of this file.
I was following this guide:
http://files.ettus.com/manual/md_usrp3_build_instructions.html

Best,
Alex
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Phase Offset problem when center frequency is changed dynamically

2018-12-18 Thread Marcus D. Leech via USRP-users


On 12/18/2018 05:07 AM, Arun kumar Verma wrote:

Dear Marcus

I  found the real problem and problem is that when i use 
set_command_time in loop then only problem exist, if do not use this 
my loop is getting executed properly. But for phase synchronization i 
have to use set_command_time

Any suggestion?

Arun Verma

How rapidly is that loop executing?  The timed-command queue is only 16 
items deep, and you're scheduling at 0.01sec intervals.






*From:* Arun kumar Verma via USRP-users 
*To:* Marcus D. Leech ; 
"usrp-users@lists.ettus.com" 

*Sent:* Tuesday, 18 December 2018 2:16 PM
*Subject:* Re: [USRP-users] Phase Offset problem when center frequency 
is changed dynamically


Dear Marcus

The problem is solved by setting RF policy manual for RF and DSP both 
and passing uhd::tune_request_t object as parameter to set_center_freq 
function, but now i getting one more issues that after 35-40 iteration 
my application is getting assertion because of "EnvironmentError: 
IOError: Block ctrl (CE_00_Port_30) no response packet - 
AssertionError: bool(buff)" and after that I have to start X310 again 
then only it responds.


My setup is X310 with single TwinRX module and I want to measure the 
phase difference from 10-6000MHz and put into look-up table. I am 
using B205-mini as transmitter and it is connected with the power 
divider to X310 input. I am working on phase interferometer direction 
finding with 5 element circular array antennae connected to 5 to 2 
Antenna Switch matrix which is connected to single  TwinRX.



I am not sure how set_center_freq command is implemented internally 
for TwinRX, but i expect that when i set this command, only LOs should 
be tuned for desired frequencies plus some filter selection of that 
band. I expect that settling time for synthesizer would be around 
maximum of 300uS and for some other stuff like filter selection , i 
think in  500uS I should be able to set everything. At present I have 
to use set_command_time so that my channels are synchronized. Can you 
suggest the fastest way to implementing frequency sweep for two 
channels as i need scan rate around 40GHz.


Regards,
Arun Verma


*From:* Marcus D. Leech via USRP-users 
*To:* usrp-users@lists.ettus.com
*Sent:* Monday, 17 December 2018 10:36 PM
*Subject:* Re: [USRP-users] Phase Offset problem when center frequency 
is changed dynamically


On 12/15/2018 08:02 AM, Arun kumar Verma via USRP-users wrote:

Dear Users

I am facing problem of phase offset when i change center frequency 
dynamically for TwinRX with X310 setup. Here is my C++ code,


Please advise

usrp_source1->set_rx_lo_source("internal",uhd::usrp::multi_usrp::ALL_LOS,0);
usrp_source1->set_rx_lo_source("companion",uhd::usrp::multi_usrp::ALL_LOS,1);

usrp_sourceDOA1->set_command_time(usrp_sourceDOA1->get_time_now() + 
uhd::time_spec_t(0.01));

usrp_sourceDOA1->set_center_freq(m_CenterFrequency,0);
usrp_sourceDOA1->set_center_freq(m_CenterFrequency,1);
usrp_sourceDOA1->clear_command_time();

I feel set_command_time is not working properly. When i start the 
X310 my phase difference is almost zero but as i change my frequency 
pjhase difference is random in nature.


Regards,
Arun Verma


COuld you explain your setup a bit more here.

I now see that you have both usrp_source1 and usrp_sourceDOA1, but I 
think you said that you have a single X310, so I'm confused about

  why you apparently have two USRP sources here.


___
USRP-users mailing list
USRP-users@lists.ettus.com 
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com


___
USRP-users mailing list
USRP-users@lists.ettus.com 
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com




___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] cross-compiling for N310

2018-12-18 Thread Philip Balister via USRP-users

Do you really need to install uhd on a machine to install an sdk on it?

Philip

On December 18, 2018 11:19:38 AM EST, Jason Matusiak via USRP-users 
 wrote:
>I got it by running: uhd_images_downloader -t sdk -t n3xx
> 
>based on instructions here:
>https://files.ettus.com/manual/page_usrp_n3xx.html#n3xx_software_dev_sdk
> 
>It does not appear to have gnuradio installed
> 
>OK, gnuradio seems to build fine for cross-compile, it is when I get to
>the gr-ettus step which is next (needed for RFNoC).  I haven't tried
>running gnuradio, but it builds.
> 
> 
>- Original Message - Subject: Re: [USRP-users]
>cross-compiling for N310
>From: "Philip Balister" 
>Date: 12/18/18 10:25 am
>To: "Jason Matusiak" , "Ettus Mail List"
>
>
>On 12/18/2018 08:17 AM, Jason Matusiak via USRP-users wrote:
>> It looks like qt4 was not included in the cross-compile build. If I
>look at my working e300 cross-compile, I have a folder:
>/opt/gnuradio/e300/sysroots/armv7ahf-neon-oe-linux-gnueabi/usr/include/qt4/
> > 
> > (in fact, there is a tone of stuff in that include).
> > 
>> If I look in the N310 directory, it doesn't exist:
>/opt/gnuradio/N310/sysroots/armv7ahf-neon-oe-linux-gnueabi/usr/include/
> > 
> > (and there are very few files/folders in there at all.
> > 
>> I will look into building it by hand, but I am guessing that it will
>just lead to more things needing to be cross-compiled
> 
>Where did you get the toolchain? Does the N310 have gnuradio installed?
>Feels like the sdk may not have the packages you need to build gnuradio
> installed.
> 
>Try disabling qt4 and seeing if you can get gnuradio to build like that
> as a test.
> 
> Philip
> 
> > 
> > 
> > 
>> - Original Message - Subject: RE: cross-compiling for
>N310
> > From: "Jason Matusiak" 
> > Date: 12/17/18 3:15 pm
> > To: "Ettus Mail List" 
> > 
>> OK, I see the first mistake. I was copying-and-pasting my notes for
>the E310 which had a different sysroot. Once I made the change to the
>proper one, it seems like it got past the rfnoc issue (or I haven't hit
>it yet with this new error).
> > 
> > I am not getting:
>> - Found PkgConfig:
>/opt/gnuradio/N310/sysroots/x86_64-oesdk-linux/usr/bin/pkg-config
>(found version "0.29.2") 
>> -- Found UHD:
>/opt/gnuradio/N310/sysroots/cortexa9hf-neon-oe-linux-gnueabi/usr/lib/libuhd.so
>
>> -- Found PythonLibs:
>/opt/gnuradio/N310/sysroots/cortexa9hf-neon-oe-linux-gnueabi/usr/lib/libpython2.7.so
>(found suitable version "2.7.14", minimum required is "2") 
>> CMake Warning at
>/opt/gnuradio/N310/sysroots/x86_64-oesdk-linux/usr/share/cmake-3.10/Modules/FindQt4.cmake:620
>(message):
>> /usr/bin/qmake-qt4 reported QT_INSTALL_LIBS as "/usr/lib64" but
>QtCore
>> could not be found there. Qt is NOT installed correctly for the
>target
> > build environment.
> > Call Stack (most recent call first):
> > CMakeLists.txt:149 (find_package)
> > 
> > CMake Error at CMakeLists.txt:151 (message):
> > Qt not found.
> > 
> > -- Configuring incomplete, errors occurred!
>> See also
>"/opt/gnuradio/N310/src/gr-ettus/n310-build/CMakeFiles/CMakeOutput.log".
>> See also
>"/opt/gnuradio/N310/src/gr-ettus/n310-build/CMakeFiles/CMakeError.log".
> > 
>> I feel like I had this issue before with an E310 build and Phil B had
>to make mods to the toolchain. Has anyone else seen and got around
>this?
> > 
> > 
> > 
>> - Original Message - Subject: cross-compiling for
>N310
> > From: "Jason Matusiak" 
> > Date: 12/17/18 1:35 pm
> > To: "Ettus Mail List" 
> > 
>> Has anyone successfully created a new build for an N310 (RFNoC
>version in particular)? I was going to bring it up to date, but seem to
>be having issues.
> > 
> > I ran: uhd_images_downloader -t sdimg -v
>> To get the *.sh image for cross-compiling:
>oecore-x86_64-cortexa9hf-neon-toolchain-nodistro.0.sh
> > 
> > I then install it like I do for the E310.
> > 
>> I create a src directory and pull down uhd and its sub-module
>fpga-src. I've tried main, master, and UHD-3.13, and they all build
>fine, but give me issues later on. In my cmake I make sure to have
>-DENABLE_RFNOC=ON and I see it checked when I run cmake-gui.
> > 
> > I then pull down gnuradio, and build like I normally do.
> > 
>> Lastly, I pull down gr-ettus. When I run: cmake
>-DCMAKE_TOOLCHAIN_FILE=$PREFIX/src/gnuradio/cmake/Toolchains/oe-sdk_cross.cmake
>-DENABLE_DOXYGEN=OFF -DCMAKE_INSTALL_PREFIX=/usr ..
> > 
> > It mostly works and then errors out with:
> > 
>> -- Found PkgConfig:
>/opt/gnuradio/N310/sysroots/x86_64-oesdk-linux/usr/bin/pkg-config
>(found version "0.29.2") 
>> -- Found UHD:
>/opt/gnuradio/N310/sysroots/cortexa9hf-neon-oe-linux-gnueabi/usr/lib/libuhd.so
>
> > CMake Error at CMakeLists.txt:140 (message):
> > RFNoC not found.
> > 
> > -- Configuring incomplete, errors occurred!
>> See also
>"/opt/gnuradio/N310/src/gr-ettus/n310-build/CMakeFiles/CMakeOutput.log".
>> See also
>"/opt/gnuradio/N310/src/gr-ettus/n310-build/CMakeFiles/CMakeError.log".
> > 
>> In the past, I

Re: [USRP-users] Creating RFNOC block that changes stream rate

2018-12-18 Thread EJ Kreinar via USRP-users

Hi Andrew,

Quick thoughts:
- Are you setting SIMPLE_MODE(0) in the axi_wrapper?
- Are you propagating tuser into and out of the axi_rate_change block?

The axi_rate_change block updates tuser, which the axi_wrapper uses to
create output packets when SIMPLE_MODE is disabled.

Also, have you run in a simulation testbench? Simulation should be able to
expose these issues before targetting hardware to make debugging a bit
easier.

EJ



On Tue, Dec 18, 2018 at 1:04 PM Andrew Danowitz via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi all,
>
> I'm trying to create an rfnoc block that takes in a stream of data at
> Sample rate n, does some processing to turn i-q values into real samples,
> and outputs data at a rate of n/2 by packing real values into both i and q
> channels of the output stream. I've tried to incorporate the
> axi_rate_change block and the axi_tag_time block a-la noc_block_ddc, but
> whenever I try to run it I keep getting a timeout error. If I take out the
> channel packing block and keep the rate n-to-n, the module works fine.
>
> Does anyone have any advice?
>
> Thanks,
> Andrew
>
> --
> Information contained, linked, or attached to this email and all verbal
> communications from WhiteFox Defense to your entity in the prior 30 days
> constitute proprietary and confidential information unless otherwise
> indicated and is therefore subject to obligations in any executed
> confidentiality agreements. Further, this email is intended solely for the
> use of the individual or entity to whom they are addressed. If you are not
> the intended recipient and this message has been addressed to you in error,
> please promptly notify i...@whitefoxdefense.com and destroy all copies of
> the message and any attachments. This email and attachments may contain
> technical data as defined in the International Traffic In Arms Regulations
> (ITAR) 22 CFR 120.10 or the Export Administration Regulations (EAR) 15 CFR
> Parts 730 – 780.  Export of this material may be controlled by these
> regulations and may not be exported or transferred to non-U.S. persons
> without prior written approval from the U.S. government.
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] cross-compiling for N310

2018-12-18 Thread EJ Kreinar via USRP-users

If I recall correctly the only place QT is used would be in the RFNoC
Fosphor host code to display the fosphor output. This typically runs on a
PC, not an embedded device like E310 or N310. Unless you really need to use
QT on the N310, definitely the easiest solution here would be to just
disable qt for gr-ettus.

I usually disable QT in gr-ettus for my cross compile builds using `cmake
..  -DENABLE_QT=OFF`

Hope this helps,
EJ

On Tue, Dec 18, 2018 at 11:21 AM Jason Matusiak via USRP-users <
usrp-users@lists.ettus.com> wrote:

> I got it by running: uhd_images_downloader -t sdk -t n3xx
>
> based on instructions here:
> https://files.ettus.com/manual/page_usrp_n3xx.html#n3xx_software_dev_sdk
>
> It does not appear to have gnuradio installed
>
> OK, gnuradio seems to build fine for cross-compile, it is when I get to
> the gr-ettus step which is next (needed for RFNoC).  I haven't tried
> running gnuradio, but it builds.
>
>
>
> - Original Message -
> Subject: Re: [USRP-users] cross-compiling for N310
> From: "Philip Balister" 
> Date: 12/18/18 10:25 am
> To: "Jason Matusiak" , "Ettus Mail List" <
> usrp-users@lists.ettus.com>
>
> On 12/18/2018 08:17 AM, Jason Matusiak via USRP-users wrote:
> > It looks like qt4 was not included in the cross-compile build. If I look
> at my working e300 cross-compile, I have a folder:
> /opt/gnuradio/e300/sysroots/armv7ahf-neon-oe-linux-gnueabi/usr/include/qt4/
> >
> > (in fact, there is a tone of stuff in that include).
> >
> > If I look in the N310 directory, it doesn't exist:
> /opt/gnuradio/N310/sysroots/armv7ahf-neon-oe-linux-gnueabi/usr/include/
> >
> > (and there are very few files/folders in there at all.
> >
> > I will look into building it by hand, but I am guessing that it will
> just lead to more things needing to be cross-compiled
>
> Where did you get the toolchain? Does the N310 have gnuradio installed?
> Feels like the sdk may not have the packages you need to build gnuradio
> installed.
>
> Try disabling qt4 and seeing if you can get gnuradio to build like that
> as a test.
>
> Philip
>
> >
> >
> >
> > - Original Message - Subject: RE: cross-compiling for
> N310
> > From: "Jason Matusiak" 
> > Date: 12/17/18 3:15 pm
> > To: "Ettus Mail List" 
> >
> > OK, I see the first mistake. I was copying-and-pasting my notes for the
> E310 which had a different sysroot. Once I made the change to the proper
> one, it seems like it got past the rfnoc issue (or I haven't hit it yet
> with this new error).
> >
> > I am not getting:
> > - Found PkgConfig:
> /opt/gnuradio/N310/sysroots/x86_64-oesdk-linux/usr/bin/pkg-config (found
> version "0.29.2")
> > -- Found UHD:
> /opt/gnuradio/N310/sysroots/cortexa9hf-neon-oe-linux-gnueabi/usr/lib/libuhd.so
>
> > -- Found PythonLibs:
> /opt/gnuradio/N310/sysroots/cortexa9hf-neon-oe-linux-gnueabi/usr/lib/
> libpython2.7.so (found suitable version "2.7.14", minimum required is
> "2")
> > CMake Warning at
> /opt/gnuradio/N310/sysroots/x86_64-oesdk-linux/usr/share/cmake-3.10/Modules/FindQt4.cmake:620
> (message):
> > /usr/bin/qmake-qt4 reported QT_INSTALL_LIBS as "/usr/lib64" but QtCore
> > could not be found there. Qt is NOT installed correctly for the target
> > build environment.
> > Call Stack (most recent call first):
> > CMakeLists.txt:149 (find_package)
> >
> > CMake Error at CMakeLists.txt:151 (message):
> > Qt not found.
> >
> > -- Configuring incomplete, errors occurred!
> > See also
> "/opt/gnuradio/N310/src/gr-ettus/n310-build/CMakeFiles/CMakeOutput.log".
> > See also
> "/opt/gnuradio/N310/src/gr-ettus/n310-build/CMakeFiles/CMakeError.log".
> >
> > I feel like I had this issue before with an E310 build and Phil B had to
> make mods to the toolchain. Has anyone else seen and got around this?
> >
> >
> >
> > - Original Message - Subject: cross-compiling for N310
> > From: "Jason Matusiak" 
> > Date: 12/17/18 1:35 pm
> > To: "Ettus Mail List" 
> >
> > Has anyone successfully created a new build for an N310 (RFNoC version
> in particular)? I was going to bring it up to date, but seem to be having
> issues.
> >
> > I ran: uhd_images_downloader -t sdimg -v
> > To get the *.sh image for cross-compiling:
> oecore-x86_64-cortexa9hf-neon-toolchain-nodistro.0.sh
> >
> > I then install it like I do for the E310.
> >
> > I create a src directory and pull down uhd and its sub-module fpga-src.
> I've tried main, master, and UHD-3.13, and they all build fine, but give me
> issues later on. In my cmake I make sure to have -DENABLE_RFNOC=ON and I
> see it checked when I run cmake-gui.
> >
> > I then pull down gnuradio, and build like I normally do.
> >
> > Lastly, I pull down gr-ettus. When I run: cmake
> -DCMAKE_TOOLCHAIN_FILE=$PREFIX/src/gnuradio/cmake/Toolchains/oe-sdk_cross.cmake
> -DENABLE_DOXYGEN=OFF -DCMAKE_INSTALL_PREFIX=/usr ..
> >
> > It mostly works and then errors out with:
> >
> > -- Found PkgConfig:
> /opt/gnuradio/N310/sysroots/x86_64-oesdk-linux/usr/bin/pkg-config (found
>

[USRP-users] Creating RFNOC block that changes stream rate

2018-12-18 Thread Andrew Danowitz via USRP-users

Hi all,

I'm trying to create an rfnoc block that takes in a stream of data at
Sample rate n, does some processing to turn i-q values into real samples,
and outputs data at a rate of n/2 by packing real values into both i and q
channels of the output stream. I've tried to incorporate the
axi_rate_change block and the axi_tag_time block a-la noc_block_ddc, but
whenever I try to run it I keep getting a timeout error. If I take out the
channel packing block and keep the rate n-to-n, the module works fine.

Does anyone have any advice?

Thanks,
Andrew

-- 

Information contained, linked, or attached to this email and all verbal 
communications from WhiteFox Defense to your entity in the prior 30 days 
constitute proprietary and confidential information unless otherwise 
indicated and is therefore subject to obligations in any executed 
confidentiality agreements. Further, this email is intended solely for the 
use of the individual or entity to whom they are addressed. If you are not 
the intended recipient and this message has been addressed to you in error, 
please promptly notify i...@whitefoxdefense.com 
 and destroy all copies of the message and 
any attachments. This email and attachments may contain technical data as 
defined in the International Traffic In Arms Regulations (ITAR) 22 CFR 
120.10 or the Export Administration Regulations (EAR) 15 CFR Parts 730 – 
780.  Export of this material may be controlled by these regulations and 
may not be exported or transferred to non-U.S. persons without prior 
written approval from the U.S. government.
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] cross-compiling for N310

2018-12-18 Thread Jason Matusiak via USRP-users

I got it by running: uhd_images_downloader -t sdk -t n3xx
 
based on instructions here: 
https://files.ettus.com/manual/page_usrp_n3xx.html#n3xx_software_dev_sdk
 
It does not appear to have gnuradio installed
 
OK, gnuradio seems to build fine for cross-compile, it is when I get to the 
gr-ettus step which is next (needed for RFNoC).  I haven't tried running 
gnuradio, but it builds.
 
 
- Original Message - Subject: Re: [USRP-users] cross-compiling 
for N310
From: "Philip Balister" 
Date: 12/18/18 10:25 am
To: "Jason Matusiak" , "Ettus Mail List" 


On 12/18/2018 08:17 AM, Jason Matusiak via USRP-users wrote:
 > It looks like qt4 was not included in the cross-compile build. If I look at 
 > my working e300 cross-compile, I have a folder: 
 > /opt/gnuradio/e300/sysroots/armv7ahf-neon-oe-linux-gnueabi/usr/include/qt4/
 > 
 > (in fact, there is a tone of stuff in that include).
 > 
 > If I look in the N310 directory, it doesn't exist: 
 > /opt/gnuradio/N310/sysroots/armv7ahf-neon-oe-linux-gnueabi/usr/include/
 > 
 > (and there are very few files/folders in there at all.
 > 
 > I will look into building it by hand, but I am guessing that it will just 
 > lead to more things needing to be cross-compiled
 
 Where did you get the toolchain? Does the N310 have gnuradio installed?
 Feels like the sdk may not have the packages you need to build gnuradio
 installed.
 
 Try disabling qt4 and seeing if you can get gnuradio to build like that
 as a test.
 
 Philip
 
 > 
 > 
 > 
 > - Original Message - Subject: RE: cross-compiling for N310
 > From: "Jason Matusiak" 
 > Date: 12/17/18 3:15 pm
 > To: "Ettus Mail List" 
 > 
 > OK, I see the first mistake. I was copying-and-pasting my notes for the E310 
 > which had a different sysroot. Once I made the change to the proper one, it 
 > seems like it got past the rfnoc issue (or I haven't hit it yet with this 
 > new error).
 > 
 > I am not getting:
 > - Found PkgConfig: 
 > /opt/gnuradio/N310/sysroots/x86_64-oesdk-linux/usr/bin/pkg-config (found 
 > version "0.29.2") 
 > -- Found UHD: 
 > /opt/gnuradio/N310/sysroots/cortexa9hf-neon-oe-linux-gnueabi/usr/lib/libuhd.so
 >  
 > -- Found PythonLibs: 
 > /opt/gnuradio/N310/sysroots/cortexa9hf-neon-oe-linux-gnueabi/usr/lib/libpython2.7.so
 >  (found suitable version "2.7.14", minimum required is "2") 
 > CMake Warning at 
 > /opt/gnuradio/N310/sysroots/x86_64-oesdk-linux/usr/share/cmake-3.10/Modules/FindQt4.cmake:620
 >  (message):
 > /usr/bin/qmake-qt4 reported QT_INSTALL_LIBS as "/usr/lib64" but QtCore
 > could not be found there. Qt is NOT installed correctly for the target
 > build environment.
 > Call Stack (most recent call first):
 > CMakeLists.txt:149 (find_package)
 > 
 > CMake Error at CMakeLists.txt:151 (message):
 > Qt not found.
 > 
 > -- Configuring incomplete, errors occurred!
 > See also 
 > "/opt/gnuradio/N310/src/gr-ettus/n310-build/CMakeFiles/CMakeOutput.log".
 > See also 
 > "/opt/gnuradio/N310/src/gr-ettus/n310-build/CMakeFiles/CMakeError.log".
 > 
 > I feel like I had this issue before with an E310 build and Phil B had to 
 > make mods to the toolchain. Has anyone else seen and got around this?
 > 
 > 
 > 
 > - Original Message - Subject: cross-compiling for N310
 > From: "Jason Matusiak" 
 > Date: 12/17/18 1:35 pm
 > To: "Ettus Mail List" 
 > 
 > Has anyone successfully created a new build for an N310 (RFNoC version in 
 > particular)? I was going to bring it up to date, but seem to be having 
 > issues.
 > 
 > I ran: uhd_images_downloader -t sdimg -v
 > To get the *.sh image for cross-compiling: 
 > oecore-x86_64-cortexa9hf-neon-toolchain-nodistro.0.sh
 > 
 > I then install it like I do for the E310.
 > 
 > I create a src directory and pull down uhd and its sub-module fpga-src. I've 
 > tried main, master, and UHD-3.13, and they all build fine, but give me 
 > issues later on. In my cmake I make sure to have -DENABLE_RFNOC=ON and I see 
 > it checked when I run cmake-gui.
 > 
 > I then pull down gnuradio, and build like I normally do.
 > 
 > Lastly, I pull down gr-ettus. When I run: cmake 
 > -DCMAKE_TOOLCHAIN_FILE=$PREFIX/src/gnuradio/cmake/Toolchains/oe-sdk_cross.cmake
 >  -DENABLE_DOXYGEN=OFF -DCMAKE_INSTALL_PREFIX=/usr ..
 > 
 > It mostly works and then errors out with:
 > 
 > -- Found PkgConfig: 
 > /opt/gnuradio/N310/sysroots/x86_64-oesdk-linux/usr/bin/pkg-config (found 
 > version "0.29.2") 
 > -- Found UHD: 
 > /opt/gnuradio/N310/sysroots/cortexa9hf-neon-oe-linux-gnueabi/usr/lib/libuhd.so
 >  
 > CMake Error at CMakeLists.txt:140 (message):
 > RFNoC not found.
 > 
 > -- Configuring incomplete, errors occurred!
 > See also 
 > "/opt/gnuradio/N310/src/gr-ettus/n310-build/CMakeFiles/CMakeOutput.log".
 > See also 
 > "/opt/gnuradio/N310/src/gr-ettus/n310-build/CMakeFiles/CMakeError.log".
 > 
 > In the past, I thought that that usually means uhd was not built properly to 
 > have RFNoC enabled, but it looks to me like it is here.
 > Anyone happen

Re: [USRP-users] cross-compiling for N310

2018-12-18 Thread Philip Balister via USRP-users

On 12/18/2018 08:17 AM, Jason Matusiak via USRP-users wrote:
> It looks like qt4 was not included in the cross-compile build.  If I look at 
> my working e300 cross-compile, I have a folder: 
> /opt/gnuradio/e300/sysroots/armv7ahf-neon-oe-linux-gnueabi/usr/include/qt4/
>  
> (in fact, there is a tone of stuff in that include).
>  
> If I look in the N310 directory, it doesn't exist: 
> /opt/gnuradio/N310/sysroots/armv7ahf-neon-oe-linux-gnueabi/usr/include/
>  
> (and there are very few files/folders in there at all.
>  
> I will look into building it by hand, but I am guessing that it will just 
> lead to more things needing to be cross-compiled

Where did you get the toolchain? Does the N310 have gnuradio installed?
Feels like the sdk may not have the packages you need to build gnuradio
installed.

Try disabling qt4 and seeing if you can get gnuradio to build like that
as a test.

Philip

>  
>  
>  
> - Original Message - Subject: RE: cross-compiling for N310
> From: "Jason Matusiak" 
> Date: 12/17/18 3:15 pm
> To: "Ettus Mail List" 
> 
>  OK, I see the first mistake.  I was copying-and-pasting my notes for the 
> E310 which had a different sysroot.  Once I made the change to the proper 
> one, it seems like it got past the rfnoc issue (or I haven't hit it yet with 
> this new error).
>  
> I am not getting:
> - Found PkgConfig: 
> /opt/gnuradio/N310/sysroots/x86_64-oesdk-linux/usr/bin/pkg-config (found 
> version "0.29.2") 
> -- Found UHD: 
> /opt/gnuradio/N310/sysroots/cortexa9hf-neon-oe-linux-gnueabi/usr/lib/libuhd.so
>  
> -- Found PythonLibs: 
> /opt/gnuradio/N310/sysroots/cortexa9hf-neon-oe-linux-gnueabi/usr/lib/libpython2.7.so
>  (found suitable version "2.7.14", minimum required is "2") 
> CMake Warning at 
> /opt/gnuradio/N310/sysroots/x86_64-oesdk-linux/usr/share/cmake-3.10/Modules/FindQt4.cmake:620
>  (message):
>  /usr/bin/qmake-qt4 reported QT_INSTALL_LIBS as "/usr/lib64" but QtCore
>  could not be found there. Qt is NOT installed correctly for the target
>  build environment.
> Call Stack (most recent call first):
>  CMakeLists.txt:149 (find_package)
>  
> CMake Error at CMakeLists.txt:151 (message):
>  Qt not found.
>  
> -- Configuring incomplete, errors occurred!
> See also 
> "/opt/gnuradio/N310/src/gr-ettus/n310-build/CMakeFiles/CMakeOutput.log".
> See also 
> "/opt/gnuradio/N310/src/gr-ettus/n310-build/CMakeFiles/CMakeError.log".
>   
>  I feel like I had this issue before with an E310 build and Phil B had to 
> make mods to the toolchain.  Has anyone else seen and got around this?
>  
>  
>  
> - Original Message - Subject: cross-compiling for N310
> From: "Jason Matusiak" 
> Date: 12/17/18 1:35 pm
> To: "Ettus Mail List" 
> 
>  Has anyone successfully created a new build for an N310 (RFNoC version in 
> particular)?  I was going to bring it up to date, but seem to be having 
> issues.
>  
> I ran: uhd_images_downloader -t sdimg -v
> To get the *.sh image for cross-compiling: 
> oecore-x86_64-cortexa9hf-neon-toolchain-nodistro.0.sh
>  
> I then install it like I do for the E310.
>  
> I create a src directory and pull down uhd and its sub-module fpga-src.  I've 
> tried main, master, and UHD-3.13, and they all build fine, but give me issues 
> later on.  In my cmake I make sure to have -DENABLE_RFNOC=ON and I see it 
> checked when I run cmake-gui.
>  
> I then pull down gnuradio, and build like I normally do.
>  
> Lastly, I pull down gr-ettus.  When I run: cmake 
> -DCMAKE_TOOLCHAIN_FILE=$PREFIX/src/gnuradio/cmake/Toolchains/oe-sdk_cross.cmake
>  -DENABLE_DOXYGEN=OFF -DCMAKE_INSTALL_PREFIX=/usr ..
>  
> It mostly works and then errors out with:
>  
> -- Found PkgConfig: 
> /opt/gnuradio/N310/sysroots/x86_64-oesdk-linux/usr/bin/pkg-config (found 
> version "0.29.2") 
> -- Found UHD: 
> /opt/gnuradio/N310/sysroots/cortexa9hf-neon-oe-linux-gnueabi/usr/lib/libuhd.so
>  
> CMake Error at CMakeLists.txt:140 (message):
>  RFNoC not found.
>  
> -- Configuring incomplete, errors occurred!
> See also 
> "/opt/gnuradio/N310/src/gr-ettus/n310-build/CMakeFiles/CMakeOutput.log".
> See also 
> "/opt/gnuradio/N310/src/gr-ettus/n310-build/CMakeFiles/CMakeError.log".
>   
>  In the past, I thought that that usually means uhd was not built properly to 
> have RFNoC enabled, but it looks to me like it is here.
>  Anyone happen to see what I am missing here?
> 
> 
> 
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> 

___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] cross-compiling for N310

2018-12-18 Thread Jason Matusiak via USRP-users

It looks like qt4 was not included in the cross-compile build.  If I look at my 
working e300 cross-compile, I have a folder: 
/opt/gnuradio/e300/sysroots/armv7ahf-neon-oe-linux-gnueabi/usr/include/qt4/
 
(in fact, there is a tone of stuff in that include).
 
If I look in the N310 directory, it doesn't exist: 
/opt/gnuradio/N310/sysroots/armv7ahf-neon-oe-linux-gnueabi/usr/include/
 
(and there are very few files/folders in there at all.
 
I will look into building it by hand, but I am guessing that it will just lead 
to more things needing to be cross-compiled
 
 
 
- Original Message - Subject: RE: cross-compiling for N310
From: "Jason Matusiak" 
Date: 12/17/18 3:15 pm
To: "Ettus Mail List" 

 OK, I see the first mistake.  I was copying-and-pasting my notes for the E310 
which had a different sysroot.  Once I made the change to the proper one, it 
seems like it got past the rfnoc issue (or I haven't hit it yet with this new 
error).
 
I am not getting:
- Found PkgConfig: 
/opt/gnuradio/N310/sysroots/x86_64-oesdk-linux/usr/bin/pkg-config (found 
version "0.29.2") 
-- Found UHD: 
/opt/gnuradio/N310/sysroots/cortexa9hf-neon-oe-linux-gnueabi/usr/lib/libuhd.so 
-- Found PythonLibs: 
/opt/gnuradio/N310/sysroots/cortexa9hf-neon-oe-linux-gnueabi/usr/lib/libpython2.7.so
 (found suitable version "2.7.14", minimum required is "2") 
CMake Warning at 
/opt/gnuradio/N310/sysroots/x86_64-oesdk-linux/usr/share/cmake-3.10/Modules/FindQt4.cmake:620
 (message):
 /usr/bin/qmake-qt4 reported QT_INSTALL_LIBS as "/usr/lib64" but QtCore
 could not be found there. Qt is NOT installed correctly for the target
 build environment.
Call Stack (most recent call first):
 CMakeLists.txt:149 (find_package)
 
CMake Error at CMakeLists.txt:151 (message):
 Qt not found.
 
-- Configuring incomplete, errors occurred!
See also 
"/opt/gnuradio/N310/src/gr-ettus/n310-build/CMakeFiles/CMakeOutput.log".
See also "/opt/gnuradio/N310/src/gr-ettus/n310-build/CMakeFiles/CMakeError.log".
  
 I feel like I had this issue before with an E310 build and Phil B had to make 
mods to the toolchain.  Has anyone else seen and got around this?
 
 
 
- Original Message - Subject: cross-compiling for N310
From: "Jason Matusiak" 
Date: 12/17/18 1:35 pm
To: "Ettus Mail List" 

 Has anyone successfully created a new build for an N310 (RFNoC version in 
particular)?  I was going to bring it up to date, but seem to be having issues.
 
I ran: uhd_images_downloader -t sdimg -v
To get the *.sh image for cross-compiling: 
oecore-x86_64-cortexa9hf-neon-toolchain-nodistro.0.sh
 
I then install it like I do for the E310.
 
I create a src directory and pull down uhd and its sub-module fpga-src.  I've 
tried main, master, and UHD-3.13, and they all build fine, but give me issues 
later on.  In my cmake I make sure to have -DENABLE_RFNOC=ON and I see it 
checked when I run cmake-gui.
 
I then pull down gnuradio, and build like I normally do.
 
Lastly, I pull down gr-ettus.  When I run: cmake 
-DCMAKE_TOOLCHAIN_FILE=$PREFIX/src/gnuradio/cmake/Toolchains/oe-sdk_cross.cmake 
-DENABLE_DOXYGEN=OFF -DCMAKE_INSTALL_PREFIX=/usr ..
 
It mostly works and then errors out with:
 
-- Found PkgConfig: 
/opt/gnuradio/N310/sysroots/x86_64-oesdk-linux/usr/bin/pkg-config (found 
version "0.29.2") 
-- Found UHD: 
/opt/gnuradio/N310/sysroots/cortexa9hf-neon-oe-linux-gnueabi/usr/lib/libuhd.so 
CMake Error at CMakeLists.txt:140 (message):
 RFNoC not found.
 
-- Configuring incomplete, errors occurred!
See also 
"/opt/gnuradio/N310/src/gr-ettus/n310-build/CMakeFiles/CMakeOutput.log".
See also "/opt/gnuradio/N310/src/gr-ettus/n310-build/CMakeFiles/CMakeError.log".
  
 In the past, I thought that that usually means uhd was not built properly to 
have RFNoC enabled, but it looks to me like it is here.
 Anyone happen to see what I am missing here?
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Phase Offset problem when center frequency is changed dynamically

2018-12-18 Thread Arun kumar Verma via USRP-users

Dear Marcus
I  found the real problem and problem is that when i use set_command_time in 
loop then only problem exist, if do not use this my loop is getting executed 
properly. But for phase synchronization i have to use set_command_timeAny 
suggestion?
Arun Verma

  From: Arun kumar Verma via USRP-users 
 To: Marcus D. Leech ; "usrp-users@lists.ettus.com" 

 Sent: Tuesday, 18 December 2018 2:16 PM
 Subject: Re: [USRP-users] Phase Offset problem when center frequency is 
changed dynamically

Dear Marcus
The problem is solved by setting RF policy manual for RF and DSP both and 
passing uhd::tune_request_t  object as parameter to set_center_freq function, 
but now i getting one more issues that after 35-40 iteration my application is 
getting assertion because of  "EnvironmentError: IOError: Block ctrl 
(CE_00_Port_30) no response packet - AssertionError: bool(buff)" and after that 
I have to start X310 again then only it responds.

My setup is X310 with single TwinRX module and I want to measure the phase 
difference from 10-6000MHz and put into look-up table. I am using B205-mini as 
transmitter and it is connected with the power divider to X310 input. I am 
working on phase interferometer direction finding with 5 element circular array 
antennae connected to 5 to 2 Antenna Switch matrix which is connected to single 
 TwinRX.

I am not sure how  set_center_freq command is implemented internally for 
TwinRX,  but i expect that when i set this command, only LOs should be tuned 
for desired frequencies plus some filter selection of that band. I expect that 
settling time for synthesizer would be around maximum of 300uS and for some 
other stuff like filter selection , i think in  500uS I should be able to set 
everything. At present I have to use set_command_time so that my channels are 
synchronized. Can you suggest the fastest way to implementing frequency sweep 
for two channels as i need scan rate around 40GHz.
Regards,Arun Verma

  From: Marcus D. Leech via USRP-users 
 To: usrp-users@lists.ettus.com 
 Sent: Monday, 17 December 2018 10:36 PM
 Subject: Re: [USRP-users] Phase Offset problem when center frequency is 
changed dynamically

 On 12/15/2018 08:02 AM, Arun kumar Verma via USRP-users wrote:

  Dear Users 
  I am facing problem of phase offset when i change center frequency 
dynamically for TwinRX with X310 setup. Here is my C++ code, 

  Please advise 

usrp_source1->set_rx_lo_source("internal",uhd::usrp::multi_usrp::ALL_LOS,0);

usrp_source1->set_rx_lo_source("companion",uhd::usrp::multi_usrp::ALL_LOS,1); 

usrp_sourceDOA1->set_command_time(usrp_sourceDOA1->get_time_now() + 
uhd::time_spec_t(0.01));
     usrp_sourceDOA1->set_center_freq(m_CenterFrequency,0);
     usrp_sourceDOA1->set_center_freq(m_CenterFrequency,1);
     usrp_sourceDOA1->clear_command_time(); 
  I feel set_command_time is not working properly. When i start the X310 my 
phase difference is almost zero but as i change my frequency pjhase difference 
is random in nature. 
  Regards, Arun Verma 

 COuld you explain your setup a bit more here.

 I now see that you have both usrp_source1 and usrp_sourceDOA1, but I think you 
said that you have a single X310, so I'm confused about
   why you apparently have two USRP sources here.

 ___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

   ___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

   ___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Phase Offset problem when center frequency is changed dynamically

2018-12-18 Thread Arun kumar Verma via USRP-users

Dear Marcus
The problem is solved by setting RF policy manual for RF and DSP both and 
passing uhd::tune_request_t  object as parameter to set_center_freq function, 
but now i getting one more issues that after 35-40 iteration my application is 
getting assertion because of  "EnvironmentError: IOError: Block ctrl 
(CE_00_Port_30) no response packet - AssertionError: bool(buff)" and after that 
I have to start X310 again then only it responds.

My setup is X310 with single TwinRX module and I want to measure the phase 
difference from 10-6000MHz and put into look-up table. I am using B205-mini as 
transmitter and it is connected with the power divider to X310 input. I am 
working on phase interferometer direction finding with 5 element circular array 
antennae connected to 5 to 2 Antenna Switch matrix which is connected to single 
 TwinRX.

I am not sure how  set_center_freq command is implemented internally for 
TwinRX,  but i expect that when i set this command, only LOs should be tuned 
for desired frequencies plus some filter selection of that band. I expect that 
settling time for synthesizer would be around maximum of 300uS and for some 
other stuff like filter selection , i think in  500uS I should be able to set 
everything. At present I have to use set_command_time so that my channels are 
synchronized. Can you suggest the fastest way to implementing frequency sweep 
for two channels as i need scan rate around 40GHz.
Regards,Arun Verma

  From: Marcus D. Leech via USRP-users 
 To: usrp-users@lists.ettus.com 
 Sent: Monday, 17 December 2018 10:36 PM
 Subject: Re: [USRP-users] Phase Offset problem when center frequency is 
changed dynamically
   
 On 12/15/2018 08:02 AM, Arun kumar Verma via USRP-users wrote:
  
  Dear Users 
  I am facing problem of phase offset when i change center frequency 
dynamically for TwinRX with X310 setup. Here is my C++ code, 
  
  Please advise 
     
usrp_source1->set_rx_lo_source("internal",uhd::usrp::multi_usrp::ALL_LOS,0);
    
usrp_source1->set_rx_lo_source("companion",uhd::usrp::multi_usrp::ALL_LOS,1); 
          
usrp_sourceDOA1->set_command_time(usrp_sourceDOA1->get_time_now() + 
uhd::time_spec_t(0.01));
     usrp_sourceDOA1->set_center_freq(m_CenterFrequency,0);
     usrp_sourceDOA1->set_center_freq(m_CenterFrequency,1);
     usrp_sourceDOA1->clear_command_time(); 
  I feel set_command_time is not working properly. When i start the X310 my 
phase difference is almost zero but as i change my frequency pjhase difference 
is random in nature. 
  Regards, Arun Verma 
  
 COuld you explain your setup a bit more here.
 
 I now see that you have both usrp_source1 and usrp_sourceDOA1, but I think you 
said that you have a single X310, so I'm confused about
   why you apparently have two USRP sources here.
 
 
 ___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com


   ___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Hello,

2018-12-18 Thread Pablo González Fernández via USRP-users

Thanks Ian!

El vie., 14 dic. 2018 a las 17:25, Ian Buckley ()
escribió:

> N310 has a different ADI radio chip and since I did not work on the design
> I don’t want to give you misleading advice on that one.
> N210 is different, as it uses the standard Ettus interchangeable daughter
> board standard. Some daughterboards have features to fully phase align
> synthesizers after a retune, some not depending which chips they are based
> on. UBX for example can be fully phase aligned, but I don’t think WBX can.
> I don’t recall the full product matrix as to which daughter boards will
> fully align phase.
> -Ian
>
>
> On Dec 14, 2018, at 3:53 AM, Pablo González Fernández <
> pgonza...@gradiant.org> wrote:
>
> Thanks Ian. Am I correct to assume that this is not the case for N210?
> What about for the N310? I am not so sure in this case, as it uses an AD
> chip as the B210.
>
> Regards
>
> El mié., 12 dic. 2018 a las 15:26, Ian Buckley ()
> escribió:
>
>> Brais,
>> Sam sent you a little bit the wrong direction there, the B200mini has the
>> PLL phase noise issue that precludes use in a MIMO system.
>> The B210 can be fully time and frequency locked to an external 10MHz
>> reference and PPS.
>> What is slightly tricky about using multiple B210’s in a MIMO
>> configuration is that the internal frequency synthesizers will have a
>> residual phase ambiguity after they have been configured, and this must be
>> characterized and compensated for after any retune.
>>
>> Watch this to gain insight into the issues involved:
>> https://www.analog.com/en/education/education-library/webcasts/developing-multiple-input-multiple-output.html
>> -Ian
>>
>> On Dec 12, 2018, at 2:30 AM, Brais Ares via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>> Thanks Sam! If I understand correctly the link that you refer to, it is
>> possible to obtain time and phase synchronization with B210s, so the only
>> issue would be to compensate phase offset which could be done by software.
>> Could you elaborate a little bit more? I'm probably missunderstading the
>> thread you link, but from it I take that MIMO implementations are possible
>> with B210. Also, can you provide any link for the difference between B210
>> and N210 that allows to use the later but not the former?
>>
>> Regards,
>> Brais.
>>
>> ___
>> USRP-users mailing list
>> USRP-users@lists.ettus.com
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>>
>>
>
>
>

-- 

[image: logo_170x100px.png] 



Pablo González Fernández
Investigador - Desarrollador Senior | Área de Comunicaciones Avanzadas
Senior Researcher - Developer | Advanced Communications Department



Ph. (+34) 986 120 430  Ext. 3016
pgonza...@gradiant.org  |  www.gradiant.org

[image: Iconos Redes Sociales GRD Firma email-01]
  [image: Iconos Redes Sociales GRD
Firma email-02]   [image: Iconos Redes
Sociales GRD Firma email-03] 
 [image: Iconos Redes Sociales GRD Firma email-04]

Take care of the environment. Try not to print this email.
The information contained in this email message may be confidential
information, and may also be the subject of legal professional privilege.
If you are not the intended recipient, any use, interference with,
disclosure or copying of this material is unauthorized and prohibited.
Please inform us immediately and destroy the email. Thank you for your
cooperation.
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Creating RFNOC block that changes stream rate

Re: [USRP-users] Creating RFNOC block that changes stream rate

Re: [USRP-users] Creating RFNOC block that changes stream rate

Re: [USRP-users] X310 xpr Files

[USRP-users] X310 xpr Files

Re: [USRP-users] Phase Offset problem when center frequency is changed dynamically

Re: [USRP-users] cross-compiling for N310

Re: [USRP-users] Creating RFNOC block that changes stream rate

Re: [USRP-users] cross-compiling for N310

[USRP-users] Creating RFNOC block that changes stream rate

Re: [USRP-users] cross-compiling for N310

Re: [USRP-users] cross-compiling for N310

Re: [USRP-users] cross-compiling for N310

Re: [USRP-users] Phase Offset problem when center frequency is changed dynamically

Re: [USRP-users] Phase Offset problem when center frequency is changed dynamically

Re: [USRP-users] Hello,

16 matches

Site Navigation

Mail list logo

Footer information