Re: [USRP-users] uhd_fft failure

[Michael Dickens via USRP-users]

Hi Saeid - The error shows that the version of UHD as installed isn't fully
compatible with the version of GR. GR 3.7.9.1 is quite old  ... unless you
need that specific version of GR, I'd recommend uninstalling that GR and
installing 3.7.14.5 from source. There are install guides around for doing
this build on Ubuntu of various versions. Hope this is useful! - MLD

On Thu, Oct 10, 2019 at 6:40 PM Saeid Hashemi via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hello everyone,
>
> I've been having some problems running the uhd_fft function recently. I
> did a fresh install of Ubuntu 16.04, then installed gnuradio using the
> package manager. When I run uhd_fft this is what I get. Would anyone have
> an idea as to where the problem is?
>
> Thanks,
> Saeid
>
> nuc03@nuc03:~$ apt-show-versions gnuradio
> gnuradio:amd64/xenial 3.7.9.1-2ubuntu1 uptodate
>
>
> nuc03@nuc03:~$ uhd_fft
> Traceback (most recent call last):
>   File "/usr/bin/uhd_fft", line 48, in 
> from gnuradio import uhd
>   File "/usr/lib/python2.7/dist-packages/gnuradio/uhd/__init__.py", line
> 135, in 
> _prepare_uhd_swig()
>   File "/usr/lib/python2.7/dist-packages/gnuradio/uhd/__init__.py", line
> 38, in _prepare_uhd_swig
> import uhd_swig
>   File "/usr/lib/python2.7/dist-packages/gnuradio/uhd/uhd_swig.py", line
> 28, in 
> _uhd_swig = swig_import_helper()
>   File "/usr/lib/python2.7/dist-packages/gnuradio/uhd/uhd_swig.py", line
> 24, in swig_import_helper
> _mod = imp.load_module('_uhd_swig', fp, pathname, description)
> ImportError: /usr/lib/python2.7/dist-packages/gnuradio/uhd/_
> uhd_swig.x86_64-linux-gnu.so: undefined symbol:
> _ZN3uhd11time_spec_t15get_system_timeEv
>
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>


-- 
Michael Dickens
Ettus Research Technical Support
Email: supp...@ettus.com
Web: https://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] Issues Completing Radio Build and Installation

[Nate Temple via USRP-users]

Hi Jon,

If you are following this app note [0], I would recommend starting with the
release-4 image. The pre-3.15 MPM based image that has been released is
currently a "beta" release. It lacks several of the dependencies required
to build out GNU Radio. We are working on a new release and hope to have it
posted soon.

[0] -
https://kb.ettus.com/Software_Development_on_the_E3xx_USRP_-_Building_RFNoC_UHD_/_GNU_Radio_/_gr-ettus_from_Source


Regards,
Nate Temple

On Fri, Oct 11, 2019 at 10:14 AM Jonathan Lockhart 
wrote:

> Greetings Ettus Radio List,
>
> I have recently acquired and began using an Ettus E312 and have been
> trying to configure the dev host and the cross compile environment.
> Unfortunately I am having issues completing some of these tasks with the
> pre-release version of 3.15 image that Ettus mentions you should use in the
> manual for the E312. I forward those issues to support but have heard no
> reply. Please refer below to the issues I am reporting. The GNURadio cross
> compile issue with the SDK and environment is the more crucial one at the
> moment. I was wondering if anyone else has been experiencing these issues
> and if so how did you proceed to get it resolved. Is there an image, sdk,
> GNURadio version that I should be using other than the 3.15 image and
> instructions that Ettus currently recommends using until a stable RC is
> provided?
>
> Thanks for your help and feedback.
>
> Regards,
> Jon Lockhart
>
>
> -- Forwarded message -
> From: Jonathan Lockhart 
> Date: Mon, Oct 7, 2019 at 3:16 PM
> Subject: Issues Completing Radio Build and Installation
> To: 
>
>
> Greetings Ettus Support,
>
> I recently acquired an Ettus E312 and I was looking to do some development
> on it. Unfortunately I am have been having some issues. The manual via
> files.ettus.com and the "Getting Started" both failed to provide a
> working environment.
>
> The farthest I got was downloading the meta section direction for the E312
> to get 3.15.0 image and sdk for the radio, and then following this guide
> page for 3.14, correcting the UHD install accordingly to comply with 3.15.
> (Guide
> https://kb.ettus.com/Software_Development_on_the_E3xx_USRP_-_Building_RFNoC_UHD_/_GNU_Radio_/_gr-ettus_from_Source#Running_RFNoC_Fosphor
> )
>
> When mounting the cross compiled UHD folders via the instructions on the
> radio, and using the uhd_usrp_probe command, there is an error checking for
> the libusb_init information.
>
> root@ni-e31x-313179A:~/newinstall# uhd_usrp_probe
> [INFO] [UHD] linux; GNU C++ version 7.3.0; Boost_106600;
> UHD_3.15.0.HEAD-0-g6563c537
> [ERROR] [UHD] Device discovery error: AssertionError:
> libusb_init(&_context) == 0
>   in libusb_session_impl::libusb_session_impl()
>   at /home/jon/rfnoc/src/uhd/host/lib/transport/libusb1_base.cpp:36
>
> [ERROR] [UHD] Device discovery error: AssertionError:
> libusb_init(&_context) == 0
>   in libusb_session_impl::libusb_session_impl()
>   at /home/jon/rfnoc/src/uhd/host/lib/transport/libusb1_base.cpp:36
>
> [ERROR] [UHD] Device discovery error: AssertionError:
> libusb_init(&_context) == 0
>   in libusb_session_impl::libusb_session_impl()
>   at /home/jon/rfnoc/src/uhd/host/lib/transport/libusb1_base.cpp:36
>
> [INFO] [MPMD] Initializing 1 device(s) in parallel with args:
> mgmt_addr=127.0.0.1,type=e3xx,product=e310_sg3,serial=313179A,claimed=False
> [INFO] [MPM.PeriphManager] Found 1 daughterboard(s).
> [INFO] [MPM.PeriphManager] init() called with device args
> `product=e310_sg3,mgmt_addr=127.0.0.1'.
> [INFO] [0/Radio_0] Initializing block control (NOC ID: 0x12AD10003310)
> [INFO] [0/DDC_0] Initializing block control (NOC ID: 0xDDC0)
> [INFO] [0/DUC_0] Initializing block control (NOC ID: 0xD0C2)
> [INFO] [0/Radio_0] RX freq = 2.4e+09
> [INFO] [0/Radio_0] RX band = 6
> [INFO] [0/Radio_0] RX SW1 = 5
> [INFO] [0/Radio_0] RX SWC = 0
> [INFO] [0/Radio_0] RX SWB = 1
> [INFO] [0/Radio_0] RX VCRX_SW = 1
> [INFO] [0/Radio_0] RX VCTXRX_SW = 0
> [INFO] [0/Radio_0] RX freq = 2.4e+09
> [INFO] [0/Radio_0] RX band = 6
> [INFO] [0/Radio_0] RX SW1 = 5
> [INFO] [0/Radio_0] RX SWC = 0
> [INFO] [0/Radio_0] RX SWB = 1
> [INFO] [0/Radio_0] RX VCRX_SW = 1
> [INFO] [0/Radio_0] RX VCTXRX_SW = 0
> [INFO] [0/Radio_0] RX freq = 2.4e+09
> [INFO] [0/Radio_0] RX band = 6
> [INFO] [0/Radio_0] RX SW1 = 5
> [INFO] [0/Radio_0] RX SWC = 0
> [INFO] [0/Radio_0] RX SWB = 1
> [INFO] [0/Radio_0] RX VCRX_SW = 1
> [INFO] [0/Radio_0] RX VCTXRX_SW = 0
> [INFO] [0/Radio_0] RX freq = 2.4e+09
> [INFO] [0/Radio_0] RX band = 6
> [INFO] [0/Radio_0] RX SW1 = 5
> [INFO] [0/Radio_0] RX SWC = 0
> [INFO] [0/Radio_0] RX SWB = 1
> [INFO] [0/Radio_0] RX VCRX_SW = 1
> [INFO] [0/Radio_0] RX VCTXRX_SW = 0
> [INFO] [0/Radio_0] RX freq = 2.4e+09
> [INFO] [0/Radio_0] RX band = 6
> [INFO] [0/Radio_0] RX SW1 = 5
> [INFO] [0/Radio_0] RX SWC = 0
> [INFO] [0/Radio_0] RX SWB = 1
> [INFO] [0/Radio_0] RX VCRX_SW = 1
> [INFO] [0/Radio_0] RX VCTXRX_SW = 0
> [INFO] [0/Radio_0] R

[USRP-users] Some questions regarding DDC implementation

[Francesco Restuccia via USRP-users]

Dear all,
I have some questions regarding the DDC implementation (ddc_chain.v, usrp2):

1) Why do we need two half-band filters (one large and one small) after the 
CIC? What is their purpose? Can’t we use just one half-band? 
2) What is the purpose of the scale factor multiplication after hb2? What does 
it compensate for? How do we decide its value?

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

Re: [USRP-users] uhd_fft failure

[Saeid Hashemi via USRP-users]

I will follow your advice, but it's worth mentioning I simply did apt-get
gnuradio and should therefore have a compatible version of uhd installed
automatically as a dependency. I did not install uhd separately.


On Fri, Oct 11, 2019 at 9:27 AM Michael Dickens 
wrote:

> Hi Saeid - The error shows that the version of UHD as installed isn't
> fully compatible with the version of GR. GR 3.7.9.1 is quite old  ...
> unless you need that specific version of GR, I'd recommend uninstalling
> that GR and installing 3.7.14.5 from source. There are install guides
> around for doing this build on Ubuntu of various versions. Hope this is
> useful! - MLD
>
> On Thu, Oct 10, 2019 at 6:40 PM Saeid Hashemi via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> Hello everyone,
>>
>> I've been having some problems running the uhd_fft function recently. I
>> did a fresh install of Ubuntu 16.04, then installed gnuradio using the
>> package manager. When I run uhd_fft this is what I get. Would anyone have
>> an idea as to where the problem is?
>>
>> Thanks,
>> Saeid
>>
>> nuc03@nuc03:~$ apt-show-versions gnuradio
>> gnuradio:amd64/xenial 3.7.9.1-2ubuntu1 uptodate
>>
>>
>> nuc03@nuc03:~$ uhd_fft
>> Traceback (most recent call last):
>>   File "/usr/bin/uhd_fft", line 48, in 
>> from gnuradio import uhd
>>   File "/usr/lib/python2.7/dist-packages/gnuradio/uhd/__init__.py", line
>> 135, in 
>> _prepare_uhd_swig()
>>   File "/usr/lib/python2.7/dist-packages/gnuradio/uhd/__init__.py", line
>> 38, in _prepare_uhd_swig
>> import uhd_swig
>>   File "/usr/lib/python2.7/dist-packages/gnuradio/uhd/uhd_swig.py", line
>> 28, in 
>> _uhd_swig = swig_import_helper()
>>   File "/usr/lib/python2.7/dist-packages/gnuradio/uhd/uhd_swig.py", line
>> 24, in swig_import_helper
>> _mod = imp.load_module('_uhd_swig', fp, pathname, description)
>> ImportError: /usr/lib/python2.7/dist-packages/gnuradio/uhd/_
>> uhd_swig.x86_64-linux-gnu.so: undefined symbol:
>> _ZN3uhd11time_spec_t15get_system_timeEv
>>
>> ___
>> USRP-users mailing list
>> USRP-users@lists.ettus.com
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>
>
> --
> Michael Dickens
> Ettus Research Technical Support
> Email: supp...@ettus.com
> Web: https://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] Issues Completing Radio Build and Installation

[Jonathan Lockhart via USRP-users]

Greetings Nate,

Thanks for getting back to me so quickly. I will be sure to flash the OS to
release 4 and roll back my dev environment to match the instructions.

Regards,
Jon Lockhart


On Fri, Oct 11, 2019, 1:20 PM Nate Temple  wrote:

> Hi Jon,
>
> If you are following this app note [0], I would recommend starting with
> the release-4 image. The pre-3.15 MPM based image that has been released is
> currently a "beta" release. It lacks several of the dependencies required
> to build out GNU Radio. We are working on a new release and hope to have it
> posted soon.
>
> [0] -
> https://kb.ettus.com/Software_Development_on_the_E3xx_USRP_-_Building_RFNoC_UHD_/_GNU_Radio_/_gr-ettus_from_Source
>
>
> Regards,
> Nate Temple
>
> On Fri, Oct 11, 2019 at 10:14 AM Jonathan Lockhart 
> wrote:
>
>> Greetings Ettus Radio List,
>>
>> I have recently acquired and began using an Ettus E312 and have been
>> trying to configure the dev host and the cross compile environment.
>> Unfortunately I am having issues completing some of these tasks with the
>> pre-release version of 3.15 image that Ettus mentions you should use in the
>> manual for the E312. I forward those issues to support but have heard no
>> reply. Please refer below to the issues I am reporting. The GNURadio cross
>> compile issue with the SDK and environment is the more crucial one at the
>> moment. I was wondering if anyone else has been experiencing these issues
>> and if so how did you proceed to get it resolved. Is there an image, sdk,
>> GNURadio version that I should be using other than the 3.15 image and
>> instructions that Ettus currently recommends using until a stable RC is
>> provided?
>>
>> Thanks for your help and feedback.
>>
>> Regards,
>> Jon Lockhart
>>
>>
>> -- Forwarded message -
>> From: Jonathan Lockhart 
>> Date: Mon, Oct 7, 2019 at 3:16 PM
>> Subject: Issues Completing Radio Build and Installation
>> To: 
>>
>>
>> Greetings Ettus Support,
>>
>> I recently acquired an Ettus E312 and I was looking to do some
>> development on it. Unfortunately I am have been having some issues. The
>> manual via files.ettus.com and the "Getting Started" both failed to
>> provide a working environment.
>>
>> The farthest I got was downloading the meta section direction for the
>> E312 to get 3.15.0 image and sdk for the radio, and then following this
>> guide page for 3.14, correcting the UHD install accordingly to comply with
>> 3.15. (Guide
>> https://kb.ettus.com/Software_Development_on_the_E3xx_USRP_-_Building_RFNoC_UHD_/_GNU_Radio_/_gr-ettus_from_Source#Running_RFNoC_Fosphor
>> )
>>
>> When mounting the cross compiled UHD folders via the instructions on the
>> radio, and using the uhd_usrp_probe command, there is an error checking for
>> the libusb_init information.
>>
>> root@ni-e31x-313179A:~/newinstall# uhd_usrp_probe
>> [INFO] [UHD] linux; GNU C++ version 7.3.0; Boost_106600;
>> UHD_3.15.0.HEAD-0-g6563c537
>> [ERROR] [UHD] Device discovery error: AssertionError:
>> libusb_init(&_context) == 0
>>   in libusb_session_impl::libusb_session_impl()
>>   at /home/jon/rfnoc/src/uhd/host/lib/transport/libusb1_base.cpp:36
>>
>> [ERROR] [UHD] Device discovery error: AssertionError:
>> libusb_init(&_context) == 0
>>   in libusb_session_impl::libusb_session_impl()
>>   at /home/jon/rfnoc/src/uhd/host/lib/transport/libusb1_base.cpp:36
>>
>> [ERROR] [UHD] Device discovery error: AssertionError:
>> libusb_init(&_context) == 0
>>   in libusb_session_impl::libusb_session_impl()
>>   at /home/jon/rfnoc/src/uhd/host/lib/transport/libusb1_base.cpp:36
>>
>> [INFO] [MPMD] Initializing 1 device(s) in parallel with args:
>> mgmt_addr=127.0.0.1,type=e3xx,product=e310_sg3,serial=313179A,claimed=False
>> [INFO] [MPM.PeriphManager] Found 1 daughterboard(s).
>> [INFO] [MPM.PeriphManager] init() called with device args
>> `product=e310_sg3,mgmt_addr=127.0.0.1'.
>> [INFO] [0/Radio_0] Initializing block control (NOC ID: 0x12AD10003310)
>> [INFO] [0/DDC_0] Initializing block control (NOC ID: 0xDDC0)
>> [INFO] [0/DUC_0] Initializing block control (NOC ID: 0xD0C2)
>> [INFO] [0/Radio_0] RX freq = 2.4e+09
>> [INFO] [0/Radio_0] RX band = 6
>> [INFO] [0/Radio_0] RX SW1 = 5
>> [INFO] [0/Radio_0] RX SWC = 0
>> [INFO] [0/Radio_0] RX SWB = 1
>> [INFO] [0/Radio_0] RX VCRX_SW = 1
>> [INFO] [0/Radio_0] RX VCTXRX_SW = 0
>> [INFO] [0/Radio_0] RX freq = 2.4e+09
>> [INFO] [0/Radio_0] RX band = 6
>> [INFO] [0/Radio_0] RX SW1 = 5
>> [INFO] [0/Radio_0] RX SWC = 0
>> [INFO] [0/Radio_0] RX SWB = 1
>> [INFO] [0/Radio_0] RX VCRX_SW = 1
>> [INFO] [0/Radio_0] RX VCTXRX_SW = 0
>> [INFO] [0/Radio_0] RX freq = 2.4e+09
>> [INFO] [0/Radio_0] RX band = 6
>> [INFO] [0/Radio_0] RX SW1 = 5
>> [INFO] [0/Radio_0] RX SWC = 0
>> [INFO] [0/Radio_0] RX SWB = 1
>> [INFO] [0/Radio_0] RX VCRX_SW = 1
>> [INFO] [0/Radio_0] RX VCTXRX_SW = 0
>> [INFO] [0/Radio_0] RX freq = 2.4e+09
>> [INFO] [0/Radio_0] RX band = 6
>> [INFO] [0/Radio_0] RX SW1 = 5
>> [INFO] [0/Radio_0] RX SWC = 0
>> [

Re: [USRP-users] uhd_fft failure

[Michael Dickens via USRP-users]

Hi Saeid - Thanks for the followup. I totally agree that if you just "sudo
apt install gnuradio", compatible versions should be installed. Are you
using Ubuntu 16.04.6 LTS (Xenial Xerus)? If you choose to install from
source, you can follow instructions such as the GR recommended way here <
https://wiki.gnuradio.org/index.php/UbuntuInstall#Xenial_Xerus_.2816.04.29
>. I have an Ubuntu 18.04 install that went very smoothly using this guide,
but maybe the guide is outdated for older Ubuntu; or, our packages need to
be updated for that OS version ... Cheers! - MLD

On Fri, Oct 11, 2019 at 2:24 PM Saeid Hashemi  wrote:

> I will follow your advice, but it's worth mentioning I simply did apt-get
> gnuradio and should therefore have a compatible version of uhd installed
> automatically as a dependency. I did not install uhd separately.
>
-- 
Michael Dickens
Ettus Research Technical Support
Email: supp...@ettus.com
Web: https://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] Fwd: Error handling D when reading data USRP N 210

[Sam Reiter via USRP-users]

Ivan,

Thanks for sending that along. From a software perspective, what parameters
do you input to your attached code to run it? I'm trying to understand the
data rates you're trying to sustain over the NIC you have. I've been
combing through this past USRP-users thread for some additional insight:

http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2014-May/037495.html

Based on some of those suggestions, it might be wise to try finding another
NIC to bring into the equation.

Sam

On Wed, Oct 9, 2019 at 2:14 PM Ivan Zahartchuk via USRP-users <
usrp-users@lists.ettus.com> wrote:

>
>
> -- Forwarded message -
> От: Ivan Zahartchuk 
> Date: ср, 9 окт. 2019 г. в 06:05
> Subject: Re: [USRP-users] Error handling D when reading data USRP N 210
> To: Sam Reiter 
>
>
> CPU intel core i7 -3610QE 2.3 GGz
> RAM 16 Gb
>  2 NIC intel 82574L gigabit ethernet and intel 82574LM gigabit ethernet
>
>
> вт, 8 окт. 2019 г. в 16:59, Sam Reiter :
>
>> What hardware are you using on the host side? Specifically, I'm
>> interested in CPU, RAM, and NIC.
>>
>> Sam Reiter
>>
>> On Tue, Oct 8, 2019 at 6:22 AM Ivan Zahartchuk via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>>> Hello. When I read data from the board, error D periodically passes. It
>>> leads to bursts in the spectrum that fits in the figure. Please tell me
>>> how you can remove this error or how it can be handled? I also attach
>>> the code file.
>>> [image: errorD.png]
>>> ___
>>> 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] uhd_fft failure

