Re: [USRP-users] X310 Register's Memory Capability

[Derek Kozel via USRP-users]

Hi Steve,

As an addon to Jonathon's email, you haven't actually said that you want to
store filter taps. If you are storing generic data then the embedded regs
are unlikely to be helpful for you because you are not going to be using
the data with DSP48s.

Regards,
Derek

On Fri, Jun 8, 2018 at 6:04 AM, Jon Pendlum via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi Steve,
>
> USE_EMBEDDED_REGS_COEFFS means that the filter will attempt to infer
> the DSP48's embedded registers (specifically register B) for storing
> coefficients. You should refer to Xilinx's DSP48 design doc
> https://www.xilinx.com/support/documentation/user_
> guides/ug479_7Series_DSP48E1.pdf.
>
> Using embedded registers is more efficient, because those registers
> come for free as part of the DSP48. However, the embedded registers
> only have a reset and will initialize to all 0s (instead of the
> coefficients in COEFFS_VEC). At startup, the coefficients must be
> loaded via the settings register bus for the filter to be useful. This
> is not a big deal though, since the block controller for
> noc_block_fir_filter does that. Also, since the embedded registers are
> chained like shift register (via BCOUT output to B input), loading new
> coefficients while streaming causes the FIR filter output to be
> corrupted until all the new coefficients have been loaded.
>
> If you set USE_EMBEDDED_REGS_COEFFS = 0, then regular registers will
> be instantiated. Those registers will be initialized with COEFFS_VEC
> and the filter will always be ready to go. Also, the output will not
> be corrupted while loading new coefficients.
>
> I would suggest enabling USE_EMBEDDED_REGS_COEFFS unless you plan to
> constantly change coefficients and are worried about the filter output
> being corrupted.
>
> Jonathon
>
> On Fri, Jun 8, 2018 at 12:06 AM, shachar J. brown via USRP-users
>  wrote:
> > After examining the files in depth, I realized I need some help
> > understanding core concepts in FPGA programming:
> >
> > In "axi_fir_filter.v" there is a parameter named
> "USE_EMBEDDED_REGS_COEFFS",
> > and explained in comment: " Reduce register usage by only using embedded
> > registers in DSP slices".
> >
> > - What is the actual difference between registers and embedded registers?
> > - Does the implementation of the two only differ in usage of "wire" vs.
> > "reg"?
> >
> > Thanks for your time,
> > Steve
> >
> > On Thu, Jun 7, 2018 at 11:28 AM, Nick Foster 
> wrote:
> >>
> >> It's going to depend on how much block RAM the image is already using,
> and
> >> how much more you can use while still getting the image to route. The
> >> easiest way to find out will be to try it.
> >>
> >> On Thu, Jun 7, 2018, 9:14 AM shachar J. brown 
> >> wrote:
> >>>
> >>> Thanks Nick, that's an excellent example.
> >>> Do you know what are the memory size restrictions of the configuration
> >>> data?
> >>>
> >>> On Thu, Jun 7, 2018 at 10:50 AM, Nick Foster 
> >>> wrote:
> 
>  Look at the RFNoC FIR filter block for a good example of pushing
>  configuration data into a block via the settings bus.
> 
>  On Thu, Jun 7, 2018, 8:25 AM shachar J. brown via USRP-users
>   wrote:
> >
> > Hi all,
> >
> > I'm working on an X310.
> >
> > I have large data (tables of 1-3 K of variables) I would like to
> insert
> > into the FPGA's memory registers while running.
> >
> > How much space is available in the FPGA? Seemingly, the Address for
> the
> > "set_register" is only 8 bits long, and the first 128 addresses are
> reserved
> > for the Noc_Shell. So... Does that mean I can store only 128
> variables at a
> > time?
> >
> > (Just to clarify: I want to change the data while running, and I'd
> like
> > it to be inside the FPGA for performance issues).
> >
> > Thank a ton!
> > 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 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] USRP N310's schematics

[Derek Kozel via USRP-users]

Hello Jon,

The schematics are still being readied for posting to the website. I'm
sorry for the delay in having them available. Do you have any specific
questions that I might be able to answer in the meanwhile? The files will
be posted to the Knowledge Base when they are ready.
https://kb.ettus.com/N300/N310

Regards,
Derek

On Fri, Jun 8, 2018 at 2:19 AM, liu Jong via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi all,
> Could you tell us where we can download USRP N310's schematics.
> Thank you.
>
> best regards
> Jon
>
> ___
> 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 Register's Memory Capability

[Jon Pendlum via USRP-users]

Hi Steve,

USE_EMBEDDED_REGS_COEFFS means that the filter will attempt to infer
the DSP48's embedded registers (specifically register B) for storing
coefficients. You should refer to Xilinx's DSP48 design doc
https://www.xilinx.com/support/documentation/user_guides/ug479_7Series_DSP48E1.pdf.

