[USRP-users] Which bandwidth does uhd::usrp::multi_usrp::set_rx_bandwidth set?

2019-02-13 Thread Janos Buttgereit via USRP-users
Hi everyone,

after having read https://kb.ettus.com/About_USRP_Bandwidths_and_Sampling_Rates 
 I wonder what 
uhd::usrp::multi_usrp::set_rx_bandwidth does for setups with Daughterboards 
that have a fixed analog bandwidth? According to the API documentation it sets 
"the RX bandwidth on the frontend“ which to me seems to refer to the analog 
bandwidth. So does calling this function only result in any changes if the 
setup contains frontends with a configurable analog bandwidth?

Now what happens if I set a sample rate that is lower than the supported analog 
bandwidth? This should obviously decrease the data rate  of the stream from/to 
the host, however what happens before? Is the signal still sampled at a sample 
rate that is high enough to handle the analog bandwidth and then digitally 
filtered and decimated/interpolated by the FPGA to match the required host 
sample rate? E.g. in fact  the sample rate setting is more relevant for the 
actual bandwidth of a setup than the bandwidth setting which is only relevant 
to a few frontends?

I’d be happy to get a short feedback if I got it all right or if I 
misunderstood something?

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


[USRP-users] N310 Images with external LO

2019-02-13 Thread Kai-Uwe Storek via USRP-users
Hey Folks,

I'm struggling with the external LO feature of my N310. This issue might be
related to
http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2018-April/056233.html
.

Setup:
Signal generator outputs a continuous wave at 2.002 GHz (-50dBm) to the RX2
of RF0. With internal LO everything is fine (see pic1).

Problem:
In the next step I use the device argument "rx_lo_source=external" and
provide a 4 GHz CW with 3 dBm at LO IN 0/1 RX. The spectrum now shows a
significant image of the input signal. I played around with level of
external LO without any changes.

Any ideas?
Thanks in advance! :)

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


Re: [USRP-users] N310 Images with external LO

2019-02-13 Thread Robert via USRP-users
Hi Kai,

I faced the same issue. Apparently it is linked to the quadrature error 
correction (QEC) and can be solved turning off this calibration. This can be 
done by setting init_cals=BASIC, where you can add the relevant calibrations 
but avoid RX_QEC_INIT, see 
https://files.ettus.com/manual/page_usrp_n3xx.html#n3xx_mg_calibrations.

Robert

From: USRP-users [mailto:usrp-users-boun...@lists.ettus.com] On Behalf Of 
Kai-Uwe Storek via USRP-users
Sent: Wednesday, February 13, 2019 4:53 PM
To: usrp-users@lists.ettus.com
Subject: [USRP-users] N310 Images with external LO

Hey Folks,

I'm struggling with the external LO feature of my N310. This issue might be 
related to 
http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2018-April/056233.html.

Setup:
Signal generator outputs a continuous wave at 2.002 GHz (-50dBm) to the RX2 of 
RF0. With internal LO everything is fine (see pic1).

Problem:
In the next step I use the device argument "rx_lo_source=external" and provide 
a 4 GHz CW with 3 dBm at LO IN 0/1 RX. The spectrum now shows a significant 
image of the input signal. I played around with level of external LO without 
any changes.

Any ideas?
Thanks in advance! :)

Kai

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


Re: [USRP-users] N310 Images with external LO

2019-02-13 Thread Kai-Uwe Storek via USRP-users
Dear Robert,

thanks for the quick and helpful reply. Turning off this calibration
feature solves the issue.

Kai


Am Mi., 13. Feb. 2019 um 17:05 Uhr schrieb Robert via USRP-users <
usrp-users@lists.ettus.com>:

> Hi Kai,
>
>
>
> I faced the same issue. Apparently it is linked to the quadrature error
> correction (QEC) and can be solved turning off this calibration. This can
> be done by setting init_cals=BASIC, where you can add the relevant
> calibrations but avoid RX_QEC_INIT, see
> https://files.ettus.com/manual/page_usrp_n3xx.html#n3xx_mg_calibrations.
>
>
>
> Robert
>
>
>
> *From:* USRP-users [mailto:usrp-users-boun...@lists.ettus.com] *On Behalf
> Of *Kai-Uwe Storek via USRP-users
> *Sent:* Wednesday, February 13, 2019 4:53 PM
> *To:* usrp-users@lists.ettus.com
> *Subject:* [USRP-users] N310 Images with external LO
>
>
>
> Hey Folks,
>
>
>
> I'm struggling with the external LO feature of my N310. This issue might
> be related to
> http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2018-April/056233.html
> .
>
>
>
> Setup:
>
> Signal generator outputs a continuous wave at 2.002 GHz (-50dBm) to the
> RX2 of RF0. With internal LO everything is fine (see pic1).
>
>
>
> Problem:
>
> In the next step I use the device argument "rx_lo_source=external" and
> provide a 4 GHz CW with 3 dBm at LO IN 0/1 RX. The spectrum now shows a
> significant image of the input signal. I played around with level of
> external LO without any changes.
>
>
>
> Any ideas?
>
> Thanks in advance! :)
>
>
>
> Kai
>
>
> ___
> 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] [UHD] Announcing 3.14.0.0 Release Candidate 1

2019-02-13 Thread Michael West via USRP-users
Hi Nick,

Information on using DPDK can be found here:
http://files.ettus.com/manual/page_dpdk.html

DPDK can be used with any example.  Think of it as an accelerator for
Ethernet transports if using Intel NICs.

Regards,
Michael

On Thu, Feb 7, 2019 at 10:29 AM Nick Foster  wrote:

> Great news! DPDK support is an interesting development. Is there any
> documentation or examples which show this capability?
>
> Nick
>
>
> On Thu, Feb 7, 2019 at 10:05 AM Michael West via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> The release candidate of UHD version 3.14.0.0 has been tagged and is
>> available for testing.  This API release introduces support for the N320
>> and N321 USRPs soon to be released (watch for the announcement on
>> ettus.com!), a DPDK-based transport, and several other features and bug
>> fixes.  This release includes all bug fixes and enhancements in the
>> 3.13.0.1, 3.13.0.2, and 3.13.1.0 maintenance releases.
>>
>> The tag for this release candidate:
>> https://github.com/EttusResearch/uhd/releases/tag/v3.14.0.0-rc1
>>
>> There have been 406 commits since the last API release (3.13.0.0) which
>> can be viewed here:
>> https://github.com/EttusResearch/uhd/compare/v3.13.0.0...v3.14.0.0-rc1
>>
>> Please report any bugs found on the UHD issue tracker:
>> http://github.com/EttusResearch/uhd/issues
>> * Please do not use the issue tracker for help or support.
>>
>> Pull requests for direct code changes may be submitted to the UHD or FPGA
>> repositories:
>> http://github.com/EttusResearch/uhd/pulls
>> http://github.com/EttusResearch/fpga/pulls
>>
>> CHANGELOG:
>> ## 003.014.000.000
>> * N320: Add N320 and N321
>> * Test: Add Python API test
>> * Device3: Move from packet-based to byte-based flow control
>> * X300: Reduce default send_frame_size to 4000 over Ethernet
>> * UHD: Release recv buffers earlier in rx_streamer
>> * Device3: Constrain send_buff_size to input fifo size
>> * X300: Change Ethernet buffering
>> * MPMD: Parallelize broadcast-finding
>> * Device: Parallelize device discovery
>> * Docs: Fix Doxygen warnings
>> * B100: Move fifo_ctrl_excelsior to b100 subdir
>> * B100: Fix fifo_ctrl_excelsior not exiting
>> * B100: Remove all Boostisms from fifo_ctrl_excelsior
>> * B100: Demote some clocking-related log messages to trace
>> * X300: Log git hash and compat number as debug message
>> * N310: Modify AD9371 reset function to keep it in reset
>> * N3xx: clocking API changes for transitioning clock and time sources
>> * E320: bist: Fix ref_clock lock test implementation
>> * UHD: Fix ADF400x driver for ref counter and charge pump mode
>> * E320: bist: Add link_up test
>> * MPM: Get list of temperatures from all thermal zones
>> * E320: Add all 5 temp sensors, fan sensor and rssi sensors per channel
>> * E320: Fix tx/rx atr - antenna and frequency settings
>> * E320: Enable devtest for E320
>> * X300: Move defaults to their own header
>> * UHD: Improve constrained_device_args_t
>> * X300: Use constrained_args
>> * X300: Enable clock_source and time_source device args
>> * Test: Integrate Python API Tester into Devtest
>> * N3xx: Bump max rev to G/6
>> * N3xx: Improve error messages for invalid clock/time settings
>> * E320: images: Separate images package for Aurora image
>> * B200: Remove superfluous fake lambda
>> * B200: Add support for user regs
>> * Docs: Add info on how to implement user regs on B200
>> * UHD API: Add multi_usrp::get_user_settings_iface()
>> * N310: move init_rf_cal before JESD de/framer bringup
>> * UHD: Remove usage of time_t (except when required)
>> * NIRIO: Demote RPC client cancel/abort to TRACE
>> * RFNoC: Convert SR_READBACK_REG_FIFOSIZE to bytes
>> * Utils: Add Zip test to downloader
>> * Utils: Factor wait_for_lo_lock() out of cal utils
>> * DPDK: Add DPDK-based sockets-like library
>> * MPMD: add option to enum rfnoc blocks from args
>> * E320: Get RFNoC crossbar baseport from FPGA
>> * N3xx: Get RFNoC crossbar baseport from FPGA
>> * UHD: add default xport params to udp_zero_copy
>> * MPM: add link_speed xport_info
>> * MPMD: add link speed to xport udp
>> * Device3: remove tx_hint[send_buff_size]
>> * X300: remove default_buff_args properties
>> * RFNoC: Add ability to enable/disable RX timestamp
>> * RFNoC: add async message handler
>> * Examples: add rfnoc_radio_loopback example
>> * UHD: Update rx_frontend_gen3.v controls for 1/4-rate mixer
>> * UHD API: Move definition of ALL_MBOARDS and ALL_CHANS constants to
>>CPP file.
>> * MPM: Add __mpm_device__ as usrp_hwd module variable
>> * MPM: Add usrp_update_fs
>> * UHD: Add traffic counter to null source sink
>> * Examples: Add benchmark_streamer example
>> * Tools: Add tool to analyze settling time of gain and freq changes
>> * UHD API: Add multi_usrp::set_sync_source() API
>> * UHD: Improve documentation for the UHD exception types
>> * Examples: Add dual measurements to benchmark_streamer
>> * MPM: Add i2c APIs for simple transfers
>> * MPM: Add vector-based transfer function f

