Re: [USRP-users] Live rate changes within an RFNOC block

[Andrew Danowitz via USRP-users]

Thanks for the feedback. I've simulated the block and got it working with
no errors over a few million samples as long as I assert axi_rate_change's
clear when I change N (I've been swapping rates once every 200
transmissions in the testbench). I still get the timeout error in hardware,
though. Could clearing be messing up some stored packet header information
that simulation wouldn't catch?

Thanks,
Andrew

On Mon, Jan 28, 2019 at 4:34 PM Jonathon Pendlum 
wrote:

> Hi Andrew,
>
> Have you simulated or used chipscope on your block? There is an output
> from axi rate change called "error_extra_outputs" that can be useful. Does
> it assert ever assert? If so, that means your user code has output more
> samples than axi rate change was expecting. If any extra samples come out,
> that breaks axi rate change's tracking of the input sample to output sample
> ratio, which can eventually lead to a lock up.
>
> Jonathon
>
> On Tue, Jan 29, 2019 at 3:11 AM Andrew Danowitz via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> I have an RFNOC block that, based on a control register can either
>> decimate the signal it's working on or leave the output rate the same as
>> the input rate. If I set the control register to an initial value (either
>> decimate, or not decimate) and let the system run, it works fine in either
>> mode. If I try to change the decimation mode while the block is running, I
>> start getting timeout errors. I currently use the axi_rate_change block to
>> help handle the rate change, and have tried to synchronize changing the
>> block's mode (decimate or not) with the axi_rate_change's clear_user flag.
>> Any thoughts?
>>
>> 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 
<mailto: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] Live rate changes within an RFNOC block

[Andrew Danowitz via USRP-users]

I have an RFNOC block that, based on a control register can either decimate
the signal it's working on or leave the output rate the same as the input
rate. If I set the control register to an initial value (either decimate,
or not decimate) and let the system run, it works fine in either mode. If I
try to change the decimation mode while the block is running, I start
getting timeout errors. I currently use the axi_rate_change block to help
handle the rate change, and have tried to synchronize changing the block's
mode (decimate or not) with the axi_rate_change's clear_user flag. Any
thoughts?

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] Creating RFNOC block that changes stream rate

[Andrew Danowitz via USRP-users]

Hi all,

Thanks for all of your help. Once I annotated the signals to debug, Vivado
started failing on creating a bitstream. It turns out I had labeled the
wrong direction for the master tready signal which in default synthesis was
driven to 0.

Thanks,
Andrew

On Fri, Dec 21, 2018 at 11:33 AM Andrew Danowitz 
wrote:

> Hi all,
>
> I tried building a control block like the one on github, but still no
> luck. I have a jtag kit on the way, so I'll keep you posted.
>
> Thanks!
> Andrew
>
> On Wed, Dec 19, 2018 at 7:15 PM Jon Pendlum  wrote:
>
>> Hi Andrew,
>>
>> You'll need to have a Xilinx USB programmer (or Digilent JTAG-HS3
>> probably works too), purchase this kit
>> https://www.ettus.com/product/details/E-JTAG-4, and follow these
>> instructions:
>> https://www.ettus.com/content/files/E-Series_JTAG-AVR_Cable_Getting_Started_Guide_.pdf.
>> For setting up the ILA and debugging, see:
>> https://kb.ettus.com/Debugging_FPGA_images.
>>
>> Jonathon
>>
>> On Thu, Dec 20, 2018 at 7:47 AM Andrew Danowitz <
>> and...@whitefoxdefense.com> wrote:
>>
>>> Hi John,
>>>
>>> Is there any documentation on using the ILA on an e310 that's running
>>> gnuradio directly?
>>>
>>> Thanks,
>>> Andrew
>>>
>>> On Tue, Dec 18, 2018 at 8:36 PM Jon Pendlum 
>>> wrote:
>>>
>>>> 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 

Re: [USRP-users] Vivado Simulation not returning to testbench after a certain time

[Andrew Danowitz via USRP-users]

Okay, I think I figured this one out. It seems like the queue structure
used to hold the payload for each packet wasn't getting properly
deleted/reinitialized between loop runs, so the queue got bigger with each
packet run until it became too big for xsim to handle leading to a freeze.
To fix, I manually deleted its elements between runs of the loop using
send_payload={}.

Thanks,
Andrew

On Fri, Dec 21, 2018 at 2:13 PM Andrew Danowitz 
wrote:

> Hi all,
>
> I'm trying to run a Vivado simulation to run 2mb of pre-recorded data
> through an RFNOC IP block. I've modified the testbench created by
> rfnocmodtool for this purpose. After sending about 5-10k data samples and
> recording the results, the Vivado flow seems to ignore future testbench
> commands (using display statements, breakpoints, and such, I've determined
> it will reach the end of the forked send/receive routines, and, after a
> while, rather than loop back for another round of send receive on more
> data, Vivado just stops executing the simulation commands in the
> testbench). I've tried restructuring how the simulation works (all 2mb of
> data as one giant payload, breaking the data into smaller chunks and
> iterating over send receive, etc.), and with each case Vivado just seems to
> eventually stop doing anything with the testbench commands. The simulation
> doesn't crash, and from the waveform all of the clk and other signals keep
> running, but no new data is ever sent. Any thoughts?
>
> 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] Vivado Simulation not returning to testbench after a certain time

[Andrew Danowitz via USRP-users]

Hi all,

I'm trying to run a Vivado simulation to run 2mb of pre-recorded data
through an RFNOC IP block. I've modified the testbench created by
rfnocmodtool for this purpose. After sending about 5-10k data samples and
recording the results, the Vivado flow seems to ignore future testbench
commands (using display statements, breakpoints, and such, I've determined
it will reach the end of the forked send/receive routines, and, after a
while, rather than loop back for another round of send receive on more
data, Vivado just stops executing the simulation commands in the
testbench). I've tried restructuring how the simulation works (all 2mb of
data as one giant payload, breaking the data into smaller chunks and
iterating over send receive, etc.), and with each case Vivado just seems to
eventually stop doing anything with the testbench commands. The simulation
doesn't crash, and from the waveform all of the clk and other signals keep
running, but no new data is ever sent. Any thoughts?

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] Creating RFNOC block that changes stream rate

[Andrew Danowitz via USRP-users]

Hi all,

I tried building a control block like the one on github, but still no luck.
I have a jtag kit on the way, so I'll keep you posted.

Thanks!
Andrew

On Wed, Dec 19, 2018 at 7:15 PM Jon Pendlum  wrote:

> Hi Andrew,
>
> You'll need to have a Xilinx USB programmer (or Digilent JTAG-HS3 probably
> works too), purchase this kit
> https://www.ettus.com/product/details/E-JTAG-4, and follow these
> instructions:
> https://www.ettus.com/content/files/E-Series_JTAG-AVR_Cable_Getting_Started_Guide_.pdf.
> For setting up the ILA and debugging, see:
> https://kb.ettus.com/Debugging_FPGA_images.
>
> Jonathon
>
> On Thu, Dec 20, 2018 at 7:47 AM Andrew Danowitz <
> and...@whitefoxdefense.com> wrote:
>
>> Hi John,
>>
>> Is there any documentation on using the ILA on an e310 that's running
>> gnuradio directly?
>>
>> Thanks,
>> Andrew
>>
>> On Tue, Dec 18, 2018 at 8:36 PM Jon Pendlum 
>> wrote:
>>
>>> 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

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

[Andrew Danowitz via USRP-users]

Hi John,

Is there any documentation on using the ILA on an e310 that's running
gnuradio directly?

Thanks,
Andrew

On Tue, Dec 18, 2018 at 8:36 PM Jon Pendlum  wrote:

> 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 att

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

[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 
<mailto: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] Creating RFNOC block that changes stream rate

[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] installing rfnoc using pybombs

[Andrew Danowitz via USRP-users]

Make sure you don't have a version of gnuradio installed through your
repository manager. Sometimes gnuradio will grab the wrong header files if
there are multiple versions installed.