[Saeid Hashemi via USRP-users]

It's Ubuntu 16.04.1, but yes, I will follow the source build instructions.

On Fri, Oct 11, 2019 at 3:11 PM Michael Dickens 
wrote:

> Hi Saeid - Thanks for the followup. I totally agree that if you just "sudo
> apt install gnuradio", compatible versions should be installed. Are you
> using Ubuntu 16.04.6 LTS (Xenial Xerus)? If you choose to install from
> source, you can follow instructions such as the GR recommended way here <
> https://wiki.gnuradio.org/index.php/UbuntuInstall#Xenial_Xerus_.2816.04.29
> >. I have an Ubuntu 18.04 install that went very smoothly using this guide,
> but maybe the guide is outdated for older Ubuntu; or, our packages need to
> be updated for that OS version ... Cheers! - MLD
>
> On Fri, Oct 11, 2019 at 2:24 PM Saeid Hashemi  wrote:
>
>> I will follow your advice, but it's worth mentioning I simply did apt-get
>> gnuradio and should therefore have a compatible version of uhd installed
>> automatically as a dependency. I did not install uhd separately.
>>
> --
> Michael Dickens
> Ettus Research Technical Support
> Email: supp...@ettus.com
> Web: https://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] Some questions regarding DDC implementation

[Martin Braun via USRP-users]