Using embedded registers is more efficient, because those registers
come for free as part of the DSP48. However, the embedded registers
only have a reset and will initialize to all 0s (instead of the
coefficients in COEFFS_VEC). At startup, the coefficients must be
loaded via the settings register bus for the filter to be useful. This
is not a big deal though, since the block controller for
noc_block_fir_filter does that. Also, since the embedded registers are
chained like shift register (via BCOUT output to B input), loading new
coefficients while streaming causes the FIR filter output to be
corrupted until all the new coefficients have been loaded.

If you set USE_EMBEDDED_REGS_COEFFS = 0, then regular registers will
be instantiated. Those registers will be initialized with COEFFS_VEC
and the filter will always be ready to go. Also, the output will not
be corrupted while loading new coefficients.

I would suggest enabling USE_EMBEDDED_REGS_COEFFS unless you plan to
constantly change coefficients and are worried about the filter output
being corrupted.

Jonathon

On Fri, Jun 8, 2018 at 12:06 AM, shachar J. brown via USRP-users
 wrote:
> After examining the files in depth, I realized I need some help
> understanding core concepts in FPGA programming:
>
> In "axi_fir_filter.v" there is a parameter named "USE_EMBEDDED_REGS_COEFFS",
> and explained in comment: " Reduce register usage by only using embedded
> registers in DSP slices".
>
> - What is the actual difference between registers and embedded registers?
> - Does the implementation of the two only differ in usage of "wire" vs.
> "reg"?
>
> Thanks for your time,
> Steve
>
> On Thu, Jun 7, 2018 at 11:28 AM, Nick Foster  wrote:
>>
>> It's going to depend on how much block RAM the image is already using, and
>> how much more you can use while still getting the image to route. The
>> easiest way to find out will be to try it.
>>
>> On Thu, Jun 7, 2018, 9:14 AM shachar J. brown 
>> wrote:
>>>
>>> Thanks Nick, that's an excellent example.
>>> Do you know what are the memory size restrictions of the configuration
>>> data?
>>>
>>> On Thu, Jun 7, 2018 at 10:50 AM, Nick Foster 
>>> wrote:

 Look at the RFNoC FIR filter block for a good example of pushing
 configuration data into a block via the settings bus.

 On Thu, Jun 7, 2018, 8:25 AM shachar J. brown via USRP-users
  wrote:
>
> Hi all,
>
> I'm working on an X310.
>
> I have large data (tables of 1-3 K of variables) I would like to insert
> into the FPGA's memory registers while running.
>
> How much space is available in the FPGA? Seemingly, the Address for the
> "set_register" is only 8 bits long, and the first 128 addresses are 
> reserved
> for the Noc_Shell. So... Does that mean I can store only 128 variables at 
> a
> time?
>
> (Just to clarify: I want to change the data while running, and I'd like
> it to be inside the FPGA for performance issues).
>
> Thank a ton!
> 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 mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] USRP N310's schematics

[liu Jong via USRP-users]

Hi all,
Could you tell us where we can download USRP N310's schematics.
Thank you.

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

Re: [USRP-users] About USRP Bandwidths and Sampling Rates

[Neel Pandeya via USRP-users]

Hello Professor Mercado:

I don't think that a row for the AD9361 belongs in that particular table,
since that table is for daughterboards, but I see your overall point, and I
do agree with you. I will add another table in that section that discusses
the analog bandwidths for the USRP devices that do not use interchangeable
daughterboards (B200, B210, B200mini, B205mini, E310, E312, E313, N300,
N310).

--​Neel Pandeya




On 7 June 2018 at 09:52, Mercado, Alejandra via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Dear USRP community,
>
> Since I'm looking my USRP equipment from a didactic perspective, and I'm
> encouraging my students to find information for themselves, I would like to
> suggest an addition to the "About USRP Bandwidths and Sampling Rates
> " web page.
>
>- Section "Analog Bandwidth"
>- Could a row be added to the table for the B210? Specifically, a row
>with:
>   - AD9361   | 70MHz - 6GHz |  56MHz
>
>
> Thanks and regards,
> Ale
>
> ___
> 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 Overrun Using Split Stream

[Peter Sanchez via USRP-users]

Thanks Juan and Nick. Do you know if this is something RFNoC plans to
address in the future?

I put a DDC in front of the Split Stream block and now I don't see anymore
overrun errors, but I have 2 new problems. First, I can only run the flow
graph one time like Juan described. If I stop it and try to run it again I
don't get anything in my GUI FFT Sink windows, and the terminal prints
timeout on chan 0 errors.
Second, I have 2 FFT Sink windows (one for each steam) and they seem to
update slowly and one at a time. The top one will show live data for 1
second while the bottom looks like it has paused, then the bottom will show
live data for 1 second and the top looks paused and so on. CPU usage is low
and data from the X310 is only at 40MB/s.

