Re: [USRP-users] problem to work witth source file and RFnoC block and FIR block

> I want to use this block with 1,000 coefficients, but when I tried to do so > I saw that the maximum possible is only 41 coefficients. > > Does anybody know if Ettus has any solution to use FIR with 1,000 > coefficients? The number of taps is an adjustable parameter in the FIR filter block's

Re: [USRP-users] [UHD] 3.11.0.0 Release Announcement

Hi Martin, Thanks for looking into it. Meanwhile I collected more information and it does get weirder. I'm attaching a basic C++ program that does nothing useful, it just RX streams until CTRL+C kills it. Compiling instructions for Linux are in the first lines of the code. On Ubuntu 18.04,

Re: [USRP-users] Running neural network ex_1layer example on x310

Well, looks like I've been called out... Sorry Francesco: Unfortunately, I have not had a chance to 1) test the examples on an x310 (I used E310 during development) or 2) update to recent rfnoc-devel releases past GRCon 2017. Usually "timeouts" in SW are not (by themselves) an indicator of an

Re: [USRP-users] Synchronisation of 2 X310s with TwinRXs

On 03/06/2018 02:03 AM, Goh Liang Zhen via USRP-users wrote: > Dear fellow users, > >   > > I intend to put together a 8 channel data collection system using 2 > X310s, each mounted with 2 TwinRXs.  With the guidance from the past > experience in this forum, I have installed the hardware and

Re: [USRP-users] [UHD] 3.11.0.0 Release Announcement

On 03/21/2018 10:12 PM, Dario Fertonani wrote: > No comments on this? It's a major bug introduced in the new release, in > my opinion. > > Anybody can replicate it by running the official test file linked below, > when compiled with UHD 3.11 from Ubuntu PPA. > >

Re: [USRP-users] USRP B210 FPGA Build

On 04/09/2018 02:24 AM, Yeo Jin Kuang Alvin (IA) via USRP-users wrote: > Hi everyone, > >   > > I tried to build the USRP B210 FPGA for Xilinx ISE 14.7 (Windows) and I > got this in my cmd prompt: > >   > > C:\Users\WORK\Desktop\fpga-maint\usrp3\top\b200>make B210 PROJECT_ONLY=1 > > "ISE

Re: [USRP-users] Spectrum Scanning Problems USRP B200

On 04/04/2018 02:27 AM, Ivan Zahartchuk via USRP-users wrote: > > ​Hello. I use B200 to scan the spectrum in a certain band. I have two > problems. > 1) the last part of the collection of the spectrum becomes the > beginning. Fig. 1 > 2) the switching time from frequency to frequency is

Re: [USRP-users] Question about uhd_cal_tx_dc_offset

On 04/11/2018 07:05 PM, Marcus D. Leech via USRP-users wrote: >> Q: Do you have a rough idea of how long the calibration is good for (a >> few days vs a few months)? > I'm not sure that anyone has ever asked that question before.  Certainly > component-aging plays some role in shifting I/Q and

Re: [USRP-users] RFNoC with 2xMIMO

On 04/15/2018 06:20 PM, Miklos Maroti via USRP-users wrote: > Dear All, > > I am new to RFNoC development, and hope some of you can give some > insight. I was looking the fpga-src repository, and reading RFNoC docs > online. Reading the source code I see that m_axis_data_tdata and >

Re: [USRP-users] USRP B210 API & FPGA

On 04/16/2018 01:54 AM, Yeo Jin Kuang Alvin (IA) via USRP-users wrote: > Hi all, > >   > > I have two questions regarding the USRP B210 configurations using API > and FPGA at the same time. For the archive: this was addressed in various other threads. -- M

Re: [USRP-users] [RFNOC] Schimdl & Cox off-the-shelf block fails timing constraints on X310

On 04/16/2018 09:52 AM, Francesco Restuccia via USRP-users wrote: > Hi all, > > I am trying to add the schmidlcox, fft and and eq to my X310. > > Looks like the S block does not meet timing constraints. This is the > report from Vivado. > > Any help would be much appreciated, thank you... Have

Re: [USRP-users] problem to work witth source file and RFnoC block and FIR block

On 04/17/2018 06:01 AM, Allouche Ishai via USRP-users wrote: > Hi all, > >   > > I am working on a USRP X310 with a source file block and I have some issues. > >   > > My setup is : > >   > > Source File -> Throttle -> RFNoC: Window -> RFNoC: FIFO -> Copy -> > Vector to Stream -> File Sink.

