date:20180904

Re: [USRP-users] x310 simulating RFNoC block with Xilinx IP

2018-09-04 Thread Dang tien Vo-Huu via USRP-users

Hi Martin,
I was able to run the simulation when I modified setupenv_base.sh to
replace the default path to Vivado with my custom path ( I think it should
be the same as --vivado-path= ) and also "source
uhd-fpga/usrp3/top/x300/setupenv.sh".
Thank you.

Best,
Tien

On Tue, Sep 4, 2018 at 5:33 PM Martin Braun via USRP-users <
usrp-users@lists.ettus.com> wrote:

> On Fri, Feb 09, 2018 at 12:44:26PM -0500, Dang tien Vo-Huu wrote:
> >Hi Martin,
> >I am on branch rfnoc-devel at version
> >b0890fa97ef3dc7d90ed8047d678ca280c72ad61, and I am using Vivado 2015.4
> >-
> >tienvh@gl502vm:~/workspace/rfnoc/src/uhd-fpga$ git branchÂ
> >* rfnoc-devel
> >tienvh@gl502vm:~/workspace/rfnoc/src/uhd-fpga$ git log
> >commit b0890fa97ef3dc7d90ed8047d678ca280c72ad61
> >Author: Nicolas Cuervo 
> >Date:Â  Â Tue Sep 19 20:03:43 2017 +0200
> >Â  Â  image_builder_gui: fix include_dir argument
> >-
> >I am able to run 'make xsim' now when 'source setupenv.sh' as
> suggested in
> >the error.
> >I think the issue is because I have Vivado installed in other place
> than
> >/opt/Xilinx/. Although I have modified
> >uhd-fpga/usrp3/tools/scripts/setupenv_base.sh for path to VIvado,
> 'make
> >xsim' doesn't seem to touch it when running.
>
> Did you try running setup_env.sh --vivado-path=?
>
> -- M
> >Tien
> >On Fri, Feb 9, 2018 at 11:05 AM, Martin Braun via USRP-users
> > wrote:
> >
> >  On 01/30/2018 08:08 AM, Dang tien Vo-Huu via USRP-users wrote:
> >  > Hi Jonathon,
> >  > Thank you for the hint. Actually your suggestion was the first
> thing I
> >  > tried but it didn't work. It threw the error:
> >  >
> >  >
> >  tienvh@gl502vm
> :~/workspace/rfnoc/src/uhd-fpga/usrp3/lib/rfnoc/noc_block_fft_tb$
> >  > make xsim
> >  > BUILDER: Checking tools...
> >  > * GNU bash, version 4.3.48(1)-release (x86_64-pc-linux-gnu)
> >  > * Python 2.7.12
> >  > * ERROR: Vivado not found in environment. Please run setupenv.sh
> >  >
> >
> /home/tienvh/workspace/rfnoc/src/uhd-fpga/usrp3/top/../tools/make/viv_preamble.mak:47:
> >  > recipe for target '.check_tool' failed
> >  > make: *** [.check_tool] Error 1
> >
> >  Which branch are you on, and which version of Vivado do you have
> >  installed?
> >  -- M
> >  ___
> >  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] N310 timeouts on Rx... Which UHD version will make my N310 work?

2018-09-04 Thread Max Scharrenbroich via USRP-users

Thanks for the feedback.  I tried 3.13.0.2 this afternoon but still the same Rx 
timeout issues.

I’ll take a look at allocating more memory for the ethernet drivers.  But the 
wireshark results still puzzle me.  I’m getting timeouts even on low bandwidth 
collects (just as a test case of course).

It seems like the FPGA is not sending all the packets to the 10Gbit IP or the 
IP is losing a packet somewhere.  I took a look through the FPGA code but 
nothing jumped out – it all looked like it should work.  Maybe there’s a race 
condition between some of the blocks?

Unfortunately a lot of code has changed and been refactored since 3.10 so it’s 
hard to see where things went wrong.  The number of releases in the last four 
months is more than what has been released in the last three years…

From: Ali Dormiani 
Sent: Tuesday, September 4, 2018 10:17 PM
To: Max Scharrenbroich 
Cc: usrp-users@lists.ettus.com; rkoss...@nd.edu
Subject: Re: [USRP-users] N310 timeouts on Rx... Which UHD version will make my 
N310 work?

Here is my Lab's N310 experiance:

3.12 had your issue (2)

3.13.0.0 had bizarre TX behavior and lock ups that required a reboot or 
re-image. Our RX noise floor was also suspiciously high.

3.13.0.1 was no better

3.13.0.2 fixed all our problems. As long as we tell linux to allocate plenty of 
ram to the Ethernet driver we can transmit and receive with two channels 
simultaneously. I have not had the chance yet to test 4 TX to 4 RX yet.

Over the past several months I have come to the conclusion that getting UHD or 
GNUradio from a package manager is more trouble than it is worth.

If you compile UHD 3.13.0.2 from source and still have these RX timeout 
problems then I suppose this issue is out of reach for non-Ettus folks.



On Tue, Sep 4, 2018 at 6:45 PM, Max Scharrenbroich via USRP-users 
mailto:usrp-users@lists.ettus.com>> wrote:
This message is a continuation of the thread that Rob Kossler last added to 
regarding the timeouts on Rx for the N310 when using version 3.13 of the UHD. 
Note that we have not tested our X310s with this version - version 3.10 of the 
UHD works well with our system of X310s and we don’t see a need in changing.

We found the same Rx timeout issues that Rob did while testing custom 
executables that have been robust using UHD version 3.10 for well over a year.  
We noticed that the problem occurs when receiving samples from multiple 
channels – a single channel seems to work as expected.  As Rob pointed out the 
error can be easily replicated with the stock UHD examples. In our case we saw 
the errors when running rx_multi_samples with more than one channel.

To dig into the underlying cause we installed WireShark and captured packets 
from the SDR<->host interface.  Based on the collects it appears that there is 
always exactly one data packet missing.  Setting the number of receive samples 
to something small (less than or equal to a packet size) results in N-1 packets 
being received on the interface, where N is the number of Rx channels specified.

In an effort to work around the problem we tried hacking at 
super_recv_packet_handler.hpp to tell the SDR to send more packets than we 
actually want and ignore the timeout condition.  This seems to work when 
receiving the first burst of  samples (STREAM_MODE_NUM_SAMPS_AND_DONE) but 
subsequent issuing of stream commands turns the rx_stream into a train wreck.

The ultimate problem we are having is that we cannot get our N310 to work with 
any of the versions of the UHD.

Here are the issues:

(1) Version 3.11 has an sdcard image that is corrupted and won’t allow our N310 
to boot.

(2) Version  3.12 does not accept the PID for the AD9371s

(3) Version 3.13 has the Rx timeout issue.

Questions:

Can someone please recommend an exact version number that will allow us to use 
our N310 as we should expect it to?

Or

If the Rx timeout is a known issue can someone point us to a bug fix that we 
can implement locally?

Thanks,

Max Scharrenbroich
Senior Principal Scientist
SAZE Technologies, LLC




___
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] N310 timeouts on Rx... Which UHD version will make my N310 work?

2018-09-04 Thread Ali Dormiani via USRP-users

Here is my Lab's N310 experiance:

3.12 had your issue (2)

3.13.0.0 had bizarre TX behavior and lock ups that required a reboot or
re-image. Our RX noise floor was also suspiciously high.

3.13.0.1 was no better

3.13.0.2 fixed all our problems. As long as we tell linux to allocate
plenty of ram to the Ethernet driver we can transmit and receive with two
channels simultaneously. I have not had the chance yet to test 4 TX to 4 RX
yet.

Over the past several months I have come to the conclusion that getting UHD
or GNUradio from a package manager is more trouble than it is worth.

If you compile UHD 3.13.0.2 from source and still have these RX timeout
problems then I suppose this issue is out of reach for non-Ettus folks.



On Tue, Sep 4, 2018 at 6:45 PM, Max Scharrenbroich via USRP-users <
usrp-users@lists.ettus.com> wrote:

> This message is a continuation of the thread that Rob Kossler last added
> to regarding the timeouts on Rx for the N310 when using version 3.13 of the
> UHD. Note that we have not tested our X310s with this version - version
> 3.10 of the UHD works well with our system of X310s and we don’t see a need
> in changing.
>
>
>
> We found the same Rx timeout issues that Rob did while testing custom
> executables that have been robust using UHD version 3.10 for well over a
> year.  We noticed that the problem occurs when receiving samples from
> multiple channels – a single channel seems to work as expected.  As Rob
> pointed out the error can be easily replicated with the stock UHD examples.
> In our case we saw the errors when running rx_multi_samples with more than
> one channel.
>
>
>
> To dig into the underlying cause we installed WireShark and captured
> packets from the SDR<->host interface.  Based on the collects it appears
> that there is always exactly one data packet missing.  Setting the number
> of receive samples to something small (less than or equal to a packet size)
> results in N-1 packets being received on the interface, where N is the
> number of Rx channels specified.
>
>
>
> In an effort to work around the problem we tried hacking at
> super_recv_packet_handler.hpp to tell the SDR to send more packets than we
> actually want and ignore the timeout condition.  This seems to work when
> receiving the first burst of  samples (STREAM_MODE_NUM_SAMPS_AND_DONE)
> but subsequent issuing of stream commands turns the rx_stream into a train
> wreck.
>
>
>
> The ultimate problem we are having is that we cannot get our N310 to work
> with any of the versions of the UHD.
>
>
>
> Here are the issues:
>
>
>
> (1) Version 3.11 has an sdcard image that is corrupted and won’t allow our
> N310 to boot.
>
>
>
> (2) Version  3.12 does not accept the PID for the AD9371s
>
>
>
> (3) Version 3.13 has the Rx timeout issue.
>
>
>
> Questions:
>
>
>
> Can someone please recommend an exact version number that will allow us to
> use our N310 as we should expect it to?
>
>
>
> Or
>
>
>
> If the Rx timeout is a known issue can someone point us to a bug fix that
> we can implement locally?
>
>
>
> Thanks,
>
>
>
> Max Scharrenbroich
>
> Senior Principal Scientist
>
> SAZE Technologies, LLC
>
>
>
>
>
>
>
> ___
> 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] N310 timeouts on Rx... Which UHD version will make my N310 work?

2018-09-04 Thread Max Scharrenbroich via USRP-users

This message is a continuation of the thread that Rob Kossler last added to 
regarding the timeouts on Rx for the N310 when using version 3.13 of the UHD. 
Note that we have not tested our X310s with this version - version 3.10 of the 
UHD works well with our system of X310s and we don't see a need in changing.

We found the same Rx timeout issues that Rob did while testing custom 
executables that have been robust using UHD version 3.10 for well over a year.  
We noticed that the problem occurs when receiving samples from multiple 
channels - a single channel seems to work as expected.  As Rob pointed out the 
error can be easily replicated with the stock UHD examples. In our case we saw 
the errors when running rx_multi_samples with more than one channel.