On Thu, Jun 7, 2018 at 12:12 AM, Nick Foster  wrote:

> The same solution that works for E310 won't work for X310. The easiest fix
> will be to use a DDC block to reduce the sample rate ahead of the Split
> Stream block. The RFNoC bus cannot handle two full-rate streams on a single
> NoC port.
>
> Nick
>
>
> On Thu, Jun 7, 2018, 2:44 AM Juan Francisco via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> Unfortunately I don't have a fix for this, but I have seen similar
>> behavior.  I have only been able to get the SplitStream block on the first
>> run after an FPGA reconfiguration (or X310 power cycle).  If you try
>> running the flowgraph a second time, it hangs and nothing gets through the
>> SplitStream.
>>
>> On Wed, Jun 6, 2018 at 7:05 PM, Peter Sanchez via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>>> Hi All,
>>>
>>> I have a RFNoC Receiver --> Split stream --> x2 DDC blocks on the X310.
>>> I see a ton of overrun on chan 0 errors after adding the Split Stream
>>> block and GNU Radio Companion eventually crashes all together.
>>>
>>>
>>> I read about a similar problem on the E310 and the fix was to change the
>>> ce_clk to bus_clk in the rfnoc_ce_auto_inst (http://lists.ettus.com/
>>> pipermail/usrp-users_lists.ettus.com/2017-February/023539.html).
>>> I tried changing that in the rfnoc_ce_auto_inst_x310.v code and
>>> reflashed the FPGA but this didn't change the overrun errors.
>>>
>>> Any thoughts?
>>> Thanks!
>>>
>>> ___
>>> 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] IQ Calibration - CPU Performance Impact?

[Dave NotTelling via USRP-users]

Derek,
 I'm very happy to hear that it's the tiniest of additional overhead!

Thanks!

On Thu, Jun 7, 2018 at 2:32 PM Derek Kozel  wrote:

> Dave,
>
> It is most tunes (as often as needed when changing the frequency would
> change the IQ correction value). The overhead is, I believe, just a single
> write and thus completely inconsequential when compared to the usual length
> of synthesizer SPI writes and switch selection that tuning can cause.
>
> Regards,
> Derek
>
> On Thu, Jun 7, 2018 at 7:08 PM, Dave NotTelling via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> Robin,
>>  Thanks for your feedback!
>>
>> Marcus,
>>  And that overhead is just on the initial tune, or for all tunes?  I
>> do mostly timed commands, so should I allow for a little more time before
>> the deadline to send the timed command out?
>>
>> Thanks all!
>>
>> On Thu, Jun 7, 2018 at 1:56 PM Marcus D. Leech via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>>> On 06/07/2018 01:04 PM, Dave NotTelling via USRP-users wrote:
>>> > Is there a processing requirement impact to using the calibration CSV
>>> > file?  Does using the cal data have any impact on tuning time for the
>>> > radio itself?
>>> >
>>> > Thanks!
>>> >
>>> The calibration values are stuffed into some machinery in the FPGA when
>>> tuning happens.  So, there's a little extra command-channel overhead.
>>>
>>>
>>>
>>> ___
>>> 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] IQ Calibration - CPU Performance Impact?

[Derek Kozel via USRP-users]

Dave,

It is most tunes (as often as needed when changing the frequency would
change the IQ correction value). The overhead is, I believe, just a single
write and thus completely inconsequential when compared to the usual length
of synthesizer SPI writes and switch selection that tuning can cause.

Regards,
Derek

On Thu, Jun 7, 2018 at 7:08 PM, Dave NotTelling via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Robin,
>  Thanks for your feedback!
>
> Marcus,
>  And that overhead is just on the initial tune, or for all tunes?  I
> do mostly timed commands, so should I allow for a little more time before
> the deadline to send the timed command out?
>
> Thanks all!
>
> On Thu, Jun 7, 2018 at 1:56 PM Marcus D. Leech via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> On 06/07/2018 01:04 PM, Dave NotTelling via USRP-users wrote:
>> > Is there a processing requirement impact to using the calibration CSV
>> > file?  Does using the cal data have any impact on tuning time for the
>> > radio itself?
>> >
>> > Thanks!
>> >
>> The calibration values are stuffed into some machinery in the FPGA when
>> tuning happens.  So, there's a little extra command-channel overhead.
>>
>>
>>
>> ___
>> 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] IQ Calibration - CPU Performance Impact?

[Dave NotTelling via USRP-users]