Re: [USRP-users] Updated rfnoc-devel Branches

On 04/04/2018 06:41 AM, Brian Padalino via USRP-users wrote: > I tried re-building the FPGA and host code for rfnoc-devel last night, > and I received an error about a major compat number being too low in UHD > for the DDC.  I linked it to > commit d588005fd87dd2594adb29dbbdcf948bbb0ab0c1, cherry

Re: [USRP-users] customize processing of U and L messages

On 04/03/2018 01:23 AM, Nicolas Cuervo via USRP-users wrote: > Hello Cedric, > > This information is listed in the manual for error/problem > troubleshooting) [1] > > The "D" is a dropped packet on reception, and shows up as an indication > of a sequence error caused by an overflow on networked

Re: [USRP-users] UHD rfnoc-devel version

On 04/06/2018 09:23 AM, Mark Luscombe via USRP-users wrote: > Hi, > >   > > The rfnoc-devel branch has now been updated to include fixes and > requires Vivado 2017.4. I’ve always created the development environment > with PyBOMBS and it seems as though this always pulls the latest version > of

Re: [USRP-users] big uhd.log

On 04/11/2018 12:48 AM, Matis Alun via USRP-users wrote: >> How did you install UHD? >> >> -- M > I installed UHD using make install from a fresh download and compilation.(UHD > 3.010.003) Ah, you're on 3.10. That's a different story. I checked the code, and you're correct that there's no way to

Re: [USRP-users] Updated BSP for e3xx