To dig into the underlying cause we installed WireShark and captured packets 
from the SDR<->host interface.  Based on the collects it appears that there is 
always exactly one data packet missing.  Setting the number of receive samples 
to something small (less than or equal to a packet size) results in N-1 packets 
being received on the interface, where N is the number of Rx channels specified.

In an effort to work around the problem we tried hacking at 
super_recv_packet_handler.hpp to tell the SDR to send more packets than we 
actually want and ignore the timeout condition.  This seems to work when 
receiving the first burst of  samples (STREAM_MODE_NUM_SAMPS_AND_DONE) but 
subsequent issuing of stream commands turns the rx_stream into a train wreck.

The ultimate problem we are having is that we cannot get our N310 to work with 
any of the versions of the UHD.

Here are the issues:

(1) Version 3.11 has an sdcard image that is corrupted and won't allow our N310 
to boot.

(2) Version  3.12 does not accept the PID for the AD9371s

(3) Version 3.13 has the Rx timeout issue.

Questions:

Can someone please recommend an exact version number that will allow us to use 
our N310 as we should expect it to?

Or

If the Rx timeout is a known issue can someone point us to a bug fix that we 
can implement locally?

Thanks,

Max Scharrenbroich
Senior Principal Scientist
SAZE Technologies, LLC



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

Re: [USRP-users] FPGA Repository and Stability

2018-09-04 Thread Ashish Chaudhari via USRP-users

On Tue, Sep 4, 2018 at 4:51 PM, Brian Padalino  wrote:
> On Tue, Sep 4, 2018 at 6:55 PM Ashish Chaudhari 
> wrote:
>>
>> On Tue, Sep 4, 2018 at 8:07 AM, Brian Padalino via USRP-users
>>  wrote:
>> > Recently there was a significant change to the noc_block_vector_iir
>> > (specifically the vector_iir):
>> >
>> >
>> >
>> > https://github.com/EttusResearch/fpga/commit/05ca30fe91330d54dcd005a3af4aeaa0dc26c8f8#diff-4b21f52231ba9f82bf132f633d594187
>> >
>> > It's a pretty significant re-write of the block, and this behavior has
>> > me
>> > asking a few questions:
>> >
>> > 1) Can anyone at Ettus expand on the reason for the major re-write?  It
>> > appears that the block itself worked previously so it seems like
>> > re-writing
>> > it was a lot of effort to potentially add new bugs to things which
>> > weren't
>> > there previously.
>> >
>>
>> There were several reasons that contributed to the re-writing that
>> block. First off, there was a bug in the delay line implementation
>> that needed to be fixed. Secondly, we wanted to improve the
>> readability and resource utilization of blocks where users hand-write
>> their DSP (as opposed to using third-party AXI-Stream IP). The old
>> approach was to implement a DSP algorithm using basic operations like
>> addition, multiplication, rounding, etc each with AXI-Stream
>> handshaking. This has the following drawbacks: 1) The code is a bit
>> hard to read because the AXI-Stream stuff takes up code real-estate 2)
>> It's hard to let the tools infer DSP primitives automatically because
>> AXI-Stream can get in the way of the standard Xilinx-intended control
>> sets. 3) The AXI-Stream logic takes up more fabric resources. The
>> Vector IIR block is the first block that wraps AXI-Stream around the
>> entire DSP algorithm instead of around basic functions. This is the
>> way we intend to write future blocks with hand-implemented DSP. The
>> change is actually a step forward in terms of stability because the
>> API to the actual DSP kernel is much simpler and intuitive, and is
>> much closer to how FPGA DSP implementation is taught. The simpler API
>> also makes it easy for the Xilinx tools to perform
>> optimization/mapping because AXI-Stream handshaking is not in the way.
>> Don't get me wrong, AXI-Stream is great, we are just changing the
>> granularity at which we implement it.
>
>
> Why start with this block instead of just blocks going forward?  I saw the
> addition of the biquad - great!  But, ideally, you'd fix the bug in the
> delay line and move on if that's what drove people looking into the behavior
> to begin with?
>
> I prefer less AXI streaming interfaces as well, but it just seems like a
> poor idea to rewrite an already written block and change something out from
> underneath everyone.
>
>>
>> > 2) Why wasn't this re-written block added as a second option for a
>> > vectored
>> > IIR implementation?  There are 64-bits worth of RFNoC block ID's out
>> > there.
>> > I understand if you don't want to support specific RFNoC blocks anymore,
>> > and
>> > want to move onto new ones, but can you retire them in a better, more
>> > thought out way?  Moving them to a deprecated folder is fine and giving
>> > one
>> > or two releases to get people to move away is fine, but please stop
>> > gutting
>> > and re-writing something like it hasn't completely changed.  There are
>> > people who may want to stick with the old way of doing things (the old
>> > DDC/DUCs are another recent re-write that could have been handled
>> > better).
>> > Please give us a chance at trying to maintain stability.
>> >
>>
>> Other than fixing the delay line issue, we did not change the behavior
>> of the block. We also did not change the software or FPGA interface to
>> the block. All that changed was the implementation, and that does not
>> warrant a new block or a deprecated copy. You can argue that if
>> something/anything changes in a piece of functional code, that it is
>> inherently unstable. However, that applies to everything from a one
>> liner bugfix to complete rewrite. That said, if you noticed a bug in
>> the code, then we will absolutely need to and will fix it.
>>
>> In general, RFNoC is still evolving and we are slowly cleaning up
>> interfaces to reach a point where we are confident that it is easy to
>> use and it efficiently supports what our customers want to do. We
>> always try to balance improvements with backwards compatibility, but
>> there are cases where we cannot guarantee compatibility. In those
>> cases we will try to minimize the incompatible changes, and increment
>> the compatibility number to ensure that changes don't go unnoticed to
>> software. None of that was true for this particular block change.
>
>
> No offense, but you're wrong in many ways.  From an implementation
> standpoint, your re-write isn't a drop-in replacement.  It requires code
> changes for anyone utilizing the vector_iir module.  On top of that, if bugs
> were found in new implementati

Re: [USRP-users] FPGA Repository and Stability

2018-09-04 Thread Brian Padalino via USRP-users

On Tue, Sep 4, 2018 at 6:55 PM Ashish Chaudhari 
wrote:

> On Tue, Sep 4, 2018 at 8:07 AM, Brian Padalino via USRP-users
>  wrote:
> > Recently there was a significant change to the noc_block_vector_iir
> > (specifically the vector_iir):
> >
> >
> >
> https://github.com/EttusResearch/fpga/commit/05ca30fe91330d54dcd005a3af4aeaa0dc26c8f8#diff-4b21f52231ba9f82bf132f633d594187
> >
> > It's a pretty significant re-write of the block, and this behavior has me
> > asking a few questions:
> >
> > 1) Can anyone at Ettus expand on the reason for the major re-write?  It
> > appears that the block itself worked previously so it seems like
> re-writing
> > it was a lot of effort to potentially add new bugs to things which
> weren't
> > there previously.
> >
>
> There were several reasons that contributed to the re-writing that
> block. First off, there was a bug in the delay line implementation
> that needed to be fixed. Secondly, we wanted to improve the
> readability and resource utilization of blocks where users hand-write
> their DSP (as opposed to using third-party AXI-Stream IP). The old
> approach was to implement a DSP algorithm using basic operations like
> addition, multiplication, rounding, etc each with AXI-Stream
> handshaking. This has the following drawbacks: 1) The code is a bit
> hard to read because the AXI-Stream stuff takes up code real-estate 2)
> It's hard to let the tools infer DSP primitives automatically because
> AXI-Stream can get in the way of the standard Xilinx-intended control
> sets. 3) The AXI-Stream logic takes up more fabric resources. The
> Vector IIR block is the first block that wraps AXI-Stream around the
> entire DSP algorithm instead of around basic functions. This is the
> way we intend to write future blocks with hand-implemented DSP. The
> change is actually a step forward in terms of stability because the
> API to the actual DSP kernel is much simpler and intuitive, and is
> much closer to how FPGA DSP implementation is taught. The simpler API
> also makes it easy for the Xilinx tools to perform
> optimization/mapping because AXI-Stream handshaking is not in the way.
> Don't get me wrong, AXI-Stream is great, we are just changing the
> granularity at which we implement it.
>

Why start with this block instead of just blocks going forward?  I saw the
addition of the biquad - great!  But, ideally, you'd fix the bug in the
delay line and move on if that's what drove people looking into the
behavior to begin with?

I prefer less AXI streaming interfaces as well, but it just seems like a
poor idea to rewrite an already written block and change something out from
underneath everyone.


> > 2) Why wasn't this re-written block added as a second option for a
> vectored
> > IIR implementation?  There are 64-bits worth of RFNoC block ID's out
> there.
> > I understand if you don't want to support specific RFNoC blocks anymore,
> and
> > want to move onto new ones, but can you retire them in a better, more
> > thought out way?  Moving them to a deprecated folder is fine and giving
> one
> > or two releases to get people to move away is fine, but please stop
> gutting
> > and re-writing something like it hasn't completely changed.  There are
> > people who may want to stick with the old way of doing things (the old
> > DDC/DUCs are another recent re-write that could have been handled
> better).
> > Please give us a chance at trying to maintain stability.
> >
>
> Other than fixing the delay line issue, we did not change the behavior
> of the block. We also did not change the software or FPGA interface to
> the block. All that changed was the implementation, and that does not
> warrant a new block or a deprecated copy. You can argue that if
> something/anything changes in a piece of functional code, that it is
> inherently unstable. However, that applies to everything from a one
> liner bugfix to complete rewrite. That said, if you noticed a bug in
> the code, then we will absolutely need to and will fix it.
>
> In general, RFNoC is still evolving and we are slowly cleaning up
> interfaces to reach a point where we are confident that it is easy to
> use and it efficiently supports what our customers want to do. We
> always try to balance improvements with backwards compatibility, but
> there are cases where we cannot guarantee compatibility. In those
> cases we will try to minimize the incompatible changes, and increment
> the compatibility number to ensure that changes don't go unnoticed to
> software. None of that was true for this particular block change.
>

No offense, but you're wrong in many ways.  From an implementation
standpoint, your re-write isn't a drop-in replacement.  It requires code
changes for anyone utilizing the vector_iir module.  On top of that, if
bugs were found in new implementations, but not in old ones, it's not easy
to roll back the changes.

Take the DDC/DUC changes for example.  I understand why they were done.  I
understand they are more efficient.  If I wante

Re: [USRP-users] FPGA Repository and Stability

2018-09-04 Thread Ashish Chaudhari via USRP-users

On Tue, Sep 4, 2018 at 8:07 AM, Brian Padalino via USRP-users
 wrote:
> Recently there was a significant change to the noc_block_vector_iir
> (specifically the vector_iir):
>
>
> https://github.com/EttusResearch/fpga/commit/05ca30fe91330d54dcd005a3af4aeaa0dc26c8f8#diff-4b21f52231ba9f82bf132f633d594187
>
> It's a pretty significant re-write of the block, and this behavior has me
> asking a few questions:
>
> 1) Can anyone at Ettus expand on the reason for the major re-write?  It
> appears that the block itself worked previously so it seems like re-writing
> it was a lot of effort to potentially add new bugs to things which weren't
> there previously.
>

There were several reasons that contributed to the re-writing that
block. First off, there was a bug in the delay line implementation
that needed to be fixed. Secondly, we wanted to improve the
readability and resource utilization of blocks where users hand-write
their DSP (as opposed to using third-party AXI-Stream IP). The old
approach was to implement a DSP algorithm using basic operations like
addition, multiplication, rounding, etc each with AXI-Stream
handshaking. This has the following drawbacks: 1) The code is a bit
hard to read because the AXI-Stream stuff takes up code real-estate 2)
It's hard to let the tools infer DSP primitives automatically because
AXI-Stream can get in the way of the standard Xilinx-intended control
sets. 3) The AXI-Stream logic takes up more fabric resources. The
Vector IIR block is the first block that wraps AXI-Stream around the
entire DSP algorithm instead of around basic functions. This is the
way we intend to write future blocks with hand-implemented DSP. The
change is actually a step forward in terms of stability because the
API to the actual DSP kernel is much simpler and intuitive, and is
much closer to how FPGA DSP implementation is taught. The simpler API
also makes it easy for the Xilinx tools to perform
optimization/mapping because AXI-Stream handshaking is not in the way.
Don't get me wrong, AXI-Stream is great, we are just changing the
granularity at which we implement it.

> 2) Why wasn't this re-written block added as a second option for a vectored
> IIR implementation?  There are 64-bits worth of RFNoC block ID's out there.
> I understand if you don't want to support specific RFNoC blocks anymore, and
> want to move onto new ones, but can you retire them in a better, more
> thought out way?  Moving them to a deprecated folder is fine and giving one
> or two releases to get people to move away is fine, but please stop gutting
> and re-writing something like it hasn't completely changed.  There are
> people who may want to stick with the old way of doing things (the old
> DDC/DUCs are another recent re-write that could have been handled better).
> Please give us a chance at trying to maintain stability.
>

Other than fixing the delay line issue, we did not change the behavior
of the block. We also did not change the software or FPGA interface to
the block. All that changed was the implementation, and that does not
warrant a new block or a deprecated copy. You can argue that if
something/anything changes in a piece of functional code, that it is
inherently unstable. However, that applies to everything from a one
liner bugfix to complete rewrite. That said, if you noticed a bug in
the code, then we will absolutely need to and will fix it.

In general, RFNoC is still evolving and we are slowly cleaning up
interfaces to reach a point where we are confident that it is easy to
use and it efficiently supports what our customers want to do. We
always try to balance improvements with backwards compatibility, but
there are cases where we cannot guarantee compatibility. In those
cases we will try to minimize the incompatible changes, and increment
the compatibility number to ensure that changes don't go unnoticed to
software. None of that was true for this particular block change.

> I've tried to emphasize stability previously, and it seems like the host
> side tries, almost to a fault, to maintain ABI compatibility and stability,
> but the FPGA side seems to have a complete disregard for stability.
>
> It would be really nice if someone from Ettus could answer the two questions
> I posed.
>
> Thanks,
> Brian
>
> ___
> 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] N310 timeout before streaming complete

2018-09-04 Thread Rob Kossler via USRP-users

Today, I confirmed that this issue exists on the head of 3.13 and 3.12, but
not 3.11.  The example program provided with my previous post can be
compiled with any of these versions.

Rob

On Fri, Aug 31, 2018 at 12:33 PM Rob Kossler  wrote:

> In this post and one other post, I mentioned two issues I am having
> related to N310 streaming:
>
>1. With STREAM_MODE_NUM_SAMPS_AND_DONE, sometimes I get a timeout
>prior to receiving the requested number of samples (this is the issue
>identified in this post). This may be simply dependent upon the number of
>samples requested.
>2. With STREAM_MODE_START_CONTINUOUS, I get errors with repeated
>captures such that after several successful captures, I eventually get a
>streaming timeout and all subsequent captures fail.
>
> So, turns out that this issue is bigger for me than I realized.  I had a
> bunch of trouble yesterday while doing some research experimentation. I had
> selected to go with X310 devices rather than N310 devices because of their
> relative maturity.  Today, I confirmed that my issues yesterday with the
> X310 are the same as I previously mentioned for the N310 (#2 above).  So,
> perhaps it is an issue with UHD-3.13 (I did not check any other branch).
>
> I modified the Ettus "txrx_loopback_to_file.cpp" code to include a "for
> loop of 50 iterations" and changed the streaming mode to be continuous.
> The modified source is included as an attachment (a 'diff' of my code to
> the original with show the minor changes I made).  I attached a console log
> of the output messages when run with my X310 which shows both the command
> line parameters I used as well as the resulting errors.  Note that
> everything is going as expected through Iteration 5, but starting at
> Iteration 6, there is no end-of-burst (EOB) and starting at Iteration 8, a
> timeout occurs prior to receiving any samples.
>
> Please let me know if you have any questions.  This is a pretty big issue
> for me and will prevent me from using 3.13 until addressed.
>
> Rob
>
>
> On Fri, Aug 24, 2018 at 2:46 PM Rob Kossler  wrote:
>
>> Hi,
>> This post is perhaps a continuation of a previous post "Problems with MPM
>> 3.13 on N310", but I wanted to change the subject to reflect this current
>> issue.
>>
>> The issue is an Rx streaming timeout.  It can be easily duplicated with a
>> stock Ettus example.  Below you will find the console log which includes
>> the command line parameters.  Note the following:
>>
>>- I requested 31250 samples
>>- There is a error "Timeout while streaming" indicated at the end
>>- The final file size of 119340 indicates that 29835 samples were
>>received
>>- I do not have any reason to believe that the specific command line
>>arguments below are needed to duplicate the issue.  I just didn't bother 
>> to
>>try other ones.
>>
>> In the other thread, I mentioned that my Rx timeout issue had gone away
>> after switching to streaming mode STREAM_MODE_NUM_SAMPS_AND_DONE.  However,
>> the issue below occurs when using that mode so it will be a problem for me.
>>
>> Let me know if you have any questions.
>>
>> Rob
>>
>>
>> irisheyes9@irisheyes9-Z240-SFF:/media/SSD_RAID/multi_pol$
>> txrx_loopback_to_file --tx-args="addr=192.168.61.2"
>> --rx-args="addr=192.168.61.2" --nsamps=31250 --tx-rate=31.25e6
>> --rx-rate=31.25e6 --tx-channels=0,1 --rx-channels=2,3 --tx-freq=2500e6
>> --rx-freq=2500e6
>>
>> Creating the transmit usrp device with: addr=192.168.61.2...
>> [INFO] [UHD] linux; GNU C++ version 5.4.0 20160609; Boost_105800;
>> UHD_3.13.0.2-0-g0ddc19e5
>> [INFO] [MPMD] Initializing 1 device(s) in parallel with args:
>> mgmt_addr=192.168.61.2,type=n3xx,product=n310,serial=315A34B,claimed=False,addr=192.168.61.2
>> [INFO] [MPM.PeriphManager] init() called with device args
>> `mgmt_addr=192.168.61.2,product=n310'.
>> [INFO] [0/DmaFIFO_0] Initializing block control (NOC ID:
>> 0xF1F0D004)
>> [INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1320 MB/s)
>> [INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1336 MB/s)
>> [INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1331 MB/s)
>> [INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1349 MB/s)
>> [INFO] [0/Radio_0] Initializing block control (NOC ID: 0x12AD10011312)
>> [INFO] [0/Radio_1] Initializing block control (NOC ID: 0x12AD10011312)
>> [INFO] [0/DDC_0] Initializing block control (NOC ID: 0xDDC0)
>> [INFO] [0/DDC_1] Initializing block control (NOC ID: 0xDDC0)
>> [INFO] [0/DUC_0] Initializing block control (NOC ID: 0xD0C2)
>> [INFO] [0/DUC_1] Initializing block control (NOC ID: 0xD0C2)
>>
>> Creating the receive usrp device with: addr=192.168.61.2...
>> Using TX Device: Single USRP:
>>   Device: N300-Series Device
>>   Mboard 0: ni-n3xx-315A34B
>>   RX Channel: 0
>> RX DSP: 0
>> RX Dboard: A
>> RX Subdev: Magnesium
>>   RX Channel: 1
>> RX DSP: 1
>> RX Dboard: A
>> RX Subdev: Magnesium
>>   RX Channel: 2

Re: [USRP-users] x310 simulating RFNoC block with Xilinx IP

2018-09-04 Thread Martin Braun via USRP-users

On Fri, Feb 09, 2018 at 12:44:26PM -0500, Dang tien Vo-Huu wrote:
>Hi Martin,
>I am on branch rfnoc-devel at version
>b0890fa97ef3dc7d90ed8047d678ca280c72ad61, and I am using Vivado 2015.4
>-
>tienvh@gl502vm:~/workspace/rfnoc/src/uhd-fpga$ git branchÂ 
>* rfnoc-devel
>tienvh@gl502vm:~/workspace/rfnoc/src/uhd-fpga$ git log
>commit b0890fa97ef3dc7d90ed8047d678ca280c72ad61
>Author: Nicolas Cuervo 
>Date:Â  Â Tue Sep 19 20:03:43 2017 +0200
>Â  Â  image_builder_gui: fix include_dir argument
>-
>I am able to run 'make xsim' now when 'source setupenv.sh' as suggested in
>the error.
>I think the issue is because I have Vivado installed in other place than
>/opt/Xilinx/. Although I have modified
>uhd-fpga/usrp3/tools/scripts/setupenv_base.sh for path to VIvado, 'make
>xsim' doesn't seem to touch it when running.

Did you try running setup_env.sh --vivado-path=?

-- M
>Tien
>On Fri, Feb 9, 2018 at 11:05 AM, Martin Braun via USRP-users
> wrote:
> 
>  On 01/30/2018 08:08 AM, Dang tien Vo-Huu via USRP-users wrote:
>  > Hi Jonathon,
>  > Thank you for the hint. Actually your suggestion was the first thing I
>  > tried but it didn't work. It threw the error:
>  >
>  >
>  
> tienvh@gl502vm:~/workspace/rfnoc/src/uhd-fpga/usrp3/lib/rfnoc/noc_block_fft_tb$
>  > make xsim
>  > BUILDER: Checking tools...
>  > * GNU bash, version 4.3.48(1)-release (x86_64-pc-linux-gnu)
>  > * Python 2.7.12
>  > * ERROR: Vivado not found in environment. Please run setupenv.sh
>  >
>  
> /home/tienvh/workspace/rfnoc/src/uhd-fpga/usrp3/top/../tools/make/viv_preamble.mak:47:
>  > recipe for target '.check_tool' failed
>  > make: *** [.check_tool] Error 1
> 
>  Which branch are you on, and which version of Vivado do you have
>  installed?
>  -- M
>  ___
>  USRP-users mailing list
>  USRP-users@lists.ettus.com
>  http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com


signature.asc
Description: PGP signature
___
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 UHD library

2018-09-04 Thread Martin Braun via USRP-users

On Fri, Aug 17, 2018 at 01:02:28PM -0400, Daryl Lee via USRP-users wrote:
> In November of 2016, I cross-compiled UHD (git-cloned) on my Ubuntu 16.04
> development host targeting a Zynq chip with Linux built with Petalinux
> 2016.3.  Life has passed me by and now I need to re-build the library using
> the Petalinux 2017.3 toolchain.  I have only a few weeks to a major
> milestone, with no time to adapt to all the changes that have no doubt
> occurred during that gap.  Is there any way to use the older UHD with the
> newer Petalinux tools?

You might be able to just remove all usage of Neon. Try removing these
lines:

https://github.com/EttusResearch/uhd/blob/6013a511370b9452020adfc72d7893f1c3bb2963/host/lib/convert/CMakeLists.txt#L65-L79

Of course, you'll lose the Neon assembly acceleration. Depending on your
app, that might still be fast enough.

-- M


> Here's the first of many similar errors:
> 
> [  5%] Building CXX object
> lib/CMakeFiles/uhd.dir/convert/convert_with_neon.cpp.o
> In file included from
> /home/daryl/RB/ZP/uhd/host/lib/convert/convert_with_neon.cpp:20:0:
> /home/daryl/Petalinux/2017.3/tools/linux-i386/gcc-arm-linux-gnueabi/lib/gcc/arm-linux-gnueabihf/6.2.1/include/arm_neon.h:
> In member function ‘virtual void
> __convert_fc32_1_sc16_item32_le_1_PRIORITY_SIMD::operator()(const
> input_type&, const output_type&, size_t)’:
> /home/daryl/Petalinux/2017.3/tools/linux-i386/gcc-arm-linux-gnueabi/lib/gcc/arm-linux-gnueabihf/6.2.1/include/arm_neon.h:5811:1:
> error: inlining failed in call to always_inline ‘float32x4_t
> vdupq_n_f32(float32_t)’: target specific option mismatch
>  vdupq_n_f32 (float32_t __a)
> 
> Any help will be appreciated.
> 
> --
> Daryl Lee
> Sr. Software Engineer
> 
> 
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com


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

Re: [USRP-users] noc_shell wrapper compatibility in UHD rfnoc-devel branch

2018-09-04 Thread Martin Braun via USRP-users

On Fri, Aug 17, 2018 at 03:53:56PM -0700, Andrew Danowitz via USRP-users wrote:
> 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?

Andrew,

can you please switch to master branch? We've retired the rfnoc-devel
branches.

Thanks,

Martin



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

Re: [USRP-users] DDC in USRP N200 Motherboard

2018-09-04 Thread Martin Braun via USRP-users

On Fri, Aug 31, 2018 at 10:14:27AM -0400, Marcus D. Leech via USRP-users wrote:
> On 08/31/2018 09:26 AM, Flo A. via USRP-users wrote:
> >Hei!
> >
> >I have a very general question regarding the function of the digital mixer
> >as part of the USRP motherboard-DDC:
> >
> >Since the RF signal is already mixed to baseband by the synthesizer
> >component of e.g. the LFRX daugtherboard, I do not understand why we need
> >another mixer after the ADC as part of the DDC.
> >
> >Probably this is more a question related to DDCs in general but it would
> >be great if you could provide me with an explanation for that.
> >
> >Thanks in advance cheers!
> >
> Neither the LFRX, nor the BASIC_RX have on-board synthesizers and mixers, so
> in that *particular* case, the DDC is crucial to bringing the
>   RF signal down to baseband.
> 
> For synthesized boards, the DDC is also used to "fine tune" the baseband
> conversion, since real-world synthesizers have a finite frequency
>   step-size.
> 
> The other part of the DDC is doing rate conversion (filtering and
> decimation), since the ADC operates at a fixed sample rate of 100Msps
>   on the N2xx.

Also, you can tune very accurately (in time) with the DDC, because it
doesn't have any kind of ringing effect as LOs do when re-tuned. Say
you're doing frequency hopping: It's much easier to do this with digital
tuning than with LO tuning (of course, you're limited to the 80 MHz of
your passband).

-- M


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

Re: [USRP-users] About the PCIe connection and drivers

2018-09-04 Thread Martin Braun via USRP-users

On Mon, Sep 03, 2018 at 11:39:56AM +, Peng Wang via USRP-users wrote:
>Hi all,
> 
>I have couple of USRP X310 and also the PCIe connectivity kit. However, I
>found that the driver [1] says that it can only support up to kernel
>version 4.2.x. Since I am using ubuntu 18.04 with much newer kernel so I
>cannot install the driver. My questions would be:
> 
>1. What is the status of the new driver? It is going to be updated to
>support newer Linux kernel soon?
> 
>2. Is it possible to install the 4.2.x kernel in Ubuntu 18.04? I am not an
>expert in Linux and my test failed in waiting for "Loading initial
>ramdisk" after installing the kernel 4.2.8.


We very recently updated; the current public manual is still lagging
master branch, but you can see this page for reference:
https://github.com/EttusResearch/uhddev/blob/master/host/docs/ni_rio_kernel.dox

Drivers:
http://files.ettus.com/binaries/niusrprio/niusrprio-installer-18.0.0.tar.gz

-- M


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

Re: [USRP-users] Software changes for new FPGA registers B205

2018-09-04 Thread Martin Braun via USRP-users

On 09/03/2018 08:21 PM, Chintan Patel via USRP-users wrote:
> Hello,
> 
> I have defined a new readback register in the FPGA in the b205_core
> file, adjacent to the lock state register. What is the least invasive
> function call/method in the UHD driver/software to be able to read this
> newly defined register?

This is how the lock state reg is read:
https://github.com/EttusResearch/uhd/blob/6013a511370b9452020adfc72d7893f1c3bb2963/host/lib/usrp/b200/b200_impl.cpp#L1325

...and if you want to read your own readback regs on that address space,
you'll need to add code that does something similar. The easiest way is
to then bind that register to a property and you can read it out in your
own software.

However, we recently added an even-less invasive way of accessing user
regs. However, they would have to live in the user_regs address space.
See the manual for more info:

http://files.ettus.com/manual/page_usrp_b200.html#b200_customfpga

-- M

> 
> Thanks
> C
> 
> 
> ___
> 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] sc12 on B2xx

2018-09-04 Thread Martin Braun via USRP-users

On 09/03/2018 07:50 PM, Marcus D. Leech via USRP-users wrote:
> On 09/03/2018 12:15 AM, Marcus D. Leech via USRP-users wrote:
>> On 09/03/2018 12:11 AM, RizThon wrote:
>>> Thanks, I'll try to run it on some intel hardware ("Ettus Research
>>> recommends using the Intel Series 7, 8, and 9 USB controllers.") as
>>> well as on Linux.
>>>
>>> Concerning my question on SC12, namely which UHD version can I use,
>>> does anyone know?
>> SC12, SC16, SC8 should all work at least up to 3.10 or so.  I haven't
>> tried very-latest-master in the lab, but I'll check on it tomorrow.
>>   R&D at Ettus are out until Tuesday.
>>
> I can report that I ran into NO issues with SC12 at the max rate of my
> USB 2.0 connection (10e6 SPS) with:

Marcus, thanks for running these tests. We fixed a bunch of sc12-related
issues in the 3.13 release.

-- M

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

Re: [USRP-users] FM Spectrum Capture, to many zeros?

2018-09-04 Thread Marcus D. Leech via USRP-users


On 09/04/2018 02:10 PM, Jeremy Foran wrote:

*@Brian*
what format should this data be in?  Is there a common file type for 
this kind of trouble shooting?


*@Marcus*
In terms of my intentions, I would like to same 20Mhz of spectrum 
(88Hmz-108Mhz) at a rate of ~20Mhz, the RF team has told me that 
should be enough to test the quality of various FM streams in the 
space.  The idea is that you could analyze the entire RF space in a 
geographic location but also run assessments on the quality of audio 
streams being broadcasted over the air.

So, you need your sample-rate to be 20Msps, rather than 1Msps.

The RX gain-control range on the WBX card is 31.5dB, so for off-the-air 
measurements, I'd suggest a higher value, like 20.





*uhd_usrp_probe:*
[INFO] [UHD] Mac OS; Clang version 9.1.0 (clang-902.0.39.2); 
Boost_106600; UHD_3.13.0.1-MacPorts-Release

[INFO] [USRP2] Opening a USRP2/N-Series device...
[INFO] [USRP2] Current recv frame size: 1472 bytes
[INFO] [USRP2] Current send frame size: 1472 bytes
_
 /
|   Device: USRP2 / N-Series Device
| _
|/
|   |   Mboard: N210r4
|   |   hardware: 2577
|   |   mac-addr: 00:80:2f:19:76:ea
|   |   ip-addr: 192.168.10.2
|   |   subnet: 255.255.255.255
|   |   gateway: 255.255.255.255
|   |   gpsdo: none
|   |   serial: 315C829
|   |   FW Version: 12.4
|   |   FPGA Version: 11.1
|   |
|   |   Time sources:  none, external, _external_, mimo
|   |   Clock sources: internal, external, mimo
|   |   Sensors: mimo_locked, ref_locked
|   | _
|   |/
|   |   |   RX DSP: 0
|   |   |
|   |   |   Freq range: -50.000 to 50.000 MHz
|   | _
|   |/
|   |   |   RX DSP: 1
|   |   |
|   |   |   Freq range: -50.000 to 50.000 MHz
|   | _
|   |/
|   |   |   RX Dboard: A
|   |   |   ID: WBX v4, WBX v4 + Simple GDB (0x0063)
|   |   |   Serial: 3158D33
|   |   | _
|   |   |/
|   |   |   |   RX Frontend: 0
|   |   |   |   Name: WBXv4 RX+GDB
|   |   |   |   Antennas: TX/RX, RX2, CAL
|   |   |   |   Sensors: lo_locked
|   |   |   |   Freq range: 25.000 to 2200.000 MHz
|   |   |   |   Gain range PGA0: 0.0 to 31.5 step 0.5 dB
|   |   |   |   Bandwidth range: 4000.0 to 4000.0 step 0.0 Hz
|   |   |   |   Connection Type: IQ
|   |   |   |   Uses LO offset: No
|   |   | _
|   |   |/
|   |   |   |   RX Codec: A
|   |   |   |   Name: ads62p44
|   |   |   |   Gain range digital: 0.0 to 6.0 step 0.5 dB
|   |   |   |   Gain range fine: 0.0 to 0.5 step 0.1 dB
|   | _
|   |/
|   |   |   TX DSP: 0
|   |   |
|   |   |   Freq range: -200.000 to 200.000 MHz
|   | _
|   |/
|   |   |   TX Dboard: A
|   |   |   ID: WBX v4 (0x0062)
|   |   |   Serial: 3158D33
|   |   |   ID: WBX + Simple GDB, WBX v3 + Simple GDB, WBX v4 + Simple 
GDB, WBX-120 + Simple GDB (0x004f)

|   |   |   Serial: 3153A62
|   |   | _
|   |   |/
|   |   |   |   TX Frontend: 0
|   |   |   |   Name: WBXv4 TX+GDB
|   |   |   |   Antennas: TX/RX, CAL
|   |   |   |   Sensors: lo_locked
|   |   |   |   Freq range: 25.000 to 2200.000 MHz
|   |   |   |   Gain range PGA0: 0.0 to 31.0 step 1.0 dB
|   |   |   |   Bandwidth range: 4000.0 to 4000.0 step 0.0 Hz
|   |   |   |   Connection Type: IQ
|   |   |   |   Uses LO offset: No
|   |   | _
|   |   |/
|   |   |   |   TX Codec: A
|   |   |   |   Name: ad9777
|   |   |   |   Gain Elements: None




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

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

2018-09-04 Thread EJ Kreinar via USRP-users

Hey Andrew,

If the OOT repo is set up correctly, you will not need to add the OOT
Xilinx IPs manually -- I regularly (daily, in fact) build FPGA images in
uhd-fpga that use OOT Xilinx IP and OOT HLS, and this can be a fully
automated command-line process using the Makefile includes.

Let me know if you run into specific issues and I can try to help point out
ways to including various files from OOTs folders.

EJ

On Tue, Sep 4, 2018 at 1:06 PM Andrew Danowitz via USRP-users <
usrp-users@lists.ettus.com> wrote:

> 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 mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] FM Spectrum Capture, to many zeros?

2018-09-04 Thread Jeremy Foran via USRP-users

@Brian
what format should this data be in?  Is there a common file type for this kind 
of trouble shooting?

@Marcus
In terms of my intentions, I would like to same 20Mhz of spectrum 
(88Hmz-108Mhz) at a rate of ~20Mhz, the RF team has told me that should be 
enough to test the quality of various FM streams in the space.  The idea is 
that you could analyze the entire RF space in a geographic location but also 
run assessments on the quality of audio streams being broadcasted over the air.

uhd_usrp_probe:
[INFO] [UHD] Mac OS; Clang version 9.1.0 (clang-902.0.39.2); Boost_106600; 
UHD_3.13.0.1-MacPorts-Release
[INFO] [USRP2] Opening a USRP2/N-Series device...
[INFO] [USRP2] Current recv frame size: 1472 bytes
[INFO] [USRP2] Current send frame size: 1472 bytes
  _
 /
|   Device: USRP2 / N-Series Device
| _
|/
|   |   Mboard: N210r4
|   |   hardware: 2577
|   |   mac-addr: 00:80:2f:19:76:ea
|   |   ip-addr: 192.168.10.2
|   |   subnet: 255.255.255.255
|   |   gateway: 255.255.255.255
|   |   gpsdo: none
|   |   serial: 315C829
|   |   FW Version: 12.4
|   |   FPGA Version: 11.1
|   |
|   |   Time sources:  none, external, _external_, mimo
|   |   Clock sources: internal, external, mimo
|   |   Sensors: mimo_locked, ref_locked
|   | _
|   |/
|   |   |   RX DSP: 0
|   |   |
|   |   |   Freq range: -50.000 to 50.000 MHz
|   | _
|   |/
|   |   |   RX DSP: 1
|   |   |
|   |   |   Freq range: -50.000 to 50.000 MHz
|   | _
|   |/
|   |   |   RX Dboard: A
|   |   |   ID: WBX v4, WBX v4 + Simple GDB (0x0063)
|   |   |   Serial: 3158D33
|   |   | _
|   |   |/
|   |   |   |   RX Frontend: 0
|   |   |   |   Name: WBXv4 RX+GDB
|   |   |   |   Antennas: TX/RX, RX2, CAL
|   |   |   |   Sensors: lo_locked
|   |   |   |   Freq range: 25.000 to 2200.000 MHz
|   |   |   |   Gain range PGA0: 0.0 to 31.5 step 0.5 dB
|   |   |   |   Bandwidth range: 4000.0 to 4000.0 step 0.0 Hz
|   |   |   |   Connection Type: IQ
|   |   |   |   Uses LO offset: No
|   |   | _
|   |   |/
|   |   |   |   RX Codec: A
|   |   |   |   Name: ads62p44
|   |   |   |   Gain range digital: 0.0 to 6.0 step 0.5 dB
|   |   |   |   Gain range fine: 0.0 to 0.5 step 0.1 dB
|   | _
|   |/
|   |   |   TX DSP: 0
|   |   |
|   |   |   Freq range: -200.000 to 200.000 MHz
|   | _
|   |/
|   |   |   TX Dboard: A
|   |   |   ID: WBX v4 (0x0062)
|   |   |   Serial: 3158D33
|   |   |   ID: WBX + Simple GDB, WBX v3 + Simple GDB, WBX v4 + Simple GDB, 
WBX-120 + Simple GDB (0x004f)
|   |   |   Serial: 3153A62
|   |   | _
|   |   |/
|   |   |   |   TX Frontend: 0
|   |   |   |   Name: WBXv4 TX+GDB
|   |   |   |   Antennas: TX/RX, CAL
|   |   |   |   Sensors: lo_locked
|   |   |   |   Freq range: 25.000 to 2200.000 MHz
|   |   |   |   Gain range PGA0: 0.0 to 31.0 step 1.0 dB
|   |   |   |   Bandwidth range: 4000.0 to 4000.0 step 0.0 Hz
|   |   |   |   Connection Type: IQ
|   |   |   |   Uses LO offset: No
|   |   | _
|   |   |/
|   |   |   |   TX Codec: A
|   |   |   |   Name: ad9777
|   |   |   |   Gain Elements: None


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

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

2018-09-04 Thread 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

Re: [USRP-users] FM Spectrum Capture, to many zeros?

2018-09-04 Thread Marcus D. Leech via USRP-users


On 09/04/2018 10:56 AM, Jeremy Foran via USRP-users wrote:

Hello All,

I'm new to the community and excited to be a part of it.

I am looking to capture the full FM spectrum for a couple of seconds, 
88Mhz to 108Mhz, using the examples supplied by Ettus.  I seem to be 
getting more zeros in the results then I would have expected.  About 
half of the complex numbers will have a zero in it.  Is that normal? 
 Am I doing something wrong?  Code below:


#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

using namespace std::chrono;

static bool stop_signal_called = false;
void sig_int_handler(int){stop_signal_called = true;}

namespace po = boost::program_options;

using namespace std;

int UHD_SAFE_MAIN(int argc, char *argv[]){
uhd::set_thread_priority_safe();
//variables to be set by po
std::string args, file, ant, subdev, ref;
size_t total_num_samps;
double rate, freq, gain, bw, duration;
std::string addr, port;
uhd::usrp::multi_usrp::sptr usrp = uhd::usrp::multi_usrp::make(args);
//Lock mboard clocks
usrp->set_clock_source("internal");

freq= 98e6;
gain= 2;
rate= 1e6;
bw  = 20e6;
duration= 8;
//set the rx sample rate
usrp->set_rx_rate(rate);
uhd::tune_request_t tune_request(freq);
usrp->set_rx_freq(tune_request);
//set the rx rf gain
usrp->set_rx_gain(gain);

//set the analog frontend filter bandwidth
usrp->set_rx_bandwidth(bw);
//create a receive streamer
uhd::stream_args_t stream_args("fc32");
uhd::rx_streamer::sptr rx_stream = usrp->get_rx_stream(stream_args);

uhd::stream_cmd_t 
stream_cmd(uhd::stream_cmd_t::STREAM_MODE_NUM_SAMPS_AND_DONE);


const size_t samps_per_buff = rx_stream->get_max_num_samps();
total_num_samps = rate * duration;
stream_cmd.num_samps= total_num_samps;
stream_cmd.stream_now   = true;
//int const buff_size = rx_stream->get_max_num_samps();
rx_stream->issue_stream_cmd(stream_cmd);
uhd::rx_metadata_t md;

std::vector> buff(total_num_samps);
std::vector> sizeor(samps_per_buff);
const size_t size_of_buff = sizeor.size();
cout<<"Number of samples to capture: "<
int index=0;
while (!md.end_of_burst){
rx_stream->recv( &buff[index * samps_per_buff], size_of_buff, md);
index++;
}
milliseconds end_time_ms = duration_cast< milliseconds 
>(system_clock::now().time_since_epoch());

cout<<"Ending Capture."< p: buff){
if(p.real() == 0){real++;}
if(p.imag() == 0){imag++;}
if( (p.real()) == 0 && (p.imag() == 0) ){zero_all++;}
if( (p.real()) == 0 || (p.imag() == 0) ){zero++;}
}
cout<<"Samps : "

Re: [USRP-users] FM Spectrum Capture, to many zeros?

2018-09-04 Thread Brian Padalino via USRP-users

On Tue, Sep 4, 2018 at 11:28 AM Jeremy Foran via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Thanks Fabian,
>
> I have tried a few different values for timeout as per your recommendation
> and none seem to have an affect:
> 2.0
> 1.0
> 0.5
> 0.25
> 0.001
>
> All have about the same result of ~50% of the samples contain a zero.
>
> Ive also tried setting the sample sizes from fc32 to sc16 with more or
> less the same result.
>
> What would be a normal amount of zeros to receive from a stream like this?
>  %1? %10?
>

Can you link us to a small example you can upload somewhere?  It would be
enlightening to see what you're talking about in terms of samples.

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

Re: [USRP-users] GPS and frequency drift problems on TDMA receiver (E310)

2018-09-04 Thread Nate Temple via USRP-users

Hi David,

We would like to debug this off the mailing list. Could you please email us
at supp...@ettus.com with the device's serial number?


Regards,
Nate Temple

On Tue, Sep 4, 2018 at 8:31 AM, David Zamorano Fernández via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi all!
>
> We have implemented a TDMA receiver using the GPS signal to discipline the
> internal clock of the E310 and thus reduce frequency deviations. The
> system works fine, but in some cases, frequency drifts appear and the slots
> start to be erroneous (wrong CRC). The number of visible satellites has
> also been controlled and abruptly goes from a high number (12-13) to a few
> (1-2) or even none.
>
> The GPS antenna is outside. The system has been tested with different
> antennas and the behavior has been the same.
>
> Is there any kind of known bug in the gps daemon related to this? Is
> there any other reason why this may be happening?
>
> I attached an image of a large message capture. You can see how there are
> three zones where the frequency drift starts to appear and the slots start
> to be erroneous (green circle = ok and red circle = error).
>
> --
>
>
> [image: logo_170x100px.png] 
>
>
>
> David Zamorano Fernández
> Investigador - Desarrollador | Área de Comunicaciones Avanzadas
> Researcher - Developer | Advanced Communications Department
>
>
>
> Ph. (+34) 986 120 430  Ext. 3012
> dzamor...@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
>
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] RFNoC fifo filling up

2018-09-04 Thread Jason Matusiak via USRP-users

Sadly, I still seem to be having this issue.  Running threshold's test bench, I 
seem to be seeing it as well.  I've attempted to reset all the files I touched 
(mostly just debug statements), so I don't know if there is an issue with 
threshold, but I don't understand why the fifos are filling up without reading 
(axi_fifo_short).
 
I am going to try to find another machine to see if I threshold works there, 
but I am thinking that something else is going on somewhere
 
 
- Original Message - Subject: RE: Re: [USRP-users] RFNoC fifo 
filling up
From: "Jason Matusiak" 
Date: 8/24/18 7:25 am
To: "Sylvain Munaut" <246...@gmail.com>
Cc: "Brian Padalino" , "usrp-users" 


 Whoops, I misspoke on the SPP size.  At some point I must have changed the SPP 
to 1024.  So with a file size of 57344 bytes, it was 57344/8/1024 = 7 full 
packets that made it though.
 
When I tried it at SPP=16, 3840 bytes were in the file sink.  So 3840/8/16 = 30 
packets made it through.
 
This would leave me to believe that I am filling up that FIFO again, but I 
don't see that happening in the simulation.
 
 
- Original Message - Subject: RE: Re: [USRP-users] RFNoC fifo 
filling up
Date: 8/24/18 7:05 am
To: "Sylvain Munaut" <246...@gmail.com>
Cc: "Brian Padalino" , "usrp-users" 


 OK, let me elaborate since my first email was not very well written (I was 
throwing it out there on the way out the door).  I spent all day yesterday 
thinking that I was making progress, the last simulation was copacetic, so I 
did a build over night, and yet again, no love.
 
I started on this block about 2 weeks ago. Part way through, I realized that I 
was essentially making a block that acted a lot like noc_block_threshold 
combined with noc_block_siggen.  I want to detect a signal above a threshold 
and instead of passing it through as-is (like the threshold block does), I want 
to send my own data through.
 
So the main logic of my block revolves around the threshold axi_async_stream.v 
module that threshold uses since it handles the "tkeep" flag and the fact that 
I am not making a 1:1 block.
 
I monitor the sample_t* signals coming from the async module since those are 
the inputs into the module (async takes the axi_wrapper data and decodes it).  
When I see a sample above my threshold, I assert the threshold_tkeep flag (the 
flag that tells async that I want to keep the incoming sample.
 
So here is a rough flowgraph of my module:
 
*AXI wrapper sends its data to async_stream (I do not touch those signals at 
all)
 
*async outputs its stream of data/flags to "user" code (my module)
*I have a tkeep wire that monitors the sample data to see if it is above my 
threshold or not (I am not monitoring sample_tavlid here since me keeping/not 
keeping data shouldn't really matter for this flag
 
*sample_tvalid comes in and is wrapped around to threshold_tvalid (from "user" 
code back into async)
*threshold_tready is the output of axi_round_and_clip_complex (that is the 
i_tready output of siggen's output axi_round_and_clip_complex)
*threshold_tdata is the data coming out of axi_round_and_clip_complex (o_tdata)
*threshold_tready is passed into axi_round_and_clip_complex's o_tready
 
Now, to make sure that I don't have an issue with siggen spitting out data 
before the axi_interface is setup (since I am not using a physical enable like 
the original siggen module has), I have a register called first_byte (poor 
naming in hindsight).  It starts out cleared and isn't asserted until  
sample_tvalid && sample_tready go high (basically not until the first sample is 
being output to "user" land, meaning that the rfnoc radio is up and passed its 
first sample through [this tells me that the axi interface is up and running]). 
 That first_byte flag is used in the threshold_tkeep wire I mentioned above.  
So this means that async will be dumping any samples that might be accidentally 
sent to async by "user" code.
 
I am guessing that I am still causing some sort of deadlock because I can 
simulate fine and get the proper results, but things timeout in a real 
flowgraph right after starting.  My flowgraph ultimately dumps the samples into 
a time sink as well as a file sink.  I can see on the time sink that data 
passed through a little.  The file sink will show a handful of samples as well. 
 On my most recent run, there are 57344 bytes in the file (so 7168 samples).  
With my SPP being 16 (which I also use as a vector size), that works out to be 
448 packets.  Note though, that the file size changes slightly on each run.
 
One last comment.  I have all sorts of permitations of rfnoc fifos without much 
change.  My current flowgraph has an rfnoc:fifo follower by a dma fifo as the 
last two blocks before crossing into the host domain (I basically copied what 
fosphor does).
 
A lot of words there, but hopefully someone can spot something stupid that I am 
doing here.
 
- Original Message - Subject: Re: [USRP-users]

Re: [USRP-users] FM Spectrum Capture, to many zeros?

2018-09-04 Thread Fabian Schwartau via USRP-users

Hi,

the recv function has a return value which tells you the amount of
samples returned. Usually you use this value to increase your buffer
pointer and continue writing where you stopped.
You should also try to plot the data to see what is happening.
Hope that helps,

Fabian

Am 04.09.2018 um 17:27 schrieb Jeremy Foran:
> Thanks Fabian,
> 
> I have tried a few different values for timeout as per your
> recommendation and none seem to have an affect:
> 2.0
> 1.0
> 0.5
> 0.25
> 0.001
> 
> All have about the same result of ~50% of the samples contain a zero.
> 
> Ive also tried setting the sample sizes from fc32 to sc16 with more or
> less the same result.
> 
> What would be a normal amount of zeros to receive from a stream like
> this?  %1? %10?
> 
>> On Sep 4, 2018, at 11:11 AM, Fabian Schwartau via USRP-users
>> mailto:usrp-users@lists.ettus.com>> wrote:
>>
>> Hi,
>>
>> maybe your recv runs frequently into timeout. It is the 4th parameter
>> which is optional and set to a default value of 0.1 seconds.
>>
>> Best regards,
>>
>> Fabian
>>
>> Am 04.09.2018 um 16:56 schrieb Jeremy Foran via USRP-users:
>>> Hello All,
>>> I'm new to the community and excited to be a part of it.
>>> I am looking to capture the full FM spectrum for a couple of seconds,
>>> 88Mhz to 108Mhz, using the examples supplied by Ettus.  I seem to be
>>> getting more zeros in the results then I would have expected.  About
>>> half of the complex numbers will have a zero in it.  Is that normal?
>>>  Am I doing something wrong?  Code below:
>>> #include 
>>> #include 
>>> #include 
>>> #include 
>>> #include 
>>> #include 
>>> #include 
>>> #include 
>>> #include 
>>> #include 
>>> #include 
>>> #include 
>>> using namespace std::chrono;
>>> static bool stop_signal_called = false;
>>> void sig_int_handler(int){stop_signal_called = true;}
>>> namespace po = boost::program_options;
>>> using namespace std;
>>> int UHD_SAFE_MAIN(int argc, char *argv[]){
>>>     uhd::set_thread_priority_safe();
>>>     //variables to be set by po
>>>     std::string args, file, ant, subdev, ref;
>>>     size_t total_num_samps;
>>>     double rate, freq, gain, bw, duration;
>>>     std::string addr, port;
>>>     uhd::usrp::multi_usrp::sptr usrp = uhd::usrp::multi_usrp::make(args);
>>>     //Lock mboard clocks
>>>     usrp->set_clock_source("internal");
>>>     freq    = 98e6;
>>>     gain    = 2;
>>>     rate    = 1e6;
>>>     bw      = 20e6;
>>>     duration= 8;
>>>     //set the rx sample rate
>>>     usrp->set_rx_rate(rate);
>>>     uhd::tune_request_t tune_request(freq);
>>>     usrp->set_rx_freq(tune_request);
>>>     //set the rx rf gain
>>>     usrp->set_rx_gain(gain);
>>>     //set the analog frontend filter bandwidth
>>>     usrp->set_rx_bandwidth(bw);
>>>     //create a receive streamer
>>>     uhd::stream_args_t stream_args("fc32");
>>>     uhd::rx_streamer::sptr rx_stream = usrp->get_rx_stream(stream_args);
>>>     uhd::stream_cmd_t
>>> stream_cmd(uhd::stream_cmd_t::STREAM_MODE_NUM_SAMPS_AND_DONE);
>>>     const size_t samps_per_buff = rx_stream->get_max_num_samps();
>>>     total_num_samps         = rate * duration;
>>>     stream_cmd.num_samps    = total_num_samps;
>>>     stream_cmd.stream_now   = true;
>>> //    int const buff_size     = rx_stream->get_max_num_samps();
>>>     rx_stream->issue_stream_cmd(stream_cmd);
>>>     uhd::rx_metadata_t md;
>>>     std::vector> buff(total_num_samps);
>>>     std::vector> sizeor(samps_per_buff);
>>>     const size_t size_of_buff = sizeor.size();
>>>     cout<<"Number of samples to capture: "<>>     //allow for some setup time
>>>     std::this_thread::sleep_for(std::chrono::seconds(2));
>>> 
>>>     cout<<"Starting Capture."<>>     milliseconds start_time_ms = duration_cast< milliseconds
>>>  >(system_clock::now().time_since_epoch());
>>>     int index=0;
>>>     while (!md.end_of_burst){
>>>         rx_stream->recv( &buff[index * samps_per_buff], size_of_buff,
>>> md);
>>>         index++;
>>>     }
>>>     milliseconds end_time_ms = duration_cast< milliseconds
>>>  >(system_clock::now().time_since_epoch());
>>>     cout<<"Ending Capture."<>> 
>>> //    int x=1;
>>>     int zero        = 0;
>>>     int zero_all    = 0;
>>>     int real        = 0;
>>>     int imag        = 0;
>>>     for (std::complex p: buff){
>>>         if(p.real() == 0){real++;}
>>>         if(p.imag() == 0){imag++;}
>>>         if( (p.real()) == 0 && (p.imag() == 0) ){zero_all++;}
>>>         if( (p.real()) == 0 || (p.imag() == 0) ){zero++;}
>>>     }
>>>     cout<<"Samps     : "<>>     cout<<"Start     : "<>>     cout<<"End       : "<>>     cout<<"Total time: "<>> start_time_ms.count()<>>     cout<<"real      :"<>>     cout<<"image     :"<>>     cout<<"Zeros     :"<>>     cout<<"Zeros_all :"<>>     cout<<"Performance :"<>> double(buff.size()))<>>     std::cout << std::endl <<

[USRP-users] GPS and frequency drift problems on TDMA receiver (E310)

2018-09-04 Thread David Zamorano Fernández via USRP-users

Hi all!

We have implemented a TDMA receiver using the GPS signal to discipline the
internal clock of the E310 and thus reduce frequency deviations. The system
works fine, but in some cases, frequency drifts appear and the slots start
to be erroneous (wrong CRC). The number of visible satellites has also been
controlled and abruptly goes from a high number (12-13) to a few (1-2) or
even none.

The GPS antenna is outside. The system has been tested with different
antennas and the behavior has been the same.

Is there any kind of known bug in the gps daemon related to this? Is there
any other reason why this may be happening?

I attached an image of a large message capture. You can see how there are
three zones where the frequency drift starts to appear and the slots start
to be erroneous (green circle = ok and red circle = error).

--


[image: logo_170x100px.png] 



David Zamorano Fernández
Investigador - Desarrollador | Área de Comunicaciones Avanzadas
Researcher - Developer | Advanced Communications Department



Ph. (+34) 986 120 430  Ext. 3012
dzamor...@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] FM Spectrum Capture, to many zeros?

2018-09-04 Thread Jeremy Foran via USRP-users

Thanks Fabian,

I have tried a few different values for timeout as per your recommendation and 
none seem to have an affect:
2.0
1.0
0.5
0.25
0.001

All have about the same result of ~50% of the samples contain a zero.

Ive also tried setting the sample sizes from fc32 to sc16 with more or less the 
same result.

What would be a normal amount of zeros to receive from a stream like this?  %1? 
%10?

On Sep 4, 2018, at 11:11 AM, Fabian Schwartau via USRP-users 
mailto:usrp-users@lists.ettus.com>> wrote:

Hi,

maybe your recv runs frequently into timeout. It is the 4th parameter which is 
optional and set to a default value of 0.1 seconds.

Best regards,

Fabian

Am 04.09.2018 um 16:56 schrieb Jeremy Foran via USRP-users:
Hello All,
I'm new to the community and excited to be a part of it.
I am looking to capture the full FM spectrum for a couple of seconds, 88Mhz to 
108Mhz, using the examples supplied by Ettus.  I seem to be getting more zeros 
in the results then I would have expected.  About half of the complex numbers 
will have a zero in it.  Is that normal?  Am I doing something wrong?  Code 
below:
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
using namespace std::chrono;
static bool stop_signal_called = false;
void sig_int_handler(int){stop_signal_called = true;}
namespace po = boost::program_options;
using namespace std;
int UHD_SAFE_MAIN(int argc, char *argv[]){
uhd::set_thread_priority_safe();
//variables to be set by po
std::string args, file, ant, subdev, ref;
size_t total_num_samps;
double rate, freq, gain, bw, duration;
std::string addr, port;
uhd::usrp::multi_usrp::sptr usrp = uhd::usrp::multi_usrp::make(args);
//Lock mboard clocks
usrp->set_clock_source("internal");
freq= 98e6;
gain= 2;
rate= 1e6;
bw  = 20e6;
duration= 8;
//set the rx sample rate
usrp->set_rx_rate(rate);
uhd::tune_request_t tune_request(freq);
usrp->set_rx_freq(tune_request);
//set the rx rf gain
usrp->set_rx_gain(gain);
//set the analog frontend filter bandwidth
usrp->set_rx_bandwidth(bw);
//create a receive streamer
uhd::stream_args_t stream_args("fc32");
uhd::rx_streamer::sptr rx_stream = usrp->get_rx_stream(stream_args);
uhd::stream_cmd_t 
stream_cmd(uhd::stream_cmd_t::STREAM_MODE_NUM_SAMPS_AND_DONE);
const size_t samps_per_buff = rx_stream->get_max_num_samps();
total_num_samps = rate * duration;
stream_cmd.num_samps= total_num_samps;
stream_cmd.stream_now   = true;
//int const buff_size = rx_stream->get_max_num_samps();
rx_stream->issue_stream_cmd(stream_cmd);
uhd::rx_metadata_t md;
std::vector> buff(total_num_samps);
std::vector> sizeor(samps_per_buff);
const size_t size_of_buff = sizeor.size();
cout<<"Number of samples to capture: "
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

[cid:clip_image001.jpg]


Jeremy Foran

Technology Specialist

BAI COMMUNICATIONS

33 BLOOR ST EAST, TORONTO, ON, CANADA M4W 3H1
M: 416.500.4283 baicommunications.com
Stay connected - LinkedIn | Twitter | Google+ | YouTube

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

Re: [USRP-users] FM Spectrum Capture, to many zeros?

2018-09-04 Thread Fabian Schwartau via USRP-users


Hi,

maybe your recv runs frequently into timeout. It is the 4th parameter 
which is optional and set to a default value of 0.1 seconds.


Best regards,

Fabian

Am 04.09.2018 um 16:56 schrieb Jeremy Foran via USRP-users:

Hello All,

I'm new to the community and excited to be a part of it.

I am looking to capture the full FM spectrum for a couple of seconds, 
88Mhz to 108Mhz, using the examples supplied by Ettus.  I seem to be 
getting more zeros in the results then I would have expected.  About 
half of the complex numbers will have a zero in it.  Is that normal?  Am 
I doing something wrong?  Code below:


#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

using namespace std::chrono;

static bool stop_signal_called = false;
void sig_int_handler(int){stop_signal_called = true;}

namespace po = boost::program_options;

using namespace std;

int UHD_SAFE_MAIN(int argc, char *argv[]){
     uhd::set_thread_priority_safe();
     //variables to be set by po
     std::string args, file, ant, subdev, ref;
     size_t total_num_samps;
     double rate, freq, gain, bw, duration;
     std::string addr, port;
     uhd::usrp::multi_usrp::sptr usrp = uhd::usrp::multi_usrp::make(args);
     //Lock mboard clocks
     usrp->set_clock_source("internal");

     freq    = 98e6;
     gain    = 2;
     rate    = 1e6;
     bw      = 20e6;
     duration= 8;
     //set the rx sample rate
     usrp->set_rx_rate(rate);
     uhd::tune_request_t tune_request(freq);
     usrp->set_rx_freq(tune_request);
     //set the rx rf gain
     usrp->set_rx_gain(gain);

     //set the analog frontend filter bandwidth
     usrp->set_rx_bandwidth(bw);
     //create a receive streamer
     uhd::stream_args_t stream_args("fc32");
     uhd::rx_streamer::sptr rx_stream = usrp->get_rx_stream(stream_args);

     uhd::stream_cmd_t 
stream_cmd(uhd::stream_cmd_t::STREAM_MODE_NUM_SAMPS_AND_DONE);


     const size_t samps_per_buff = rx_stream->get_max_num_samps();
     total_num_samps         = rate * duration;
     stream_cmd.num_samps    = total_num_samps;
     stream_cmd.stream_now   = true;
//    int const buff_size     = rx_stream->get_max_num_samps();
     rx_stream->issue_stream_cmd(stream_cmd);
     uhd::rx_metadata_t md;

     std::vector> buff(total_num_samps);
     std::vector> sizeor(samps_per_buff);
     const size_t size_of_buff = sizeor.size();
     cout<<"Number of samples to capture: "< 


     cout<<"Starting Capture."<     milliseconds start_time_ms = duration_cast< milliseconds 
 >(system_clock::now().time_since_epoch());

     int index=0;
     while (!md.end_of_burst){
         rx_stream->recv( &buff[index * samps_per_buff], size_of_buff, md);
         index++;
     }
     milliseconds end_time_ms = duration_cast< milliseconds 
 >(system_clock::now().time_since_epoch());

     cout<<"Ending Capture."< 


//    int x=1;
     int zero        = 0;
     int zero_all    = 0;
     int real        = 0;
     int imag        = 0;
     for (std::complex p: buff){
         if(p.real() == 0){real++;}
         if(p.imag() == 0){imag++;}
         if( (p.real()) == 0 && (p.imag() == 0) ){zero_all++;}
         if( (p.real()) == 0 || (p.imag() == 0) ){zero++;}
     }
     cout<<"Samps     : "<     cout<<"Total time: "

[USRP-users] FPGA Repository and Stability

2018-09-04 Thread Brian Padalino via USRP-users

Recently there was a significant change to the noc_block_vector_iir
(specifically the vector_iir):

https://github.com/EttusResearch/fpga/commit/05ca30fe91330d54dcd005a3af4aeaa0dc26c8f8#diff-4b21f52231ba9f82bf132f633d594187

It's a pretty significant re-write of the block, and this behavior has me
asking a few questions:

1) Can anyone at Ettus expand on the reason for the major re-write? It
appears that the block itself worked previously so it seems like re-writing
it was a lot of effort to potentially add new bugs to things which weren't
there previously.

2) Why wasn't this re-written block added as a second option for a vectored
IIR implementation? There are 64-bits worth of RFNoC block ID's out
there. I understand if you don't want to support specific RFNoC blocks
anymore, and want to move onto new ones, but can you retire them in a
better, more thought out way? Moving them to a deprecated folder is fine
and giving one or two releases to get people to move away is fine, but
please stop gutting and re-writing something like it hasn't completely
changed. There are people who may want to stick with the old way of doing
things (the old DDC/DUCs are another recent re-write that could have been
handled better). Please give us a chance at trying to maintain stability.

I've tried to emphasize stability previously, and it seems like the host
side tries, almost to a fault, to maintain ABI compatibility and stability,
but the FPGA side seems to have a complete disregard for stability.

It would be really nice if someone from Ettus could answer the two
questions I posed.

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

[USRP-users] FM Spectrum Capture, to many zeros?

2018-09-04 Thread Jeremy Foran via USRP-users

Hello All,

I'm new to the community and excited to be a part of it.

I am looking to capture the full FM spectrum for a couple of seconds, 88Mhz to 
108Mhz, using the examples supplied by Ettus.  I seem to be getting more zeros 
in the results then I would have expected.  About half of the complex numbers 
will have a zero in it.  Is that normal?  Am I doing something wrong?  Code 
below:

#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

using namespace std::chrono;

static bool stop_signal_called = false;
void sig_int_handler(int){stop_signal_called = true;}

namespace po = boost::program_options;

using namespace std;

int UHD_SAFE_MAIN(int argc, char *argv[]){
uhd::set_thread_priority_safe();

//variables to be set by po
std::string args, file, ant, subdev, ref;
size_t total_num_samps;
double rate, freq, gain, bw, duration;
std::string addr, port;

uhd::usrp::multi_usrp::sptr usrp = uhd::usrp::multi_usrp::make(args);

//Lock mboard clocks
usrp->set_clock_source("internal");

freq= 98e6;
gain= 2;

rate= 1e6;
bw  = 20e6;
duration= 8;

//set the rx sample rate
usrp->set_rx_rate(rate);

uhd::tune_request_t tune_request(freq);
usrp->set_rx_freq(tune_request);

//set the rx rf gain
usrp->set_rx_gain(gain);

//set the analog frontend filter bandwidth
usrp->set_rx_bandwidth(bw);


//create a receive streamer
uhd::stream_args_t stream_args("fc32");
uhd::rx_streamer::sptr rx_stream = usrp->get_rx_stream(stream_args);

uhd::stream_cmd_t 
stream_cmd(uhd::stream_cmd_t::STREAM_MODE_NUM_SAMPS_AND_DONE);

const size_t samps_per_buff = rx_stream->get_max_num_samps();

total_num_samps = rate * duration;
stream_cmd.num_samps= total_num_samps;
stream_cmd.stream_now   = true;
//int const buff_size = rx_stream->get_max_num_samps();

rx_stream->issue_stream_cmd(stream_cmd);
uhd::rx_metadata_t md;

std::vector> buff(total_num_samps);

std::vector> sizeor(samps_per_buff);
const size_t size_of_buff = sizeor.size();

cout<<"Number of samples to capture: "<___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Phase Representation: Using Xilinx CORDIC IP with RFNoC

2018-09-04 Thread Brian Padalino via USRP-users

On Tue, Sep 4, 2018 at 9:15 AM Jon Pendlum via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hey Steve,
>
> The complex_to_mag_phase 32-bit output is a concatenation:  [31:16] phase,
> [15:0] magnitude. There is also complex_to_magphase_int16_int24 if you want
> 24-bit phase, mag. The phase value is in scaled radians. If you want a
> different phase precision, you will need to create a new CORDIC IP
> instance. Using the data with RFNoC, you have two options: 1) choose a
> precision that will work with the built in UHD converters. see:
> https://files.ettus.com/manual/page_converters.html or 2) handle the
> conversion on your own. In either case, AXI Wrapper expects 32-bit data, so
> you can concatenate or sign extend your data however works best for you.
>

To expand on Jon's answer, adding your own converter is pretty easy to do,
though I must admit I am not an expert.

Attached is what I had to do when receiving a u32 type from a magnitude
squared representation from a custom block.

Note that if you want to make very complicated typed to pass into a send()
or recv() call, that can also work.  You just need to register them the
same way.

One point of confusion I have, though, is when dealing with OOT modules
which describe their own converters.  It isn't clear to me, but there needs
to be a destructor defined: uhd::convert::converter::~converter().

To get things to compile for me, I just defined ~converter() to be nothing
since no resources were allocated, but if there are multiple OOT blocks
with converters in them (think fancy controller blocks with singular static
registrations with libuhd at construction or library loading), each trying
to define that destructor, I don't know how this is supposed to work.

As an experiment, for documentation, and to be complete, can someone from
Ettus write a converter going both ways for the 32-bit concatenation that
Jon described - [31:16] phase, [15:0] magnitude on the RFNoC side, and
complex float on the host side?  Both transmit and receive?  I think that
would be a good code example to have.

Thanks,
Brian

converter_example.cpp
Description: Binary data
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Rx streaming to alternate destination

2018-09-04 Thread Rob Kossler via USRP-users

Will,
I believe that I was told that this capability doesn't presently exist and
that it was not trivial to implement on your own. As an alternative, I had
tossed around the following ideas:
1)  having the host PC simply "repeat" the streaming to another IP address
2) placing the processing PC in-between the host PC and the USRP such that
the processing PC simply forwards all non-streaming packets, but intercepts
the streaming packets

However, I never got around to implementing either method above.
Rob


On Tue, Sep 4, 2018 at 12:46 AM Horix On via USRP-users <
usrp-users@lists.ettus.com> wrote:

> I was following this thread below, and I wanted to see if anyone has been 
> able to get X3x0, N310 streaming to a different IP/Port working?
>
> I am using RFNOC and have mostly followed this example: 
> https://github.com/EttusResearch/uhd/blob/master/host/examples/rfnoc_rx_to_file.cpp
>
> But the rx_streamer seems to ignore stream_args that specify IP/Port.
>
> I have a separate process on a different machine receiving and decoding VRT 
> packets, and would like to programmatically control this.
>
> Appreciate any help
>
> Thanks
>
> -- Will
>
> On 19 May 2018 20:34:46 GMT+02:00, Neel Pandeya via USRP-users  lists.ettus.com 
> > wrote:
> >*Hello Rob:
> *>>*This capability is not supported with the multi_usrp API on the X300,
> *>*X310,
> *>*N310.
> *>>*It was supported on the N200/N210.
> *>>*https://files.ettus.com/manual/page_usrp2.html#usrp2_altstream 
> 
> *>>*However, this capability is supported for the X300, X310, N310 using
> *>*the
> *>*RFNoC API.
> *>>*--Neel Pandeya
> *>*408-610-6370
> *>*On 7 May 2018 at 15:55, Rob Kossler via USRP-users <
> *>*usrp-users at lists.ettus.com 
> > wrote:
> *>>>* Hi,
> *>>* I am using UHD from a custom c++ application and I would like to
> *>*control
> *>>* the USRP from one port and send the Rx streaming samples to a
> *>*separate
> *>>* application at a different IP address using the other USRP SFP port.
> *>*I
> *>>* found in the documentation for stream_args_t that there are "port"
> *>*and
> *>>* "addr" args that can be set to send the streaming to an alternate
> *>>* destination.
> ** When I specify these args, I am not seeing traffic on the specified
> *>>* addr/port.  This occurs using an N310.  I would like this
> *>*functionality to
> *>>* work for both X310 and N310.  I am wondering if I am missing a step
> *>*or
> *>>* two.  Please let me know.
> ** Rob
> ** ___
> *>>* USRP-users mailing list
> *>>* USRP-users at 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 Representation: Using Xilinx CORDIC IP with RFNoC

2018-09-04 Thread Jon Pendlum via USRP-users

Hey Steve,

The complex_to_mag_phase 32-bit output is a concatenation:  [31:16] phase,
[15:0] magnitude. There is also complex_to_magphase_int16_int24 if you want
24-bit phase, mag. The phase value is in scaled radians. If you want a
different phase precision, you will need to create a new CORDIC IP
instance. Using the data with RFNoC, you have two options: 1) choose a
precision that will work with the built in UHD converters. see:
https://files.ettus.com/manual/page_converters.html or 2) handle the
conversion on your own. In either case, AXI Wrapper expects 32-bit data, so
you can concatenate or sign extend your data however works best for you.

Jonathon

On Tue, Sep 4, 2018 at 8:48 PM shachar J. brown via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi all,
>
> I'm trying to create a "complex-to-phase" by using the arctan within the
> Xilinx CORDIC IP.
> (Part of a simple fft-->1-in-N-->to-phase scheme).
> Quite frankly I am a bit confused with the different bit representations.
>
> According to the Xilinx manual (
> https://www.xilinx.com/support/documentation/ip_documentation/cordic/v6_0/pg105-cordic.pdf),
> the phase is represented by a 3QN format. How can such a format fit into an
> RFNoC design?
>
> Note: Is there a simpler way to calculate a complex-to-phase in RFNoC?
> I've noticed a "complex_to_mag_phase.v" within usrp3->lib->corgen, But I
> couldn't figure out whether the 32-bit output is a magnitude or a phase
>
> Thnx a lot,
> Steve
> ___
> 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] Phase Representation: Using Xilinx CORDIC IP with RFNoC

2018-09-04 Thread shachar J. brown via USRP-users

Hi all,

I'm trying to create a "complex-to-phase" by using the arctan within the
Xilinx CORDIC IP.
(Part of a simple fft-->1-in-N-->to-phase scheme).
Quite frankly I am a bit confused with the different bit representations.

According to the Xilinx manual (
https://www.xilinx.com/support/documentation/ip_documentation/cordic/v6_0/pg105-cordic.pdf),
the phase is represented by a 3QN format. How can such a format fit into an
RFNoC design?

Note: Is there a simpler way to calculate a complex-to-phase in RFNoC? I've
noticed a "complex_to_mag_phase.v" within usrp3->lib->corgen, But I
couldn't figure out whether the 32-bit output is a magnitude or a phase

Thnx a lot,
Steve
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

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

2018-09-04 Thread Jon Pendlum via USRP-users

If you only need integer decimation, noc_block_ddc should have everything
you need or close to it. Averaging across FFTs can be done with
noc_block_vector_iir. For an example, check out the
flowgraph rfnoc_vector_iir.grc in gr-ettus.

Jonathon

On Tue, Sep 4, 2018 at 3:23 PM Rich Maes  wrote:

> I’d like to add a configurable decimator and some averaging logic to the
> output of the FFT.  So I’ll be adding some new registers to the control
> bloc and verilog, but the overall core will still be very similar.
>
> I’ll take a look at the examples you reference below to see if that gets
> me going in the right direction.  Thanks.
> Rich
>
> On Sep 3, 2018, at 8:43 PM, Jon Pendlum  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

Re: [USRP-users] x310 simulating RFNoC block with Xilinx IP

Re: [USRP-users] N310 timeouts on Rx... Which UHD version will make my N310 work?

Re: [USRP-users] N310 timeouts on Rx... Which UHD version will make my N310 work?

[USRP-users] N310 timeouts on Rx... Which UHD version will make my N310 work?

Re: [USRP-users] FPGA Repository and Stability

Re: [USRP-users] FPGA Repository and Stability

Re: [USRP-users] FPGA Repository and Stability

Re: [USRP-users] N310 timeout before streaming complete

Re: [USRP-users] x310 simulating RFNoC block with Xilinx IP

Re: [USRP-users] Cross-compiling UHD library

Re: [USRP-users] noc_shell wrapper compatibility in UHD rfnoc-devel branch

Re: [USRP-users] DDC in USRP N200 Motherboard

Re: [USRP-users] About the PCIe connection and drivers

Re: [USRP-users] Software changes for new FPGA registers B205

Re: [USRP-users] sc12 on B2xx

Re: [USRP-users] FM Spectrum Capture, to many zeros?

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

Re: [USRP-users] FM Spectrum Capture, to many zeros?

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

Re: [USRP-users] FM Spectrum Capture, to many zeros?

Re: [USRP-users] FM Spectrum Capture, to many zeros?

Re: [USRP-users] GPS and frequency drift problems on TDMA receiver (E310)

Re: [USRP-users] RFNoC fifo filling up

Re: [USRP-users] FM Spectrum Capture, to many zeros?

[USRP-users] GPS and frequency drift problems on TDMA receiver (E310)

Re: [USRP-users] FM Spectrum Capture, to many zeros?

Re: [USRP-users] FM Spectrum Capture, to many zeros?

[USRP-users] FPGA Repository and Stability

[USRP-users] FM Spectrum Capture, to many zeros?

Re: [USRP-users] Phase Representation: Using Xilinx CORDIC IP with RFNoC

Re: [USRP-users] Rx streaming to alternate destination

Re: [USRP-users] Phase Representation: Using Xilinx CORDIC IP with RFNoC

[USRP-users] Phase Representation: Using Xilinx CORDIC IP with RFNoC

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

34 matches

Site Navigation

Mail list logo

Footer information