Ian,
 Thank you very much!  That helps me out a lot!

-Dave

On Thu, Jun 7, 2018 at 2:17 PM Ian Buckley  wrote:

> Dave, from what I remember the overhead will be incurred each time a
> (re)tune takes you to a different line of the IQ imbalance table…you can
> see the granularity of that from simply looking in the CSV file.
> The overhead is very minor I suspect, we are talking about updating two
> integer coefficients (phase and mag correction) in setting regs for each TX
> and RX port.
> -Ian
>
> On Jun 7, 2018, at 11:08 AM, Dave NotTelling via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
> Robin,
>  Thanks for your feedback!
>
> Marcus,
>  And that overhead is just on the initial tune, or for all tunes?  I
> do mostly timed commands, so should I allow for a little more time before
> the deadline to send the timed command out?
>
> Thanks all!
>
> On Thu, Jun 7, 2018 at 1:56 PM Marcus D. Leech via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> On 06/07/2018 01:04 PM, Dave NotTelling via USRP-users wrote:
>> > Is there a processing requirement impact to using the calibration CSV
>> > file?  Does using the cal data have any impact on tuning time for the
>> > radio itself?
>> >
>> > Thanks!
>> >
>> The calibration values are stuffed into some machinery in the FPGA when
>> tuning happens.  So, there's a little extra command-channel overhead.
>>
>>
>>
>> ___
>> 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] IQ Calibration - CPU Performance Impact?

[Ian Buckley via USRP-users]

Dave, from what I remember the overhead will be incurred each time a (re)tune 
takes you to a different line of the IQ imbalance table…you can see the 
granularity of that from simply looking in the CSV file.
The overhead is very minor I suspect, we are talking about updating two integer 
coefficients (phase and mag correction) in setting regs for each TX and RX port.
-Ian

> On Jun 7, 2018, at 11:08 AM, Dave NotTelling via USRP-users 
>  wrote:
> 
> Robin,
>  Thanks for your feedback!
> 
> Marcus,
>  And that overhead is just on the initial tune, or for all tunes?  I do 
> mostly timed commands, so should I allow for a little more time before the 
> deadline to send the timed command out?
> 
> Thanks all!
> 
> On Thu, Jun 7, 2018 at 1:56 PM Marcus D. Leech via USRP-users 
> mailto:usrp-users@lists.ettus.com>> wrote:
> On 06/07/2018 01:04 PM, Dave NotTelling via USRP-users wrote:
> > Is there a processing requirement impact to using the calibration CSV 
> > file?  Does using the cal data have any impact on tuning time for the 
> > radio itself?
> >
> > Thanks!
> >
> The calibration values are stuffed into some machinery in the FPGA when 
> tuning happens.  So, there's a little extra command-channel overhead.
> 
> 
> 
> ___
> 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] IQ Calibration - CPU Performance Impact?

[Dave NotTelling via USRP-users]

Robin,
 Thanks for your feedback!

Marcus,
 And that overhead is just on the initial tune, or for all tunes?  I do
mostly timed commands, so should I allow for a little more time before the
deadline to send the timed command out?

Thanks all!

On Thu, Jun 7, 2018 at 1:56 PM Marcus D. Leech via USRP-users <
usrp-users@lists.ettus.com> wrote:

> On 06/07/2018 01:04 PM, Dave NotTelling via USRP-users wrote:
> > Is there a processing requirement impact to using the calibration CSV
> > file?  Does using the cal data have any impact on tuning time for the
> > radio itself?
> >
> > Thanks!
> >
> The calibration values are stuffed into some machinery in the FPGA when
> tuning happens.  So, there's a little extra command-channel overhead.
>
>
>
> ___
> 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] IQ Calibration - CPU Performance Impact?

[Marcus D. Leech via USRP-users]

On 06/07/2018 01:04 PM, Dave NotTelling via USRP-users wrote:
Is there a processing requirement impact to using the calibration CSV 
file?  Does using the cal data have any impact on tuning time for the 
radio itself?


Thanks!

The calibration values are stuffed into some machinery in the FPGA when 
tuning happens.  So, there's a little extra command-channel overhead.




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

Re: [USRP-users] IQ Calibration - CPU Performance Impact?

[ROBIN TORTORA via USRP-users]

What I have noticed over the years is the only impact to tuning is the first 
time you tune, the file is read in and any disk IO is slow relatively speaking. 
 Subsequent tunes after the first are much faster and consistent :)

> On June 7, 2018 at 1:04 PM Dave NotTelling via USRP-users 
>  wrote:
> 
> Is there a processing requirement impact to using the calibration CSV 
> file?  Does using the cal data have any impact on tuning time for the radio 
> itself?
> 
> Thanks!
> ___
> 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] IQ Calibration - CPU Performance Impact?