On Tue, Sep 11, 2018 at 10:06 AM, Rob Kossler via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi,
> I just tried to install rfnoc using pybombs according to the RFNoC getting
> started guide.  The build fails with the following messages during the
> gnuradio build.  Any way around this?
> Rob
>
> [ 88%] Built target tags_demo
> [ 88%] Built target _uhd_swig_doc_tag
> [ 88%] Built target uhd_swig_swig_doc
> [ 88%] Built target _uhd_swig_swig_tag
> [ 88%] Built target uhd_swig_gr_uhd_swig_5e3ce
> [ 88%] Building CXX object gr-uhd/swig/CMakeFiles/_uhd_
> swig.dir/uhd_swigPYTHON_wrap.cxx.o
> /home/irisheyes1/rfnoc/src/gnuradio/build/gr-uhd/swig/uhd_swigPYTHON_wrap.cxx:
> In function ‘PyObject* _wrap_time_spec_t_get_system_time(PyObject*,
> PyObject*)’:
> /home/irisheyes1/rfnoc/src/gnuradio/build/gr-uhd/swig/
> uhd_swigPYTHON_wrap.cxx:19511:16: error: ‘get_system_time’ is not a
> member of ‘uhd::time_spec_t’
>result = uhd::time_spec_t::get_system_time();
> ^
> /home/irisheyes1/rfnoc/src/gnuradio/build/gr-uhd/swig/uhd_swigPYTHON_wrap.cxx:
> In function ‘PyObject* _wrap_dboard_iface_set_gpio_debug(PyObject*,
> PyObject*, PyObject*)’:
> /home/irisheyes1/rfnoc/src/gnuradio/build/gr-uhd/swig/
> uhd_swigPYTHON_wrap.cxx:27597:15: error: ‘class uhd::usrp::dboard_iface’
> has no member named ‘set_gpio_debug’
>(arg1)->set_gpio_debug(arg2,arg3);
>^
> /home/irisheyes1/rfnoc/src/gnuradio/build/gr-uhd/swig/uhd_swigPYTHON_wrap.cxx:
> In function ‘PyObject* _wrap_dboard_iface_sptr_set_gpio_debug(PyObject*,
> PyObject*, PyObject*)’:
> /home/irisheyes1/rfnoc/src/gnuradio/build/gr-uhd/swig/
> uhd_swigPYTHON_wrap.cxx:28960:16: error: ‘class uhd::usrp::dboard_iface’
> has no member named ‘set_gpio_debug’
>(*arg1)->set_gpio_debug(arg2,arg3);
>
>
> ___
> 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] E310 cross-compile issue

[Andrew Danowitz via USRP-users]

I've never gotten this error on a cross-compile build, but I have gotten it
on an rfnoc build. In my case, the linker was finding headers from a system
install of gnuradio and trying to use those instead of the fresh ones
generated by make. I might uninstall any repository installs of gnuradio or
temporarily muck with some environment variables so make only finds your
local, up-to-date header files.

On Mon, Sep 10, 2018 at 4:51 AM, Jason Matusiak via USRP-users <
usrp-users@lists.ettus.com> wrote:

> OK, I am having a weird cross-compile issue still.  I am using the latest
> cross-compile files from Philip, but I am getting a weird error that has me
> stumped.
>
> Here are the steps I took, maybe I hosed something up along the way.  I am
> worried about:
> 1 - How I setup the cmakes
> 2 - enabling RFNOC properly
> 3 - that I have proper versions of things (I went and rolled back gnuradio
> to v3.7.12.0 due to it having error, maybe I need to do that for gr-ettus
> as well?)
>
> Here were my steps followed by the error at the end:
>
> 997 mkdir /opt/gnuradio/E310
> 998 sh ./oecore-x86_64-armv7ahf-neon-toolchain-nodistro.0.sh
> 999 cd /opt/gnuradio/E310/
> 1004 unset LD_LIBRARY_PATH
> 1005 source ./environment-setup-armv7ahf-neon-oe-linux-gnueabi
> 1006 echo $CC
> 1007 mkdir src
> 1008 cd src/
> 1009 git clone https://github.com/EttusResearch/uhd.git
> 1010 cd uhd/host && mkdir build && cd build
> 1011 cmake -DCMAKE_TOOLCHAIN_FILE=../host/cmake/Toolchains/oe-sdk_cross.cmake
> -DCMAKE_INSTALL_PREFIX=/usr -DENABLE_E300=ON -DENABLE_RFNOC=ON ..
> 1013 make -j8
> 1014 make install DESTDIR=/opt/gnuradio/E310
> 1015 cd ../../
> 1016 cd ..
> 1018 git clone --recursive https://github.com/gnuradio/gnuradio.git
> 1020 cd gnuradio/
> 1026 git checkout v3.7.12.0
> 1027 mkdir build
> 1028 cd build/
> 1029 cmake -Wno-dev -DCMAKE_TOOLCHAIN_FILE=../
> cmake/Toolchains/oe-sdk_cross.cmake -DCMAKE_INSTALL_PREFIX=/usr
> -DENABLE_GR_VOCODER=OFF -DENABLE_GR_ATSC=OFF -DENABLE_GR_DTV=OFF
> -DENABLE_DOXYGEN=OFF ../
> 1030 make -j8
> 1031 make -j4 install DESTDIR=/opt/gnuradio/E310
> 1032 cd ../../
> 1034 git clone https://github.com/EttusResearch/gr-ettus.git
> 1035 cd gr-ettus/
> 1037 mkdir build
> 1038 cd build && cmake -Wno-dev -DCMAKE_TOOLCHAIN_FILE=../../
> uhd/host/cmake/Toolchains/oe-sdk_cross.cmake -DCMAKE_INSTALL_PREFIX=/usr
> -DENABLE_DOXYGEN=OFF -DUHD_DIR=/opt/gnuradio/e300/usr/lib/cmake/uhd
> -DUHD_INCLUDE_DIRS=/opt/gnuradio/e300/usr/include
> -DUHD_LIBRARIES=/opt/gnuradio/e300/usr/lib ../
> 1039 make -j4
>
>
>
> And then I get the build error for gr-ettus:
>
> [ 90%] Building CXX object swig/CMakeFiles/_ettus_swig.
> dir/ettus_swigPYTHON_wrap.cxx.o
> [ 92%] Linking CXX executable test-ettus
> [ 92%] Built target test-ettus
> /opt/gnuradio/E310/src/gr-ettus/build/swig/ettus_swigPYTHON_wrap.cxx: In
> function ‘PyObject* _wrap_time_spec_t_get_system_time(PyObject*,
> PyObject*)’:
> /opt/gnuradio/E310/src/gr-ettus/build/swig/ettus_swigPYTHON_wrap.cxx:18100:34:
> error: ‘get_system_time’ is not a member of ‘uhd::time_spec_t’
> result = uhd::time_spec_t::get_system_time();
> ^~~
> make[2]: *** [swig/CMakeFiles/_ettus_swig.dir/ettus_swigPYTHON_wrap.cxx.o]
> Error 1
> make[1]: *** [swig/CMakeFiles/_ettus_swig.dir/all] Error 2
> make: *** [all] Error 2
>
>
>
> Philip thought that maybe I was using too old of a version of UHD, but I
> am using the head (hash 6013a), as well as the head of gr-ettus (hash
> 4ef12).  It seems like there is a mismatch somewhere, but I am not sure how
> to resolve this.  Could there be a problem with the cross-compile tools not
> being able to build things?
>
> ___
> 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