On 04/16/2018 09:25 PM, Kurt Kiefer via USRP-users wrote: > The last release of the BSP and firmware for e3xx devices is either back at > fido, which was over two years ago, or jethro a year ago (though it's still > listed as "beta" on files.ettus.com). This age makes it increasingly >

Re: [USRP-users] BRAM usage of the X300/X310 design

On 04/19/2018 07:35 AM, Nives Novković via USRP-users wrote: > I can see by the official numbers that the default Ettus FPGA design on > X310 takes about 50% BRAM and on X300 about 90%. I would like to make my > own design for Ettus but use only ADC and Ethernet cores from the > default design.

Re: [USRP-users] E310 default build of uhd-fpga/rfnoc-devel placer fails

EJ is correct, and we've applied his patch that reduces the usage. However, we've discovered a separate issue on current rfnoc-devel, which we're currently investigating, and recommend everyone to simply locally edit the local version of rfnoc_ce_auto_inst. Thanks, Martin On 04/19/2018 08:07

Re: [USRP-users] Problem using RFNoC to make an X310 HG build with Vivado HLS after successfully making XG builds

On 04/19/2018 01:28 PM, John McGinn via USRP-users wrote: > I’m a relative newbie with rfnoc to build X310 loads so I may have > missed something, but if so, I can’t find what it is. > >   > > After successfully making many HG builds (one 1GbE link, one 10GbE > link),  I reached a point where I

[USRP-users] SDX 18.1.6 - RC3

Salut, Voici SDX 18.1.6 RC3: Ubuntu: skydel-sdx-18.1.6-7aaee92-RC3.deb Windows: (sera prêt dans 20 minutes) À mon avis, tout est prêt dans ce build pour la relâche. Voici les derniers "sanity" tests que j'aimerais qu'on fasse:

Re: [USRP-users] Suppressing output at runtime

> I think it's clear now that the current state of UHD doesn't include all > the features that you want, so I think we can close out this thread. Or put it another way. Before this reply, it was never mentioned or confirmed that what I want was impossible with 3.11 so I thought the methods you

[USRP-users] Problem using RFNoC to make an X310 HG build with Vivado HLS after successfully making XG builds

Hello sir. I'm a relative newbie with rfnoc to build X310 loads so I may have missed something, but if so, I can't find what it is. After successfully making many HG builds (one 1GbE link, one 10GbE link), I reached a point where I needed higher X310 to host bandwidth so switched to making

Re: [USRP-users] Suppressing output at runtime

> I think it's clear now that the current state of UHD doesn't include all > the features that you want, so I think we can close out this thread. > For the record, it is perfectly reasonable to ask for additional > features here, and a runtime-disabling of the fastpath messages is not > something

Re: [USRP-users] Suppressing output at runtime

On 04/19/2018 10:59 AM, Yichao Yu wrote: > Ah, and I finally find that email I was referring to again, > > http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2017-April/024653.html > > which mentioned that > >> - Main reason for customers registering custom message handlers was to >>

Re: [USRP-users] RuntimeError: Firmware and FPGA image update

Hello Kazem, Have you run the step by step commands which are printed in the error? If they did not work, can you please share the errors from running them? Also, though those are the correct commands, here is the manual page for reference.

Re: [USRP-users] DC Offset Calibration Issue for Rev. C UBX-40 daughter cards

While uncalibrated LO leakage has never been great in the UBX for us, the dc offset calibration procedure has given us adequate enough improvement. We’re generally using offset tuning, but we still need that extra 15-20 dB suppression we get from the calibration procedure. The issue we’re

Re: [USRP-users] Suppressing output at runtime

>>> And as Marcus says, fastpath also goes to stderr, so you can direct it >>> /dev/null. >> >> That's like throw the baby out with the bath water The application >> is also using `stderr` for useful output. > > You can register your own handlers if you want to filter log messages > based

Re: [USRP-users] Suppressing output at runtime

On Thu, Apr 19, 2018 at 1:53 PM, Yichao Yu wrote: > On Thu, Apr 19, 2018 at 1:42 PM, Martin Braun via USRP-users > wrote: >> On 04/19/2018 10:39 AM, Marcus D. Leech via USRP-users wrote: >>> On 04/19/2018 01:37 PM, Yichao Yu wrote: The page

Re: [USRP-users] Suppressing output at runtime

On 04/19/2018 10:53 AM, Yichao Yu wrote: > On Thu, Apr 19, 2018 at 1:42 PM, Martin Braun via USRP-users > wrote: >> On 04/19/2018 10:39 AM, Marcus D. Leech via USRP-users wrote: >>> On 04/19/2018 01:37 PM, Yichao Yu wrote: The page still doesn't mention fastpath

Re: [USRP-users] Suppressing output at runtime

On Thu, Apr 19, 2018 at 1:42 PM, Martin Braun via USRP-users wrote: > On 04/19/2018 10:39 AM, Marcus D. Leech via USRP-users wrote: >> On 04/19/2018 01:37 PM, Yichao Yu wrote: >>> The page still doesn't mention fastpath message though and I though >>> there was a

Re: [USRP-users] DC Offset Calibration Issue for Rev. C UBX-40 daughter cards

Hi John, LO Leakage in general has ALWAYS been a problem for us as well in general on the UBX. The WBX was fine, we migrated to the UBX quite early and had significant problems that really were never resolved. Most of the chatter revolved around being continuously in high power mode, but

Re: [USRP-users] Suppressing output at runtime

On 04/19/2018 10:39 AM, Marcus D. Leech via USRP-users wrote: > On 04/19/2018 01:37 PM, Yichao Yu wrote: >> The page still doesn't mention fastpath message though and I though >> there was a previous email on this list that mentions such control was >> possible when the new logging system was just

Re: [USRP-users] Suppressing output at runtime

>> The page still doesn't mention fastpath message though and I though there >> was a previous email on this list that mentions such control was possible >> when the new logging system was just implemented. > > Perhaps Martin can say a word or two about how that is handled in the new > logging

Re: [USRP-users] Suppressing output at runtime

On 04/19/2018 01:37 PM, Yichao Yu wrote: The page still doesn't mention fastpath message though and I though there was a previous email on this list that mentions such control was possible when the new logging system was just implemented. Perhaps Martin can say a word or two about how that is

Re: [USRP-users] Suppressing output at runtime

> Well, as of 3.11 at least, the library version header is an INFO message, > and can be dealt with as outlined in the linked document. Ah, you are right! Just checked that the initializetion message is going through my handler on 3.11 now. I think I just noticed that the fastpath message can't

Re: [USRP-users] Suppressing output at runtime

On 04/19/2018 01:24 PM, Yichao Yu wrote: http://files.ettus.com/manual/page_logging.html Has some info. No. Note that as I've already explained, the two kind of messages I'd like to suppress are Well, as of 3.11 at least, the library version header is an INFO message, and can be dealt with as

Re: [USRP-users] Host synchronization within a continuous stream

> I'm still a bit confused about the time synchronization being an issue > at all – even after a packet dropout, all packets coming from the X3xx > contain a timestamp, so you'd *never* have to call get_time_now (and it > won't do any good, for asynchronity reasons). Hmmm, maybe I failed to

Re: [USRP-users] Host synchronization within a continuous stream

Hi Yichao, Sorry, this is probably my fault. I apologize – I'm not quite sure how to help you most efficiently right now. I remember this being a relatively involved issue; just from reading your second-to-last email on this list, this becomes clear. I'm still a bit confused about the time

Re: [USRP-users] Suppressing output at runtime

> http://files.ettus.com/manual/page_logging.html > > Has some info. No. Note that as I've already explained, the two kind of messages I'd like to suppress are >> 1. The printing of the library version during initialization. This >> should really be disabled by default and should be controlled

Re: [USRP-users] Suppressing output at runtime

On 04/19/2018 12:56 PM, Yichao Yu via USRP-users wrote: Hi, As the title suggests, is there a way to suppress all the output from libuhd? They are extremely annoy and is messing up the normal output of the programs (and even libraries) that link to libuhd. The output that only seems to have a

[USRP-users] Suppressing output at runtime

Hi, As the title suggests, is there a way to suppress all the output from libuhd? They are extremely annoy and is messing up the normal output of the programs (and even libraries) that link to libuhd. The output that only seems to have a compile time switch includes, 1. The printing of the

Re: [USRP-users] Host synchronization within a continuous stream

Forwarding to the mailing list after getting no reply from ettus in 4 months!!! Sorry for the top post but it's increasingly clear that the ad-hoc method of resetting the device every now and then is giving us a lot of problems and it's getting worse with libuhd update. We really need to know how

Re: [USRP-users] Running neural network ex_1layer example on x310

Hello Francesco: We do not directly provide technical support for the RFNoC blocks created by the teams in the Vivado HLS Challenge from last year. The ex_1layer example is from HLS Neuralnet, and the repository is at the link below. https://github.com/Xilinx/RFNoC-HLS-NeuralNet If you have

Re: [USRP-users] NI-USRP driver support on Ubuntu 17.10

Hello Dmitry: We are currently working on adding support for newer kernels (newer than 4.2) to the NI-USRP driver for X300/X310 PCIe. We are planning to have this ready soon. I'll check the status, and post a follow-up message. Ubuntu 16.04.2 uses a 4.2 kernel. Ubuntu 16.04.3, 16.04.4, 16.10,

Re: [USRP-users] Spurious emissions using B200

Hi Carmine, Can you please post a plot showing the spurious emissions you're seeing? If possible, if you can include how you're generating the plots (the script) would be useful as well. What version of UHD are you using? What color is the PCB of your B200? What USRP are you using as a

Re: [USRP-users] E310 default build of uhd-fpga/rfnoc-devel placer fails

As a quick followup, it appears that resources requirements are just a tad too high for the instantiations defined in rfnoc_ce_auto_inst_e310.v. Editing the file to remove one of the two FIFOs builds successfully. EJ On Thu, Apr 19, 2018 at 10:19 AM, EJ Kreinar wrote: >

[USRP-users] BRAM usage of the X300/X310 design

Hi everyone, I can see by the official numbers that the default Ettus FPGA design on X310 takes about 50% BRAM and on X300 about 90%. I would like to make my own design for Ettus but use only ADC and Ethernet cores from the default design. Does anybody know how much BRAM blocks would only those 2

[USRP-users] E310 default build of uhd-fpga/rfnoc-devel placer fails

Hi all, I've recently checked out the rfnoc-devel branch of uhd-fpga (which is now set to use Vivado 2017.4), SHA1 9c8c2ba... A default build from scratch (make E310_RFNOC_sg3) seems to fail to place all resources. Here's the tail of my console output: [00:13:03] Current task: Placer +++

Re: [USRP-users] Getting started with FPGA and RFNoC developement

On Thu, Apr 19, 2018 at 2:48 AM TIMMEN Koen < koen.tim...@thalesaleniaspace.com> wrote: > Nick, > > > > Since you replied to my previous questions regarding working with RFNoC, I > would like to address some follow up questions to you if you don’t mind. I > am still working on the same subject

Re: [USRP-users] USRP: AD9361

Hi, I'll admit, I do not know how to answer these specific questions because they're pretty far outside the typical use case of the b200 device. However, Nick Foster and others have already responded to similar questions about your application. Please explain your results when you followed their

[USRP-users] RuntimeError: Firmware and FPGA image update

Good day dear Sir, I am a new user of Ubuntu and USRP. I'm trying to connect my PC to USRP N200, but I have encountered the error below. I have installed  and uninstalled my GNU radio and UHD several times, but what I get is still the latest version in which is not compatible with my FPGA. I