[Dave NotTelling via USRP-users]

Is there a processing requirement impact to using the calibration CSV
file?  Does using the cal data have any impact on tuning time for the radio
itself?

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

Re: [USRP-users] [UHD] Announcing 3.12.0.0 Release

[Martin Braun via USRP-users]

On 06/06/2018 08:26 AM, Martin Braun wrote:
> - 3.12.0.0 removed some public API calls, it is thus an API-breaking
>   release (note that these were some obscure API calls, most users
>   won't see a difference. GNU Radio users certainly won't).
>   If you want to keep everything as stable as possible, but want all the
>   recent bugfixes, pick the 3.11.1.0 release.

The following API calls were removed:

- uhd::time_spec_t::get_system_time(). Migration guide: If you're using
C++11, there are actually std::chrono calls you can use, such as
std::chrono::system_clock::now().

- uhd::spin_wait_with_timeout(). Migration guide: There are plenty of
spinlock implementation available, pick whatever suits your need best.

- uhd::simple_claimer: This is effectively a lock with timeout
capabilities, C++ provides alternatives to that.


Note that all those API calls were flagged as 'DEPRECATED' for the 3.11
release cycle, we will do our best to flag API calls long before they're
due to go.

Cheers,
Martin

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

[USRP-users] About USRP Bandwidths and Sampling Rates

[Mercado, Alejandra via USRP-users]

Dear USRP community,

Since I'm looking my USRP equipment from a didactic perspective, and I'm
encouraging my students to find information for themselves, I would like to
suggest an addition to the "About USRP Bandwidths and Sampling Rates
" web page.

   - Section "Analog Bandwidth"
   - Could a row be added to the table for the B210? Specifically, a row
   with:
  - AD9361   | 70MHz - 6GHz |  56MHz


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

Re: [USRP-users] [UHD] Announcing 3.12.0.0 Release

[Martin Braun via USRP-users]

On 06/06/2018 08:41 AM, Philip Balister wrote:
>> Tag, FPGA images and github-auto-produced tarballs can be found here:
>> https://github.com/EttusResearch/uhd/releases/tag/v3.12.0.0
> 
> If you are using tarball checksums to validate the tarball, github will
> occasionally regenerate the tarball leading to a changed checksum. So if
> you are validating tarballs before use, don't depend on stable checksums
> from github automatically generated tarballs. Sadly, this makes github
> auto created tarballs pretty useless.


Good thing we also provide our own tarballs! Unfortunately, our BuildBot
glitched and didn't upload the tarballs and Windows installers
yesterday, so we'll re-jigger that and make sure the tarballs are in the
usual spot.

Note that github auto-generates the github tarballs -- they're basically
always there.

Cheers,
Martin

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

[USRP-users] Streaming results with X310 and UHD 3.9, 3.11, 3.12

[Rob Kossler via USRP-users]

Hi,
I ran experiments using benchmark_rate using the latest versions of the
3.9.7 (UHD-3.9.LTS), 3.11.1 (maint), and 3.12.0 (master) branches.

benchmark_rate --args="addr=192.168.50.2" --rx_rate=100e6 --tx_rate=100e6
--channels="0,1"

Results

   - With 3.9.7, the command completes with no errors, consistently
   - With 3.11.1 and 3.12.0, the command completes with around 500
   underruns that occur right near the beginning
   - If I change the args to add ",second_addr=192.168.150.2", I get many
   more underruns and sequence errors (for 3.11.1 and 3.12.1 only; N/A for
   3.9.7)

Note that these data rates are only half the max rate of 200 MS/s per
channel.  (If I change rates to 200e6 (with dual 10Gb), the errors
dramatically increase).

I am wondering if the problem could be with my workstation HW or config or
if the problem is with the various UHD versions.  It seems that it is the
latter given that these experiments were run in succession using the exact
same workstation & USRP.  If indeed the problem is with later UHD versions,
I am wondering if there is a time frame for when such errors will be
fixed.  I would really like to move to the later versions for a number of
reasons, including support of N3xx.

Thank you.
Rob


Details

   - Ubuntu 16.04
   - Intel XL710 NIC with 1:4 fanout DAC
   - X310/UBX
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] X310/SBX-120 Expected Level of Phase Noise

[Marcus D. Leech via USRP-users]

On 06/07/2018 10:03 AM, Kenneth Collier via USRP-users wrote:

Hello All,

I have an X310/WBX-120 transmitting a 500kHz tone @ 1.6GHz through a 
power divider to RF A Rx and RF B Rx on an X310/SBX-120. The 10MHz 
reference for both devices is sourced from an Octoclock-G using its 
internal reference. The PPS reference for both devices is also sourced 
from the Octoclock-G which is connected to an active GPS antenna. The 
sample rate is 2.5 MS/s. I am using  UHD version 3.11.1.0-0-gad6b0935.