Re: [USRP-users] Issues installing GNUradio using PYBOMBS (e3xx-custom-uhd or e3xx-rfnoc)

[Andrew Danowitz via USRP-users]

Forgot to reply all, but see below:

On Wed, Sep 5, 2018 at 12:57 PM, Andrew Danowitz  wrote:

> I've worked around this by:
> 1) going into the prefix directory
> 2) source environment-setup-armv7ahf-vfp-neon-oe-linux-gnueabi (this sets
> your environment to use the built in python)
> 3) download and unzip the six library from pypi
> 4) navigate to the directory with the uncompressed six and run "python
> setup.py install"
> 5) Open a new terminal
> 6) Go back to your prefix directory and source setup_env.sh
> 7) Run pybombs rebuild gnuradio
> 8) Run pybombs install gr-ettus
>
> On Wed, Sep 5, 2018 at 12:35 PM, Philip Balister via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> On 09/05/2018 03:25 PM, Jason Matusiak via USRP-users wrote:
>> > Philip, I know I am digging this up from early in the year, but I
>> didn't see an answer.  I am having the exact same issue with the six
>> package.  Were you ever able to fix this?
>>
>> Pretty sure the sdk from here is fixed:
>>
>> https://www.dropbox.com/sh/4w19l8ixwm2ke24/AAB3aGPAkjqe9SvG32TsyK5Ia?dl=0
>>
>> These are newer images based of rocko I ended creating out of another
>> job. Posted in case others find them useful.
>>
>> Philip
>>
>> >
>> >
>> > - Original Message -On 04/02/2018 06:58 PM, Marcus
>> D. Leech wrote:
>> >  > On 04/02/2018 06:09 PM, Philip Balister wrote:
>> >  >> On 04/02/2018 05:01 PM, MASDR GS wrote:
>> >  >>> I'm having issues with installing GNU radio using PYBOMBS. It
>> >  >>> successfully
>> >  >>> installs the SDK and UHD but once it reaches to GNU Radio I
>> receive a
>> >  >>> missing python six message. I have been using this guide from
>> Ettus for
>> >  >>> reference.
>> >  >>>
>> >  >>> https://kb.ettus.com/Software_Development_on_the_E310_and_E3
>> 12#Preparation_using_PyBOMBS
>> >  >>>
>> >  >>>
>> >  >>>
>> >  >>> -- Python checking for six - python 2 and 3 compatibility library
>> - not
>> >  >>> found
>> >  >>> CMake Error at volk/CMakeLists.txt:93 (message):
>> >  >>>six - python 2 and 3 compatibility library required to build
>> VOLK
>> >  >>>
>> >  >> Looks like the volk added a dependency on python-six and the E300
>> image
>> >  >> doesn't have it. Ettus needs to create a new file system image with
>> that
>> >  >> package installed.
>> >  >>
>> >  >> Philip
>> >  > WHile that is actually, true, in this case the user is doing
>> >  > cross-builds on their PC host, and had installed python-six into
>> their
>> >  > cross-build
>> >  >   environment, and still no joy.
>> >
>> >  Adding python-six-native cleared up my build issue. Likely the real
>> >  solution is regenerate the sdk including the native-sdk version of
>> >  python-six.
>> >
>> >  I'll poke meta-sdr for this soon to cover other users.
>> >
>> >  Philip
>> >
>> >  >
>> >  >
>> >  >>
>> >  >>> -- Configuring incomplete, errors occurred!
>> >  >>>
>> >  >>>
>> >  >>> Someone also posted the same issue but I couldn't find a response
>> to his
>> >  >>> question along with how  to bypass this error. I've tried
>> installing the
>> >  >>> lastest version of  python six-1.11.0 onto my local computer still
>> but
>> >  >>> having no luck. Any guidance or help is appreciated.
>> >  >>>
>> >  >>> http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/
>> 2017-February/023677.html
>> >  >>>
>> >  >>>
>> >  >>>
>> >  >>>
>> >  >>> ___
>> >  >>> Discuss-gnuradio mailing list
>> >  >>> address@hidden
>> >  >>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>> >  >>>
>> >  >> ___
>> >  >> Discuss-gnuradio mailing list
>> >  >> address@hidden
>> >  >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>> >  >
>> >  >
>> >  > ___
>> >  > Discuss-gnuradio mailing list
>> >  > address@hidden
>> >  > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>> >  >
>> >
>> >
>> >
>> > ___
>> > 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
>>
>
>