Half-Bands are very flat in the passband, and somewhat efficient to
implement because every second tap is zero. The CIC on the other hand, is
super efficient, but has a horrible frequency response.

So, you want to use the half-bands for decimation whenever possible. You
will have fewer aliases, the spectrum looks nicer, etc.

More halfbands is always better. But two halfbands was chosen because on
the N210, it's a good compromise between available resources and spectral
improvements. Also, keep in mind that you can only stack halfbands as long
as your decimation is a multiple of two. If your decimation is 6 (= 2 * 3),
then you can only use one halfband, and set the CIC to 3. In other words,
adding another halfband only enables rates where the decimation rate is a
multiple of 8, and so on.

Next, why are they different. That was another compromise. More taps are
always better, so why not use the bigger one twice? That's because when
cascading the halfbands, the fidelity of the second filter reduces the
requirement for a super-good first filter. If you draw this on a piece of
paper, it's more obvious, but here's an attempt at writing it as text:
Fewer taps in a halfband mean the transition band (from passband to stop
band) is wider, which makes the flat passband smaller. However, because the
second half-band will further reduce the total available bandwidth, you
don't need a super sharp transition zone.

Finally, what does the multiplier do. In software, we calculate a total
gain of our DSP chain, based on the CIC settings and some other numbers we
have figured out. For example, the CORDIC has an almost constant, non-zero
gain. and the CIC decimator has a non-constant gain which is a function of
the decimation (all of this because we're doing fixpoint math). We try and
negate this as much as possible by multiplying the output with a
compensation factor.

-- M

On Fri, Oct 11, 2019 at 10:57 AM Francesco Restuccia via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Dear all,
> I have some questions regarding the DDC implementation (ddc_chain.v,
> usrp2):
>
> 1) Why do we need two half-band filters (one large and one small) after
> the CIC? What is their purpose? Can’t we use just one half-band?
> 2) What is the purpose of the scale factor multiplication after hb2? What
> does it compensate for? How do we decide its value?
>
> Thanks,
> Francesco
> ___
> 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] B200 FPGA development.