My hope is that the list can provide some insight on whether or not 
the variation vs time that I'm seeing when comparing the phase between 
the signal received on the two ports of the X310 is expected. There is 
very little drift but the phase variation oscillates within a few 
degrees (~+/-2deg). Please see the attached plot for reference. Here 
the mean phase difference is 4 degrees with a standard deviation of .5 
degrees. I am using integer-N tuning on both Tx and Rx since the phase 
deviations are noticeably worse using fractional-N tuning.


Thanks in advance for your feedback.

Ken

Could we first make sure that you have an attenuator in-line between 
your TX and RX?





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

Re: [USRP-users] X310 Register's Memory Capability

[shachar J. brown via USRP-users]

After examining the files in depth, I realized I need some help
understanding core concepts in FPGA programming:

In "axi_fir_filter.v" there is a parameter named
"USE_EMBEDDED_REGS_COEFFS", and explained in comment: " Reduce register
usage by only using embedded registers in DSP slices".

- What is the actual difference between registers and embedded registers?
- Does the implementation of the two only differ in usage of "wire" vs.
"reg"?

Thanks for your time,
Steve

On Thu, Jun 7, 2018 at 11:28 AM, Nick Foster  wrote:

> It's going to depend on how much block RAM the image is already using, and
> how much more you can use while still getting the image to route. The
> easiest way to find out will be to try it.
>
> On Thu, Jun 7, 2018, 9:14 AM shachar J. brown 
> wrote:
>
>> Thanks Nick, that's an excellent example.
>> Do you know what are the memory size restrictions of the configuration
>> data?
>>
>> On Thu, Jun 7, 2018 at 10:50 AM, Nick Foster 
>> wrote:
>>
>>> Look at the RFNoC FIR filter block for a good example of pushing
>>> configuration data into a block via the settings bus.
>>>
>>> On Thu, Jun 7, 2018, 8:25 AM shachar J. brown via USRP-users <
>>> usrp-users@lists.ettus.com> wrote:
>>>
 Hi all,

 I'm working on an X310.

 I have large data (tables of 1-3 K of variables) I would like to insert
 into the FPGA's memory registers while running.

 How much space is available in the FPGA? Seemingly, the Address for the
 "set_register" is only 8 bits long, and the first 128 addresses are
 reserved for the Noc_Shell. So... Does that mean I can store only 128
 variables at a time?

 (Just to clarify: I want to change the data while running, and I'd like
 it to be inside the FPGA for performance issues).

 Thank a ton!
 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

Re: [USRP-users] X310/SBX-120 Expected Level of Phase Noise

[ROBIN TORTORA via USRP-users]

What is the Tx gain of your WBX?

What is the Rx gain of your SBX?

What is the power your signal is going out at in dbm?


Assuming:

10MHz reference and 1PPS cables are all same length.

Both USRPs have been recently calibrated with utilities.


Splitters change phase, although I am not sure that it would make things vary 
as your graph illustrates...


> On June 7, 2018 at 10:03 AM Kenneth Collier via USRP-users 
>  wrote:
> 
> Hello All,
> 
> I have an X310/WBX-120 transmitting a 500kHz tone @ 1.6GHz through a 
> power divider to RF A Rx and RF B Rx on an X310/SBX-120. The 10MHz reference 
> for both devices is sourced from an Octoclock-G using its internal reference. 
> The PPS reference for both devices is also sourced from the Octoclock-G which 
> is connected to an active GPS antenna. The sample rate is 2.5 MS/s. I am 
> using  UHD version 3.11.1.0-0-gad6b0935.
> 
> My hope is that the list can provide some insight on whether or not the 
> variation vs time that I'm seeing when comparing the phase between the signal 
> received on the two ports of the X310 is expected. There is very little drift 
> but the phase variation oscillates within a few degrees (~+/-2deg). Please 
> see the attached plot for reference. Here the mean phase difference is 4 
> degrees with a standard deviation of .5 degrees. I am using integer-N tuning 
> on both Tx and Rx since the phase deviations are noticeably worse using 
> fractional-N tuning. 
> 
> Thanks in advance for your feedback.
> 
> Ken
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> 
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] X310/SBX-120 Expected Level of Phase Noise

[Kenneth Collier via USRP-users]

Hello All,

I have an X310/WBX-120 transmitting a 500kHz tone @ 1.6GHz through a power
divider to RF A Rx and RF B Rx on an X310/SBX-120. The 10MHz reference for
both devices is sourced from an Octoclock-G using its internal reference.
The PPS reference for both devices is also sourced from the Octoclock-G
which is connected to an active GPS antenna. The sample rate is 2.5 MS/s. I
am using  UHD version 3.11.1.0-0-gad6b0935.