-- 

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 

Re: [USRP-users] Pulling in AXI_FFT into a OOT module and block

[Andrew Danowitz via USRP-users]

It's true that uhd_image_builder.py will pull in all RFNOC IPs
automatically, but if you go to simulate an OOT rfnoc block that relies on
an IP, in my experience, you have to launch Vivado and add the UHD IP
directory to your project.

On Mon, Sep 3, 2018 at 8:43 PM, Jon Pendlum via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hey Rich,
>
> Do you want to customize the FFT IP or use it as is? If you are using it
> as is, there is no need to do anything. All in-tree code and IP is
> automatically included as part of the FPGA build. If you want to customize
> it, I suggest copying the FFT IP into your OOT and using
> https://github.com/ejk43/rfnoc-ootexample as an example on how to add it
> (see the rfnoc/ip directory). Use viv_modify_ip (available after you source
> setupenv.sh) to customize the FFT IP. You'll want to rename it as well so
> it does not conflict with the in-tree FFT IP.
>
> Jonathon
>
> On Tue, Sep 4, 2018 at 9:58 AM Rich Maes via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> Is there an example of modifying a out of tree (OOT) module and block to
>> pull in a rfnoc library.  Specifically I would like to pull in the AXI_FFT
>> generated code and make my own custom FFT block.  I can’t quite figure out
>> how to modify the CMAKE files, (I assume that is the proper method) to
>> reference that RFNOC library/source.
>>
>> Thanks in advance.
>> Rich
>>
>>
>> ___
>> 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
>
>

-- 

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] axi_round_and_clip busted?

[Andrew Danowitz via USRP-users]

When I try to use axi_round_and_clip in my design, simulation won't run and
has weird internal simulation issues. If I build it into an rfnoc image,
the flow graph doesn't return any data. Has anyone else run into this?

-- 

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] UHD not compatible with FPGA master noc_shell

[Andrew Danowitz via USRP-users]

Hi Brent,

Sounds good. I think the gnuradio pybombs recipe pulls in volk as a
submodule. I think they manage it with the line "gitargs: --recursive" in
their recipe.

On Fri, Aug 31, 2018 at 2:15 PM, Brent Stapleton via USRP-users <
usrp-users@lists.ettus.com> wrote:

> The underlying reason for the mismatches is that, because the uhd/fpga-src
> submodule points to a commit on fpga, we need THAT commit to be on the fpga
> master branch. So, by necessity, we'll always have some amount of time in
> which the two repositories are out of sync (that is, fpga is ahead of uhd).
> This window was longer than usual, and we apologize for that. In the
> future, if hiccups like this are an absolute deal-breaker for you, please
> consider using the submodule pointer, or one of the UHD release branches.
>
> Regarding PyBOMBS, as far as I can tell, there isn't a silver bullet in
> this situation. I like the idea of the uhd-fpga recipe tracking
> uhd/fpga-src, but I don't think git can clone submodules. The best thing
> that comes to mind is to have the uhd-fpga recipe populate the uhd/fpga-src
> submodule, which just saves the effort of manually updating the submodule.
> If you have a better suggestion, we'd love to hear it.
>
> Best Regards,
> Brent
>
> On Thu, Aug 30, 2018 at 5:28 PM Juan Francisco 
> wrote:
>
>> It seems that this issue has tripped up several people.  It might be
>> prudent to not push the FPGA changes to master until you have the
>> corresponding UHD updates ready to go.
>>
>> On Thu, Aug 30, 2018 at 12:49 PM Brent Stapleton <
>> brent.staple...@ettus.com> wrote:
>>
>>> Hi Juan,
>>>
>>> In general, FPGA images built from the submodule in the uhd repository
>>> will be compatible with UHD built from that commit. The HEADs of the two
>>> master branches (uhd and fpga) do not have that guarantee. For example, the
>>> HEAD of uhd master branch (as I write this email) is the git
>>> commit 3b42e6f0, and the submodule points to the commit c3987555 on fpga.
>>> Those both use NoC shell compat number 4.
>>>
>>> We'll get the noc shell compat 5 changes out ASAP though, so don't throw
>>> away that image.
>>>
>>> Regards,
>>> Brent
>>>
>>> On Wed, Aug 29, 2018 at 7:14 PM Juan Francisco via USRP-users <
>>> usrp-users@lists.ettus.com> wrote:
>>>
 There appears to be a compatibility mismatch for the latest FPGA master
 and UHD.  I built a new image from fpga master today, but uhd_usrp_probe
 from UHD (w/ -DENABLE_RFNOC=ON) gives me the error message below:

 [INFO] [0/DmaFIFO_0] Initializing block control (NOC ID:
 0xF1F0D000)
 [ERROR] [0/DmaFIFO_0] Major compat number mismatch for noc_shell:
 Expecting 4, got 5.
 Error: RuntimeError: FPGA component `noc_shell' is revision 5 and UHD
 supports revision 4. Please either upgrade UHD  (recommended) or downgrade
 the FPGA image.

 Thanks,
 Juan
 ___
 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
>
>

-- 

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] Issue with rfnocmodtool generated NOC IDs with leading 0's

[Andrew Danowitz via USRP-users]

I used rfnocmodtool from UHD3.13 to generate a new noc block. The id it
assigned the block had a leading 0. Unfortunately, the tool appears to have
dropped the leading 0 in the auto-generated xml file, which led to grc and
uhd_usrp_probe not being able to find the controller and name for the block.

I don't know if this has been fixed in the latest version, but definitely
something to look into.

-- 

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] UHD not compatible with FPGA master noc_shell

[Andrew Danowitz via USRP-users]

As a note, these mismatches can occur if you use pybombs to manage your
install and do pybombs update uhd-fpga. If you're a pybombs user, my
recommendation is to ignore the uhd-fpga directory altogether, and from
within uhd/fpga run git submodule init, followed by git pull.

Brent, is this something ettus can change in the pybombs recipes?

Thanks,
Andrew

On Thu, Aug 30, 2018 at 9:49 AM, Brent Stapleton via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi Juan,
>
> In general, FPGA images built from the submodule in the uhd repository
> will be compatible with UHD built from that commit. The HEADs of the two
> master branches (uhd and fpga) do not have that guarantee. For example, the
> HEAD of uhd master branch (as I write this email) is the git
> commit 3b42e6f0, and the submodule points to the commit c3987555 on fpga.
> Those both use NoC shell compat number 4.
>
> We'll get the noc shell compat 5 changes out ASAP though, so don't throw
> away that image.
>
> Regards,
> Brent
>
> On Wed, Aug 29, 2018 at 7:14 PM Juan Francisco via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> There appears to be a compatibility mismatch for the latest FPGA master
>> and UHD.  I built a new image from fpga master today, but uhd_usrp_probe
>> from UHD (w/ -DENABLE_RFNOC=ON) gives me the error message below:
>>
>> [INFO] [0/DmaFIFO_0] Initializing block control (NOC ID:
>> 0xF1F0D000)
>> [ERROR] [0/DmaFIFO_0] Major compat number mismatch for noc_shell:
>> Expecting 4, got 5.
>> Error: RuntimeError: FPGA component `noc_shell' is revision 5 and UHD
>> supports revision 4. Please either upgrade UHD  (recommended) or downgrade
>> the FPGA image.
>>
>> Thanks,
>> Juan
>> ___
>> 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
>
>

-- 

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] Multiple instances of RFNOC block in single flow graph

[Andrew Danowitz via USRP-users]

Works like a charm. Thanks!

-Andrew

On Wed, Aug 29, 2018 at 5:34 AM, Jason Matusiak <
ja...@gardettoengineering.com> wrote:

> Andrew,
>
> I have this issue all the time.  To get around it, I go into properties of
> the block (double click on it in the GRC), go to the the RFNoC Config tab,
> and change the Device Select to 0 for one of them, and 1 for the other.
> There is some sort of issue (I don't recall why, but it was explained to me
> a few years back) with -1 not causing the code generation to be smart
> enough to auto-populate the values (which is the point of it).
>
>
>
> - Original Message -
> Subject: [USRP-users] Multiple instances of RFNOC block in single flow
> graph
> From: "Andrew Danowitz via USRP-users" 
> Date: 8/28/18 5:34 pm
> To: "shachar J. brown via USRP-users" 
>
> Hi all,
>
> Has anyone used multiple instances of an RFNOC block in a single flow
> graph? I Built an image with my block, mAvgFilter, twice in the build args.
> When I try to use both in a flow graph, though, I get:
>
> File "/home/root/e300/src/test_code/top_block.py", line 255, in __init__
> self.device3.connect(self.wf_delay_0.get_block_id(), 0,
> self.wf_mAvgFilter_1.get_block_id(), 0)
>   File "/home/root/e300/usr/lib/python2.7/site-packages/ettus/ettus_swig.py",
> line 1267, in connect
> return _ettus_swig.device3_sptr_connect(self, *args)
> RuntimeError: RuntimeError: On node 0/mAvgFilter_0, input port 0 is
> already connected.
>
> As you can see, the python is properly using instance _1, but somehow the
> C is defaulting to instance _0.
>
> I'm running UHD_3.13
>
> 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 
<mailto: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] Multiple instances of RFNOC block in single flow graph

[Andrew Danowitz via USRP-users]

Hi all,

Has anyone used multiple instances of an RFNOC block in a single flow
graph? I Built an image with my block, mAvgFilter, twice in the build args.
When I try to use both in a flow graph, though, I get:

File "/home/root/e300/src/test_code/top_block.py", line 255, in __init__
self.device3.connect(self.wf_delay_0.get_block_id(), 0,
self.wf_mAvgFilter_1.get_block_id(), 0)
  File
"/home/root/e300/usr/lib/python2.7/site-packages/ettus/ettus_swig.py", line
1267, in connect
return _ettus_swig.device3_sptr_connect(self, *args)
RuntimeError: RuntimeError: On node 0/mAvgFilter_0, input port 0 is already
connected.

As you can see, the python is properly using instance _1, but somehow the C
is defaulting to instance _0.

I'm running UHD_3.13

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] RFNOC blocks with multiple inputs?

[Andrew Danowitz via USRP-users]

Hi all,

I'm trying to create an rfnoc divide block. I have the RTL and testbench
set up and working, but every time I try to put it in a grc flow, I get:

RuntimeError: Invalid stream args.

I'm assuming this has to do with the grc xml file for my block. Is there
any documentation on how to make an rfnoc block with multiple inputs or
outputs? For the make args, should I use the same ettus.rfnoc_generic call
that the built-in addsub block uses?

-- 

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] ValueError: recv_buff_size must be larger than the recv_frame_size.

[Andrew Danowitz via USRP-users]

Update, I get this error even if I don't use any rfnoc components, and just
use a standard UHD source going into the qt gui time sink.

Thanks,
Andrew

On Wed, Aug 22, 2018 at 11:12 AM, Andrew Danowitz <
and...@whitefoxdefense.com> wrote:

> Hi,
>
> I rebuilt everything using the latest recipes for rfnoc and e3xx-rfnoc.
> Now when I try to run any rfnoc flow-chart on the e310, I get the following
> error:
>
> ValueError: recv_buff_size must be larger than the recv_frame_size.
>
> Even if I just take an rfnoc: radio block and connect it directly to a qt
> time sink, I get:
>
> Initializing block control (NOC ID: 0x5B888C918ACDF7F3)
> thread[thread-per-block[0]: ]: ValueError:
> recv_buff_size must be larger than the recv_frame_size.
>
> Has anyone run into this before? Where are these buffer and frame sizes
> set?
>
> 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] ValueError: recv_buff_size must be larger than the recv_frame_size.

[Andrew Danowitz via USRP-users]

Hi,

I rebuilt everything using the latest recipes for rfnoc and e3xx-rfnoc. Now
when I try to run any rfnoc flow-chart on the e310, I get the following
error:

ValueError: recv_buff_size must be larger than the recv_frame_size.

Even if I just take an rfnoc: radio block and connect it directly to a qt
time sink, I get:

Initializing block control (NOC ID: 0x5B888C918ACDF7F3)
thread[thread-per-block[0]: ]: ValueError:
recv_buff_size must be larger than the recv_frame_size.

Has anyone run into this before? Where are these buffer and frame sizes set?

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] Creating New GR Blocks for E310

[Andrew Danowitz via USRP-users]

When you source environment-setup-armv7ahf-vfp-neon-oe-linux-gnueabi it
points python to the e310/ARM version of Python that comes to the SDK.
Since gr_modtool needs to run on your host system to set up a new OOT
module, the ARM version of python won't work for you. Your best bet is to
open a new terminal, source your e310/setup_env.sh, and then develop your
OOT module as needed. Only source
environment-setup-armv7ahf-vfp-neon-oe-linux-gnueabi
at the end when it's time to build and install your OOT module into your
cross-compile build. Another alternative, do development and testing of
your OOT module on a pybomb prefix set up for x86 gnuradio and just
copy-paste-make-install the directory to your cross-compile prefix at the
end.

On Wed, Aug 22, 2018 at 1:53 AM, shachar J. brown via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi everyone,
>
> I'm having trouble creating a new gr block for my e310.
>
> I compiled uhd and gnuradio from source as instructed in the following
> page:
> https://kb.ettus.com/Software_Development_on_the_E310_and_E312
>
> Now, when I try using the "gr_modtool newmod" command on my development
> device (pc), I receive the following error:
>
>
> user@user-OptiPlex-7040:~/prefix/src$ gr_modtool newmod DF_project
> Traceback (most recent call last):
>   File 
> "/home/user/prefix/sysroots/x86_64-oesdk-linux/usr/lib/python2.7/site.py",
> line 553, in 
> main()
>   File 
> "/home/user/prefix/sysroots/x86_64-oesdk-linux/usr/lib/python2.7/site.py",
> line 535, in main
> known_paths = addusersitepackages(known_paths)
>   File 
> "/home/user/prefix/sysroots/x86_64-oesdk-linux/usr/lib/python2.7/site.py",
> line 266, in addusersitepackages
> user_site = getusersitepackages()
>   File 
> "/home/user/prefix/sysroots/x86_64-oesdk-linux/usr/lib/python2.7/site.py",
> line 241, in getusersitepackages
> user_base = getuserbase() # this will also set USER_BASE
>   File 
> "/home/user/prefix/sysroots/x86_64-oesdk-linux/usr/lib/python2.7/site.py",
> line 230, in getuserbase
> from sysconfig import get_config_var
>   File 
> "/home/user/prefix/sysroots/x86_64-oesdk-linux/usr/lib/python2.7/sysconfig.py",
> line 10, in 
> 'stdlib': '{base}/'+sys.lib+'/python{py_version_short}',
> AttributeError: 'module' object has no attribute 'lib'
>
>
> Note: I've set up the environment using the  
> "environment-setup-armv7ahf-vfp-neon-oe-linux-gnueabi"
> in the prefix directory, as I've done while compiling uhd and gnuradio.
>
> Note2: The sdk is seemingly not well supported, and I had to install six
> (a VOLK dependency) manually to complete the gnuradio compilation.
>
> Thanks for your time,
> Steve
>
>
>
>
> ___
> 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] noc_shell wrapper compatibility in UHD rfnoc-devel branch

[Andrew Danowitz via USRP-users]

Hi,

I generated an rfnoc fpga image using the latest UHD-fpga tools on the
rfnoc-devel branch. When I go to run it with the latest UHD on the
rfnoc-devel branch, I get RuntimeError: RuntimeError: FPGA component
`noc_shell' is revision 4 and UHD supports revision 2. Please either
upgrade UHD  (recommended) or downgrade the FPGA image.

Looking through the source on github it seems that the UHD master branch
supports up to revision 4, but the rfnoc-devel branch only supports up to
version 2. Is there any reason for this?

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] Custom OOT RFNOC modules no longer simulating or running on E310 after upgrade to latest UHD

[Andrew Danowitz via USRP-users]

I recently upgraded to the newest versions of the development tools (fresh
pybombs installs of recipes rfnoc-e3xx for cross-compiling, and rfnoc for
local test and development). Since that time, all of my previously
functioning custom RFNOC blocks now hang in simulation on Vivado (they hang
at the tb_streamer.recv(recv_payload,md); command), and when used in
grc-programs run directly on the e310 they result in limitless "timeout on
chan 0" errors, and the radio no longer seems to send or receive.

I've tried re-implementing one of my blocks using the latest rfnocmodtool
to ensure that all of the nocblock auto-generated collateral is up-to-date,
but still see the same results.

Anyone else experiencing this error?

-- 

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