[Martin Braun via USRP-users]

No, you can do FPGA dev on the B200 series. However, you can't do RFNoC on
the B200 series. The manual has a few comments on it:
http://files.ettus.com/manual/page_usrp_b200.html#b200_customfpga

We expose a register interface (meaning you might not also have to modify
UHD), and there's a scratch space in the Verilog where you can drop your
designs into.

-- M

On Wed, Oct 9, 2019 at 8:10 AM J Subash via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi guys,
>
> I am looking to incorporate a channel equaliser and channel fader in the
> DUC and DDC chain inside a B200. I can't find examples of this sort on
> the Ettus KB. Is FPGA development confined to the X series and N series
> devices?
>
> Thanks very much.
>
> BW
>
> JS
>
>
> ___
> 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 / Vivado Build Failure

[Martin Braun via USRP-users]

Is this with vanilla code, or your own custom code?

On Thu, Sep 26, 2019 at 5:49 PM Jeff S via USRP-users <
usrp-users@lists.ettus.com> wrote:

> I'm trying to take what I learned from GRCon2019 from Neel and company's
> workshop, and I'm trying to perform the uhd_image_builder_gui.py script. It
> fails with a message similar to:
>
> [00:12:22] Starting DRC Task
> ERROR: [DRC MDRV-1] Multiple Driver Nets: Net bus_clk_gen/inst/CLK_OUT4 has 
> multiple drivers: radio_clk_gen/inst/clkout1_buf/O, and bus_clk_gen/  
>inst/clkout4_buf/O.
> ERROR: [DRC MDRV-1] Multiple Driver Nets: Net 
> radio_reset_sync/reset_double_sync/synchronizer_false_path/value[9]_9 has 
> multiple drivers: ce_res 
> et_sync/reset_double_sync/synchronizer_false_path/stages[9].value_reg[9][0]/Q,
>  and radio_reset_sync/reset_double_sync/synchronizer_false_path/st
>  ages[9].value_reg[9][0]/Q.
> ERROR: [Vivado_Tcl 4-78] Error(s) found during DRC. Opt_design not run.
>
>
> I have to finish the paperwork to get the real log out of my lab so I can
> post it, but it looked pretty much the same as the log in the unanswered
> archived message at:
>
>
> http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2019-August/060443.html
>
>
> and I wanted to try and get a jumpstart on the issue.
>
> I have an X310
> Vivado 2018.3
>
> Jeff
>
> ___
> 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] Fwd: Error handling D when reading data USRP N 210