Re: [USRP-users] [UHD] Announcing 3.14.0.0 Release Candidate 1

2019-02-13 Thread Nick Foster via USRP-users
Any plans to update to the latest API? Won't compile with anything after
17.05.

On Wed, Feb 13, 2019, 11:33 AM Michael West  wrote:

> Hi Nick,
>
> Information on using DPDK can be found here:
> http://files.ettus.com/manual/page_dpdk.html
>
> DPDK can be used with any example.  Think of it as an accelerator for
> Ethernet transports if using Intel NICs.
>
> Regards,
> Michael
>
> On Thu, Feb 7, 2019 at 10:29 AM Nick Foster  wrote:
>
>> Great news! DPDK support is an interesting development. Is there any
>> documentation or examples which show this capability?
>>
>> Nick
>>
>>
>> On Thu, Feb 7, 2019 at 10:05 AM Michael West via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>>> The release candidate of UHD version 3.14.0.0 has been tagged and is
>>> available for testing.  This API release introduces support for the N320
>>> and N321 USRPs soon to be released (watch for the announcement on
>>> ettus.com!), a DPDK-based transport, and several other features and bug
>>> fixes.  This release includes all bug fixes and enhancements in the
>>> 3.13.0.1, 3.13.0.2, and 3.13.1.0 maintenance releases.
>>>
>>> The tag for this release candidate:
>>> https://github.com/EttusResearch/uhd/releases/tag/v3.14.0.0-rc1
>>>
>>> There have been 406 commits since the last API release (3.13.0.0) which
>>> can be viewed here:
>>> https://github.com/EttusResearch/uhd/compare/v3.13.0.0...v3.14.0.0-rc1
>>>
>>> Please report any bugs found on the UHD issue tracker:
>>> http://github.com/EttusResearch/uhd/issues
>>> * Please do not use the issue tracker for help or support.
>>>
>>> Pull requests for direct code changes may be submitted to the UHD or
>>> FPGA repositories:
>>> http://github.com/EttusResearch/uhd/pulls
>>> http://github.com/EttusResearch/fpga/pulls
>>>
>>> CHANGELOG:
>>> ## 003.014.000.000
>>> * N320: Add N320 and N321
>>> * Test: Add Python API test
>>> * Device3: Move from packet-based to byte-based flow control
>>> * X300: Reduce default send_frame_size to 4000 over Ethernet
>>> * UHD: Release recv buffers earlier in rx_streamer
>>> * Device3: Constrain send_buff_size to input fifo size
>>> * X300: Change Ethernet buffering
>>> * MPMD: Parallelize broadcast-finding
>>> * Device: Parallelize device discovery
>>> * Docs: Fix Doxygen warnings
>>> * B100: Move fifo_ctrl_excelsior to b100 subdir
>>> * B100: Fix fifo_ctrl_excelsior not exiting
>>> * B100: Remove all Boostisms from fifo_ctrl_excelsior
>>> * B100: Demote some clocking-related log messages to trace
>>> * X300: Log git hash and compat number as debug message
>>> * N310: Modify AD9371 reset function to keep it in reset
>>> * N3xx: clocking API changes for transitioning clock and time sources
>>> * E320: bist: Fix ref_clock lock test implementation
>>> * UHD: Fix ADF400x driver for ref counter and charge pump mode
>>> * E320: bist: Add link_up test
>>> * MPM: Get list of temperatures from all thermal zones
>>> * E320: Add all 5 temp sensors, fan sensor and rssi sensors per channel
>>> * E320: Fix tx/rx atr - antenna and frequency settings
>>> * E320: Enable devtest for E320
>>> * X300: Move defaults to their own header
>>> * UHD: Improve constrained_device_args_t
>>> * X300: Use constrained_args
>>> * X300: Enable clock_source and time_source device args
>>> * Test: Integrate Python API Tester into Devtest
>>> * N3xx: Bump max rev to G/6
>>> * N3xx: Improve error messages for invalid clock/time settings
>>> * E320: images: Separate images package for Aurora image
>>> * B200: Remove superfluous fake lambda
>>> * B200: Add support for user regs
>>> * Docs: Add info on how to implement user regs on B200
>>> * UHD API: Add multi_usrp::get_user_settings_iface()
>>> * N310: move init_rf_cal before JESD de/framer bringup
>>> * UHD: Remove usage of time_t (except when required)
>>> * NIRIO: Demote RPC client cancel/abort to TRACE
>>> * RFNoC: Convert SR_READBACK_REG_FIFOSIZE to bytes
>>> * Utils: Add Zip test to downloader
>>> * Utils: Factor wait_for_lo_lock() out of cal utils
>>> * DPDK: Add DPDK-based sockets-like library
>>> * MPMD: add option to enum rfnoc blocks from args
>>> * E320: Get RFNoC crossbar baseport from FPGA
>>> * N3xx: Get RFNoC crossbar baseport from FPGA
>>> * UHD: add default xport params to udp_zero_copy
>>> * MPM: add link_speed xport_info
>>> * MPMD: add link speed to xport udp
>>> * Device3: remove tx_hint[send_buff_size]
>>> * X300: remove default_buff_args properties
>>> * RFNoC: Add ability to enable/disable RX timestamp
>>> * RFNoC: add async message handler
>>> * Examples: add rfnoc_radio_loopback example
>>> * UHD: Update rx_frontend_gen3.v controls for 1/4-rate mixer
>>> * UHD API: Move definition of ALL_MBOARDS and ALL_CHANS constants to
>>>CPP file.
>>> * MPM: Add __mpm_device__ as usrp_hwd module variable
>>> * MPM: Add usrp_update_fs
>>> * UHD: Add traffic counter to null source sink
>>> * Examples: Add benchmark_streamer example
>>> * Tools: Add tool to analyze settling time of gain and freq changes
>>> * UHD