My hope is that the list can provide some insight on whether or not the
variation vs time that I'm seeing when comparing the phase between the
signal received on the two ports of the X310 is expected. There is very
little drift but the phase variation oscillates within a few degrees
(~+/-2deg). Please see the attached plot for reference. Here the mean phase
difference is 4 degrees with a standard deviation of .5 degrees. I am using
integer-N tuning on both Tx and Rx since the phase deviations are
noticeably worse using fractional-N tuning.

Thanks in advance for your feedback.

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

Re: [USRP-users] Consequences of late command

[Derek Kozel via USRP-users]

Hello Fabian,

Commands which are late will be executed anyways and return the error
notification which you are seeing. Commands after it are also executed.
Depending on your application it is often possible to structure the
commands such that get_time_now only needs to be called in the beginning
and the act of receiving can be used to keep track of the device time. The
TwinRX fast frequency hopping example does this, allowing for continuous
and stable frequency hopping and burst receiving at a very high rate.

Regards,
Derek

On Thu, Jun 7, 2018 at 12:12 PM, Fabian Schwartau via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi everyone,
>
> I am currently working with timed commands to perform synchronized
> reception of multiple channels. As the timing is quite critilical I would
> like to use quite low delay I add to usrp->get_time_now() for the next
> command(s). However, sometimes it happens (even with quite high values like
> 20ms) that I get an late command error when reading the data from the
> stream. I guess this can happen from time to time if the thread was
> interrupted by the OS to do other stuff. And this is not a problem, if it
> happens just from time to time. But I don't know how to handle the problem.
> Is the command that was too late executed anyway? What about the commands
> after that?
> Is there is simple way to get in a clean state after receiving this error?
> Like delete all commands in the queue and clear all buffers?
>
> I am using two USRP X310 with each 2 TwinRX. PPS, 10 MHz and LOs are
> synchronized over all boards.
>
> Best regards,
> Fabian
>
> ___
> 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] Consequences of late command

[Fabian Schwartau via USRP-users]

Hi everyone,

I am currently working with timed commands to perform synchronized 
reception of multiple channels. As the timing is quite critilical I 
would like to use quite low delay I add to usrp->get_time_now() for the 
next command(s). However, sometimes it happens (even with quite high 
values like 20ms) that I get an late command error when reading the data 
from the stream. I guess this can happen from time to time if the thread 
was interrupted by the OS to do other stuff. And this is not a problem, 
if it happens just from time to time. But I don't know how to handle the 
problem.
Is the command that was too late executed anyway? What about the 
commands after that?
Is there is simple way to get in a clean state after receiving this 
error? Like delete all commands in the queue and clear all buffers?


I am using two USRP X310 with each 2 TwinRX. PPS, 10 MHz and LOs are 
synchronized over all boards.


Best regards,
Fabian

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

Re: [USRP-users] Building the UHD for N3XX devices.

[Derek Kozel via USRP-users]

Hello Walter,

The N310 uses MPMD as it's host side interface so the appropriate flag is
-DENABLE_MPMD. I'll see about documenting that better. The E3xx build flag
is entirely separate.
http://files.ettus.com/manual/page_usrp_n3xx.html#n3xx_software_dev_uhd

Regards,
Derek

On Thu, Jun 7, 2018 at 5:14 AM, Walter Maguire via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi all,
>
> When building the UHD for the E300 devices cmake uses the option
>
> -DENABLE_E300=ON
>
> However, when building for the N3XX devices there is no cmake option
>
> (Checked with cmake -LAH) to target the N3XX devices.
>
> git status returns
>
> Your branch is up-to-date with 'origin/rfnoc-devel'
>
> I was expecting to see a cmake option like
>
> -DENABLE_N300, -DENABLE_N310 or -DENABLE_N3XX.
>
> As both the N3XX and E3XX devices use zynq parts can we assume building
> for the -DENABLE_E300=ON will be sufficient for the N3XX devices?
>
> Are you planning on updating the build systems to target the N3XX parts
> directly?
>
>
> Regards
>
>
>
> Walter
>
>
> ___
> 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 Register's Memory Capability

[Nick Foster via USRP-users]

It's going to depend on how much block RAM the image is already using, and
how much more you can use while still getting the image to route. The
easiest way to find out will be to try it.

On Thu, Jun 7, 2018, 9:14 AM shachar J. brown 
wrote:

> Thanks Nick, that's an excellent example.
> Do you know what are the memory size restrictions of the configuration
> data?
>
> On Thu, Jun 7, 2018 at 10:50 AM, Nick Foster  wrote:
>
>> Look at the RFNoC FIR filter block for a good example of pushing
>> configuration data into a block via the settings bus.
>>
>> On Thu, Jun 7, 2018, 8:25 AM shachar J. brown via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>>> Hi all,
>>>
>>> I'm working on an X310.
>>>
>>> I have large data (tables of 1-3 K of variables) I would like to insert
>>> into the FPGA's memory registers while running.
>>>
>>> How much space is available in the FPGA? Seemingly, the Address for the
>>> "set_register" is only 8 bits long, and the first 128 addresses are
>>> reserved for the Noc_Shell. So... Does that mean I can store only 128
>>> variables at a time?
>>>
>>> (Just to clarify: I want to change the data while running, and I'd like
>>> it to be inside the FPGA for performance issues).
>>>
>>> Thank a ton!
>>> 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

Re: [USRP-users] X310 Register's Memory Capability

[shachar J. brown via USRP-users]

Thanks Nick, that's an excellent example.
Do you know what are the memory size restrictions of the configuration data?

On Thu, Jun 7, 2018 at 10:50 AM, Nick Foster  wrote:

> Look at the RFNoC FIR filter block for a good example of pushing
> configuration data into a block via the settings bus.
>
> On Thu, Jun 7, 2018, 8:25 AM shachar J. brown via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> Hi all,
>>
>> I'm working on an X310.
>>
>> I have large data (tables of 1-3 K of variables) I would like to insert
>> into the FPGA's memory registers while running.
>>
>> How much space is available in the FPGA? Seemingly, the Address for the
>> "set_register" is only 8 bits long, and the first 128 addresses are
>> reserved for the Noc_Shell. So... Does that mean I can store only 128
>> variables at a time?
>>
>> (Just to clarify: I want to change the data while running, and I'd like
>> it to be inside the FPGA for performance issues).
>>
>> Thank a ton!
>> 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

Re: [USRP-users] X310 Register's Memory Capability

[Nick Foster via USRP-users]

Look at the RFNoC FIR filter block for a good example of pushing
configuration data into a block via the settings bus.

On Thu, Jun 7, 2018, 8:25 AM shachar J. brown via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi all,
>
> I'm working on an X310.
>
> I have large data (tables of 1-3 K of variables) I would like to insert
> into the FPGA's memory registers while running.
>
> How much space is available in the FPGA? Seemingly, the Address for the
> "set_register" is only 8 bits long, and the first 128 addresses are
> reserved for the Noc_Shell. So... Does that mean I can store only 128
> variables at a time?
>
> (Just to clarify: I want to change the data while running, and I'd like it
> to be inside the FPGA for performance issues).
>
> Thank a ton!
> 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] X310 Register's Memory Capability

[shachar J. brown via USRP-users]

Hi all,

I'm working on an X310.

I have large data (tables of 1-3 K of variables) I would like to insert
into the FPGA's memory registers while running.

How much space is available in the FPGA? Seemingly, the Address for the
"set_register" is only 8 bits long, and the first 128 addresses are
reserved for the Noc_Shell. So... Does that mean I can store only 128
variables at a time?

(Just to clarify: I want to change the data while running, and I'd like it
to be inside the FPGA for performance issues).

Thank a ton!
Steve
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] RFNoC Overrun Using Split Stream

[Nick Foster via USRP-users]

The same solution that works for E310 won't work for X310. The easiest fix
will be to use a DDC block to reduce the sample rate ahead of the Split
Stream block. The RFNoC bus cannot handle two full-rate streams on a single
NoC port.

Nick

On Thu, Jun 7, 2018, 2:44 AM Juan Francisco via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Unfortunately I don't have a fix for this, but I have seen similar
> behavior.  I have only been able to get the SplitStream block on the first
> run after an FPGA reconfiguration (or X310 power cycle).  If you try
> running the flowgraph a second time, it hangs and nothing gets through the
> SplitStream.
>
> On Wed, Jun 6, 2018 at 7:05 PM, Peter Sanchez via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> Hi All,
>>
>> I have a RFNoC Receiver --> Split stream --> x2 DDC blocks on the X310.
>> I see a ton of overrun on chan 0 errors after adding the Split Stream
>> block and GNU Radio Companion eventually crashes all together.
>>
>>
>> I read about a similar problem on the E310 and the fix was to change the
>> ce_clk to bus_clk in the rfnoc_ce_auto_inst (
>> http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2017-February/023539.html
>> ).
>> I tried changing that in the rfnoc_ce_auto_inst_x310.v code and reflashed
>> the FPGA but this didn't change the overrun errors.
>>
>> Any thoughts?
>> Thanks!
>>
>> ___
>> 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

[USRP-users] unsuscribe

[Noelia Pérez Palma via USRP-users]

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