[Marcus D. Leech via USRP-users]

On 10/11/2019 04:28 PM, Sam Reiter via USRP-users wrote:

Ivan,

Thanks for sending that along. From a software perspective, what 
parameters do you input to your attached code to run it? I'm trying to 
understand the data rates you're trying to sustain over the NIC you 
have. I've been combing through this past USRP-users thread for some 
additional insight:


http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2014-May/037495.html

Based on some of those suggestions, it might be wise to try finding 
another NIC to bring into the equation.


Sam

Indeed, I just noticed the 82574L/LM referenced in the original complaint.

Those types of NICs have issues that cause packet loss--there have been 
a few "workarounds" over the years in various kernels, but none of
  them actually 100% fix the underlying issue with those chips--they're 
basically broken.   You don't notice this with web-browsing and

  other TCP-based protocols, because those protocols do error recovery.






On Wed, Oct 9, 2019 at 2:14 PM Ivan Zahartchuk via USRP-users 
mailto:usrp-users@lists.ettus.com>> wrote:




-- Forwarded message -
От: *Ivan Zahartchuk* mailto:adray0...@gmail.com>>
Date: ср, 9 окт. 2019 г. в 06:05
Subject: Re: [USRP-users] Error handling D when reading data USRP
N 210
To: Sam Reiter mailto:sam.rei...@ettus.com>>


CPU intel core i7 -3610QE 2.3 GGz
RAM 16 Gb
 2 NIC intel 82574L gigabit ethernet and intel 82574LM gigabit
ethernet


вт, 8 окт. 2019 г. в 16:59, Sam Reiter mailto:sam.rei...@ettus.com>>:

What hardware are you using on the host side? Specifically,
I'm interested in CPU, RAM, and NIC.

Sam Reiter

On Tue, Oct 8, 2019 at 6:22 AM Ivan Zahartchuk via USRP-users
mailto:usrp-users@lists.ettus.com>> wrote:

Hello. When I read data from the board, error D
periodically passes. It leads to bursts in the spectrum
that fits in the figure. Please tell me how you can remove
this error or how it can be handled? I also attach the
code file.
errorD.png
___
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