[USRP-users] Building UHD installer
In Windows I am attempting to create an installer for a custom built UHD. UHD works as it should, however the PACKAGE target does not finish. I get the following error. This seems to be a common error when specifying an absolute path rather than a relative path. Is there a way around this? 85>-- Build started: Project: PACKAGE, Configuration: Release x64 -- 85>CPack: Create package using NSIS 85>CPack: Install projects 85>CPack: - Install project: UHD 85>CPack: - Install component: libraries 85>CPack: - Install component: pythonapi 85>CMake Error at C:/martin/uhd_stack_build/uhd_build/python/cmake_install.cmake:42 (message): 85> ABSOLUTE path INSTALL DESTINATION forbidden (by caller): C:/Program 85> Files/UHD/Lib/site-packages/uhd 85>Call Stack (most recent call first): 85> C:/martin/uhd_stack_build/uhd_build/cmake_install.cmake:73 (include) 85> 85> 85>EXEC : CPack error : Error when generating package: UHD -- Martin K. ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
[USRP-users] E310 environment
I am trying to follow the instructions at https://files.ettus.com/manual/page_usrp_e3x0.html I have a fresh installation of Ubuntu (either 16.04 or 18.04) When I get to the point of setting up the cross compilation environment, I get a fatal error. This is some sort of Python issue, for which I am not a Python developer, I have no idea what I should be doing to fix this. My goal is to compile my custom C++ code against UHD for the E310. If there is a better solution please let me know. Thank you. $ . e3xx/environment-setup-armv7ahf-vfp-neon-oe-linux-gnueabi $ CC Fatal Python error: Py_Initialize: Unable to get the locale encoding ModuleNotFoundError: No module named 'encodings' Current thread 0x7f05861ce740 (most recent call first): Aborted (core dumped) -- Martin K. ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] pybombs init error --> volk
Michael, thank you. That does help. Do you or anyone know if there is a version of Ubuntu or Debian [or any distro] that supports the default PyBombs installation out of the box? I don't have time to learn pybombs and debug the build. Thanks, Martin Klingensmith On Wed, Mar 27, 2019 at 2:56 PM Michael Dickens wrote: > > The version of Volk currently installed is too new for the version of GNU > Radio you're trying to build. I'm not 100% clear on how to install different > recipes in PyBOMBS, but if you can do so try a newer version of GNU Radio (if > you search the GIT logs for "volk_32f_8u_polarbutterfly_32f" you'll find the > commit to be at least a recent as). Hope this is useful! - MLD > > On Wed, Mar 27, 2019, at 12:36 PM, Martin K via USRP-users wrote: > > I am installing the e3xx-rfnoc pybombs recipe for Ettus E310 development. > > It gets as far as > > gr-fec/lib/CMakeFiles/gnuradio-fec.dir/polar_decoder_common.cc.o and > > fails (error follows below). The command I am running is: > > $ pybombs prefix init ~/e3xx -R e3xx-rfnoc > > > > The OS is Ubuntu 18.04LTS. The OS installation is new. > > Thank you for any help. > > > > /home/martin/e3xx/src/gnuradio/gr-fec/lib/polar_decoder_common.cc: In > > member function 'void > > gr::fec::code::polar_decoder_common::butterfly_volk(float*, unsigned > > char*, int, int, int)': > > /home/martin/e3xx/src/gnuradio/gr-fec/lib/polar_decoder_common.cc:126:95: > > error: too many arguments to function > > volk_32f_8u_polarbutterfly_32f(llrs, u, block_size(), > > block_power(), stage, u_num, row); > > > > ^ > > gr-fec/lib/CMakeFiles/gnuradio-fec.dir/build.make:1020: recipe for > > target 'gr-fec/lib/CMakeFiles/gnuradio-fec.dir/polar_decoder_common.cc.o' > > failed > > make[2]: *** > > [gr-fec/lib/CMakeFiles/gnuradio-fec.dir/polar_decoder_common.cc.o] > > Error 1 > > CMakeFiles/Makefile2:3846: recipe for target > > 'gr-fec/lib/CMakeFiles/gnuradio-fec.dir/all' failed > > make[1]: *** [gr-fec/lib/CMakeFiles/gnuradio-fec.dir/all] Error 2 > > Makefile:143: recipe for target 'all' failed > > make: *** [all] Error 2 > > [ERROR] Build failed. See output above for error messages. > > [ERROR] Problem occurred while building package gnuradio: > > Build failed. > > [ERROR] Error installing package gnuradio. Aborting. > > > > > > -- > > Martin K. > > > > ___ > > USRP-users mailing list > > USRP-users@lists.ettus.com > > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com > > -- Martin K. ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
[USRP-users] pybombs init error --> volk
I am installing the e3xx-rfnoc pybombs recipe for Ettus E310 development. It gets as far as gr-fec/lib/CMakeFiles/gnuradio-fec.dir/polar_decoder_common.cc.o and fails (error follows below). The command I am running is: $ pybombs prefix init ~/e3xx -R e3xx-rfnoc The OS is Ubuntu 18.04LTS. The OS installation is new. Thank you for any help. /home/martin/e3xx/src/gnuradio/gr-fec/lib/polar_decoder_common.cc: In member function 'void gr::fec::code::polar_decoder_common::butterfly_volk(float*, unsigned char*, int, int, int)': /home/martin/e3xx/src/gnuradio/gr-fec/lib/polar_decoder_common.cc:126:95: error: too many arguments to function volk_32f_8u_polarbutterfly_32f(llrs, u, block_size(), block_power(), stage, u_num, row); ^ gr-fec/lib/CMakeFiles/gnuradio-fec.dir/build.make:1020: recipe for target 'gr-fec/lib/CMakeFiles/gnuradio-fec.dir/polar_decoder_common.cc.o' failed make[2]: *** [gr-fec/lib/CMakeFiles/gnuradio-fec.dir/polar_decoder_common.cc.o] Error 1 CMakeFiles/Makefile2:3846: recipe for target 'gr-fec/lib/CMakeFiles/gnuradio-fec.dir/all' failed make[1]: *** [gr-fec/lib/CMakeFiles/gnuradio-fec.dir/all] Error 2 Makefile:143: recipe for target 'all' failed make: *** [all] Error 2 [ERROR] Build failed. See output above for error messages. [ERROR] Problem occurred while building package gnuradio: Build failed. [ERROR] Error installing package gnuradio. Aborting. -- Martin K. ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] Installing UHD package
Vinayak, I believe you want one of these files. You downloaded the source code for UHD. http://files.ettus.com/binaries/uhd/latest_release/Windows7/ On Tue, Mar 26, 2019 at 3:26 PM VINAYAK KARANDIKAR wrote: > > Hello Martin, > I am using Windows 10 OS, and i have downloaded the > file "uhd_3.12.0.0-release.tar.Z", which i have unzipped to retrieve so many > many many subfolders. So i am unable to follow what next i do, for the > purpose of installation of UHD. > Thanks a lot, > Vinayak Anant Karandikar > > On Tue, 26 Mar 2019 at 20:23, Martin K wrote: >> >> What operating system are you using? >> What is the name of the file you downloaded? >> >> On Tue, Mar 26, 2019 at 1:54 PM VINAYAK KARANDIKAR via USRP-users >> wrote: >> > >> > Hello, >> >following instructions at >> > "http://files.ettus.com/manual/page_install.html;, i have downloaded the >> > installer from " http://files.ettus.com/binaries/uhd/latest_release;. >> > >> > Now, when i unzip the package, i arrive at a folder named >> > "uhd_3.12.0-release". This folder has many many many sub folders and each >> > sub folders has many many many files within. >> > >> > So i am unable to follow what do i do? How do i install the UHD from here. >> > >> > I think i need step by step instructions. >> > >> > Thanks a lot, >> > Vinayak Anant karandikar >> > ___ >> > USRP-users mailing list >> > USRP-users@lists.ettus.com >> > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >> >> >> >> -- >> Martin K. -- Martin K. ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] Issues finding multiple USRP's connected to same host
Ali, What is your full command line for uhd_find_devices? - Martin Klingensmith On Mon, Jan 21, 2019 at 5:39 PM Ali Dormiani via USRP-users wrote: > > Hello everyone, > > I am having a strange (new) problem where my host machine can not detect more > than one USRP at a time. I recently re-installed everything to update all > devices to 3.13.1.0. > > Each of my N310's SFP+0 ports is configured as follows: > > MTU: 8000 > > Address: 192.168.5x/24 > > Where x is the device number I have assigned (1-9). > > What is bizarre is if two N310's are connected to the host, only one shows up > in uhd_find_devices. > > Each N310 connects fine on its own. Just plug and play. But attaching more > than one to the server breaks things. > > The server is manually configured with a different static ip for each SFP+ > port: > > 192.168.20.2y > > Where y is the port number (0-6). > > Everything (SD file system, host install, FPGA, ixgbe driver) is up to date. > I can do whatever I want if only one device is attached (SSH, UHD commands, > GNU radio, device_probe). > > > I'm not sure what to do about this as individually all of them work > perfectly. Any ideas? > > Thank you for your time, > > Ali > ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] regrading GPIO header connector in USRP-B200 mini
According to NI documentation the B200mini is not supported by LabView directly. You may be able to write HDL for the B200mini but it will be fully custom, as others have said. - Martin K On Thu, Jan 10, 2019 at 5:17 AM Maitry Raval via USRP-users wrote: > > Hello, > > sorry, I have just started to work with USRP-B200 mini and GNU radio, and I > have implemented channel coding/ decoding and modulation-demodulation for > continuous transmission/reception in GNU radio.and what i understand is when > I am doing all these dsp in GNU radio with host computer, it uses USRP-b200 > mini as a pass through by using UHD drivers(sink and source), and I can > transmit and receive through GNU radio. and I think, for embedded USRP with E > series can run these radio application(GNU) on board itself without the use > of host computer, which is not possible with USRP-B200 mini. and through > labview,it is possible to parses block diagram and converts the code to text > based VHDL if I done the same channel coding/decoding and mod-demod in > labview as per my application, > so my question is, Is it possible that USRP-B200 mini is labview supported or > I need to do it through direct VHDL-verilog? > > > > With Best Regards, > Maitry Raval, > ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] regrading GPIO header connector in USRP-B200 mini
Maitry, The B200mini cannot run a GNURadio application by itself. It will always require a separate computer to control it. -- Martin K. On Wed, Jan 9, 2019 at 7:01 AM Maitry Raval wrote: > > Hello, > > Thanks for your quick response! > Actually, I have GNU radio flow graph as per my application which runs > through UHD USRP sink and UHD USRP source to USRP B200 mini hardware, right. > But now as you said we can use USB to serial converter for transmitting data > from outside source. but for that, I need to dump the GNU radio flow graph > into FPGA right?(that means I have to run GNU radio application on board > itself without the use of host computer) > So, Can you please guide me on the following > (1) How can I run GNU radio flow graph on USRP B200 mini itself(without the > use of host computer) or I have to dump the python code that GNU radio > generates? > > thanks for your support in advance. > > With Best Regards, > Maitry Raval, > > > - Original Message - > From: "Martin K" > To: "Maitry Raval" > Cc: "usrp-users" > Sent: Tuesday, January 8, 2019 6:09:39 PM > Subject: Re: [USRP-users] regrading GPIO header connector in USRP-B200 mini > > Maitry, > I think this would require modifying the FPGA code. > You could expose the "user regs" to read/write to a serial peripheral > which you would have to add to the FPGA. This feature (the user i/o > regs) is only present in the newest version of UHD (3.14), so you will > have to build UHD from the master branch as well as rebuild the FPGA. > > https://files.ettus.com/manual/md_usrp3_build_instructions.html > https://files.ettus.com/manual/page_usrp_b200.html#b200_customfpga > > However, if you merely need serial i/o, a much easier solution is to > use a USB to serial converter. You should think about ways to make > this work before modifying the FPGA. > > > -- > Martin K. > ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] regrading GPIO header connector in USRP-B200 mini
Maitry, I think this would require modifying the FPGA code. You could expose the "user regs" to read/write to a serial peripheral which you would have to add to the FPGA. This feature (the user i/o regs) is only present in the newest version of UHD (3.14), so you will have to build UHD from the master branch as well as rebuild the FPGA. https://files.ettus.com/manual/md_usrp3_build_instructions.html https://files.ettus.com/manual/page_usrp_b200.html#b200_customfpga However, if you merely need serial i/o, a much easier solution is to use a USB to serial converter. You should think about ways to make this work before modifying the FPGA. -- Martin K. On Tue, Jan 8, 2019 at 4:54 AM Maitry Raval via USRP-users wrote: > > Hello, > > Is it possible to give serial input through GPIO connector to USRP-B200 mini? > Please provide some guidance, As I want to provide serial input(continous) > from outside to USRP and all other digital processing from GNU radio flow > graph, so for that, I need to have one GRC block(may be sink block) that can > take the serial data from outside serial input device, right? > > > > With Best Regards, > Maitry Raval, > > ___ > 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] UHD 3.13 Visual Studio build question
Hello all, I am attempting to build the latest 3.13 branch. I am encountering an error. It seems simple if I knew where to look: 7>Generating build/timestamp 7>CUSTOMBUILD : error : package directory 'C:martin\uhd_stack_build\uhd_build\python\uhd' does not exist 7>Done building project "pyuhd_library.vcxproj" -- FAILED. As you can see, there appears to be a typo in the CUSTOMBUILD step for this target. (there is a missing backslash, C:\martin...) The directory exists. However, I have checked the .vcproj but I can't find where this error is being introduced. Do you know where I should look to fix this? This error has presented itself in the 3.13 release, as I was able to compile 3.13.0-rc_ without issue. Thanks for your help, Martin Klingensmith ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] Weird effects setting external clock source in a B200mini
Can the VCTCXO DAC be controlled via the UHD API?
I would rather manually calibrate on demand than see large jumps in frequency.
On Wed, Jan 2, 2019 at 5:16 PM Marcus D. Leech via USRP-users
wrote:
>
> On 01/02/2019 09:54 AM, Brais Ares via USRP-users wrote:
>
> Hello,
>
> We've just bought an AXIOM90 OCXO [1] (actual configuration: 5 V, ±50 ppb,
> +7.7 dBm) and we are having trouble configuring it as an external clock
> reference on a B200mini.
>
> All we do in code is set the clock source as external:
>
> usrp->set_clock_source("external");
>
> And loop until it gets locked by checking:
>
> uhd::sensor_value_t ref_locked = usrp->get_mboard_sensor("ref_locked", 0);
>
> Once it's locked we capture 60 seconds of a RF sinusoid waveform centered at
> the central frequency (100 MHz) and plot its spectrum using Matlab. We would
> expect:
>
> Frequency drift - Internal oscillator [2] @ ±2 ppm = ±200 Hz
>
> Captured tone shows a freq. offset of +126 Hz, makes sense (see image and
> image zoomed in)
>
> Frequency drift - External oscillator (Agilent E4438C Signal generator,
> output power: +10 dBm)
>
> Captured tone shows a freq. offset of -3 Hz, makes sense, but the tone is
> heavily distorted (see image and image zomeed in).
>
> Frequency drift - External oscillator (AXIOM90) @ ±50 ppb (0.05 ppm) =
> ±5.4 Hz
>
> Freq. offset of +127 Hz, which does not make sense, and the tone is heavily
> distorted as well (see image and image zomeed in).
>
> We've been fighting this for a few days. Any point of view is welcome here.
>
> Regards and happy new year :)
> Brais.
>
>
> The clock servo on the B2xx-mini series is NOT an analog PLL like on the
> other models. It tends to be "jumpy" with fairly high
> close-in phase-noise.
>
> This is probably the cause of your issue.
>
>
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
--
Martin K.
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] Weird effects setting external clock source in a B200mini
Brais,
I have two USRP here in front of me: B210, B200mini
When I run a sample program (C++) which specifies an external
reference, the B200mini shows a variable frequency offset. It seems to
lock (with high jitter) but then it "jumps" and I would say the offset
changes by +-10 Hz for a few seconds, then it stabilizes (and repeats
this behavior, forever).
When I run the same exact program with my B210 the phase stays visibly
locked and I see no problems with the frequency jumping around.
Therefore (I hesitantly say) I believe there is something undesirable
going on with the B200mini or something in UHD/firmware.
My test setup is thus:
10MHz rubidium reference --> N5182B Vector Signal Generator (BPSK
mode, 10kHz symbol rate) --> Ettus B200mini --or-- B210 (same 10 MHz
reference attached)
Sample code is C++, derived from usrp_recv_to_udp
[INFO] [UHD] Win32; Microsoft Visual C++ version 14.1; Boost_106800;
UHD_3.13.0.3-0-unknown
External reference is specified (and an exception is raised if 10 MHz
is not present).
My code is filtering and downsampling to baseband. I am viewing the
data in a constellation diagram which allows me to see the phase lock
or baseband rotation of the BPSK points.
I am happy to provide more information to solve this issue.
--
Martin Klingensmith
On Wed, Jan 2, 2019 at 9:56 AM Brais Ares via USRP-users
wrote:
>
> Hello,
>
> We've just bought an AXIOM90 OCXO [1] (actual configuration: 5 V, ±50 ppb,
> +7.7 dBm) and we are having trouble configuring it as an external clock
> reference on a B200mini.
>
> All we do in code is set the clock source as external:
>
> usrp->set_clock_source("external");
>
> And loop until it gets locked by checking:
>
> uhd::sensor_value_t ref_locked = usrp->get_mboard_sensor("ref_locked", 0);
>
> Once it's locked we capture 60 seconds of a RF sinusoid waveform centered at
> the central frequency (100 MHz) and plot its spectrum using Matlab. We would
> expect:
>
> Frequency drift - Internal oscillator [2] @ ±2 ppm = ±200 Hz
>
> Captured tone shows a freq. offset of +126 Hz, makes sense (see image and
> image zoomed in)
>
> Frequency drift - External oscillator (Agilent E4438C Signal generator,
> output power: +10 dBm)
>
> Captured tone shows a freq. offset of -3 Hz, makes sense, but the tone is
> heavily distorted (see image and image zomeed in).
>
> Frequency drift - External oscillator (AXIOM90) @ ±50 ppb (0.05 ppm) =
> ±5.4 Hz
>
> Freq. offset of +127 Hz, which does not make sense, and the tone is heavily
> distorted as well (see image and image zomeed in).
>
> We've been fighting this for a few days. Any point of view is welcome here.
>
> Regards and happy new year :)
> Brais.
>
> [1] - http://www.axtal.com/cms/docs/doc86239.pdf
> [2] - https://www.ettus.com/content/files/USRP_B200mini_Data_Sheet.pdf
>
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
--
Martin K.
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] Question B210 installation of C++ driver under Visual Studio 2017
[Sending to the list in case this information can help someone else:] I just did this with the following dependencies. All from source except python-2.7 * boost 1.68.0 - bzip2-1.0.6 (probably not required, but it was easy to add to boost) - icu4c - 63.1 - zlib-1.2.11 - python 2.7 * building boost: > bootstrap.bat Add the following line to the file project-config.jam in the boost source directory: using python : 2.7 : C:\\Python27\\python : : : 64 ; Then run b2 (boost build) > b2 -sBZIP2_SOURCE="C:\uhd_stack_build\bzip2-1.0.6" -sZLIB_SOURCE="C:\uhd_stack_build\zlib-1.2.11" -sICU_PATH="C:\uhd_stack_build\icu\source" --build-type=complete --libdir=c:\boost\lib architecture=x86 address-model=64 install **note the library source paths must be correct** Mako v1.0.7 > pip install mako numpy v1.15.4 > pip install numpy requests v2.20.1 > pip install requests nsis v3.03 (not required, but I installed it anyway) UHD 3.13.0.3-rc1 cmake GUI for windows Run cmake-gui (Start->) Set source path: C:/uhd_build/uhd-3.13.0.3-rc1 Set build path (an empty dir): C:/uhd_build/uhd-3.13.0.3-rc1/build Check Advanced click Configure Set toolset = Visual Studio 15 2017 Win64 The dependencies have to be manually located if cmake didn't find them. For example if you want to use USB USRPs then obviously you need cmake to find libusb properly. cmake uses unix style forward slashes, so click the [...] button to have it fix the path for you. (this is the path containing libusb.h) LIBUSB_INCLUDE_DIRS C:\uhd_stack_build\libusb-build\libusb-master\libusb\ (this is the full path to libusb-1.0.lib) LIBUSB_LIBRARIES C:\uhd_stack_build\libusb-build\libusb-master\x64\Release\lib\libusb-1.0.lib PYTHON_LIBRARYC:/Python27/libs/python27.lib PYTHON_EXECUTABLE C:/Python27/python.exe PYTHON_INCLUDE_DIR C:/Python27/include Boost_LIBRARY_DIR_DEBUGC:/boost/lib/x64 Boost_LIBRARY_DIR_RELEASEC:/boost/lib/x64 Boost_PYTHON_LIBRARY_DEBUG C:/boost/lib/x64/boost_python27-vc141-mt-gd-x64-1_68.lib Boost_PYTHON_LIBRARY_RELEASE C:/boost/lib/x64/boost_python27-vc141-mt-x64-1_68.lib After fixing incorrect/unknown dependency paths, click Configure again. This was the result of Configure after I had all the paths set correctly: ## # UHD enabled components ## * LibUHD * LibUHD - C API * LibUHD - Python API * Examples * Utils * Tests * USB * B100 * B200 * USRP1 * USRP2 * X300 * N230 * MPMD * N300 * E320 * OctoClock ## # UHD disabled components ## * LIBERIO * GPSD * E300 * Manual * API/Doxygen * Man Pages Building version: 3.13.0.3-0-unknown Using install prefix: C:/Program Files/UHD Configuring done Building UHD After configuring, open the project in Visual Studio by clicking the "Open Project" button in CMake Change target to Release Build Solution. Right click INSTALL project and Build Change target to RelWithDebInfo Build Solution. Right click INSTALL project and Build (if you encounter a cryptic build error about unknown stdlib symbols:) In the "uhd" project Properties pages, add in the: Additional Dependencies, this library: legacy_stdio_definitions.lib UHD Images Download UHD will automatically load the correct FPGA images for your hardware. To do this it needs to download the images from Ettus' website. >python "C:\Program Files\UHD\lib\uhd\utils\uhd_images_downloader.py" --verbose (of course, python must be in your PATH) ** Testing UHD installation ** UHD can be tested by executing: C:\Program Files\UHD\bin>uhd_usrp_probe.exe -- Martin Klingensmith ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] MSVC + CMake
Marcus, Thank you. I ran the 'INSTALL' target in Visual Studio and it installed FindUHD.cmake successfully. Previously I had generated an installer with the NSIS tool and I don't think it installed FindUHD.cmake. CMake now finds UHD. Is it normal that I cannot Debug a UHD client program in Visual Studio? The init_usrp sample application works in Release configuration but crashes in Debug. Exception thrown at 0x7FFAA1C02075 (uhd.dll) in init_usrp.exe: 0xC005: Access violation reading location 0x00462090 Thanks for your help, Martin Klingensmith On Fri, Dec 7, 2018 at 12:36 PM Marcus Müller wrote: > Dear Mr. Klingensmith, > > puh, it's been a while since I worked under Windows with CMake, but do > try > cmake -DCMAKE_MODULE_PATH=/path/to/where/FindUHD.cmake .. > > or using ccmake to add that path to the CMAKE_MODULE_PATH list. > > > Best regards, > Marcus > > On Thu, 2018-12-06 at 16:29 -0500, Martin K via USRP-users wrote: > > I just built UHD for my version of Visual Studio (15.5 == 2017) > > the examples, such as uhd_usrp_probe, execute normally. > > > > I am trying to make a new project and build the init_usrp example. > > The CMake GUI for Windows cannot find UHD: > > > > CMake Error at CMakeLists.txt:33 (find_package): > > By not providing "FindUHD.cmake" in CMAKE_MODULE_PATH this project > > has > > asked CMake to find a package configuration file provided by "UHD", > > but > > CMake did not find one. > > > > Could not find a package configuration file provided by "UHD" > > (requested > > version 3.8.0) with any of the following names: > > > > UHDConfig.cmake > > uhd-config.cmake > > > > Add the installation prefix of "UHD" to CMAKE_PREFIX_PATH or set > > "UHD_DIR" > > to a directory containing one of the above files. If "UHD" > > provides a > > separate development package or SDK, be sure it has been installed. > > > > > > I tried setting UHD_DIR, UHD_INCLUDE_DIRS, UHD_LIBRARIES in the CMake > > cache without any improvements. > > > > What is the best way to get CMake to find UHD on Windows? > > > > Thank you, > > -- > > Martin Klingensmith > > > > ___ > > USRP-users mailing list > > USRP-users@lists.ettus.com > > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com > > -- Martin K. ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
[USRP-users] MSVC + CMake
I just built UHD for my version of Visual Studio (15.5 == 2017) the examples, such as uhd_usrp_probe, execute normally. I am trying to make a new project and build the init_usrp example. The CMake GUI for Windows cannot find UHD: CMake Error at CMakeLists.txt:33 (find_package): By not providing "FindUHD.cmake" in CMAKE_MODULE_PATH this project has asked CMake to find a package configuration file provided by "UHD", but CMake did not find one. Could not find a package configuration file provided by "UHD" (requested version 3.8.0) with any of the following names: UHDConfig.cmake uhd-config.cmake Add the installation prefix of "UHD" to CMAKE_PREFIX_PATH or set "UHD_DIR" to a directory containing one of the above files. If "UHD" provides a separate development package or SDK, be sure it has been installed. I tried setting UHD_DIR, UHD_INCLUDE_DIRS, UHD_LIBRARIES in the CMake cache without any improvements. What is the best way to get CMake to find UHD on Windows? Thank you, -- Martin Klingensmith ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] IQ baseband fade?
Hi Matt, That would be a possibility, but the Real signal was decaying and the power was not shifting to the Imaginary leg. In other words, the phase was not rotating. My "decaying" signal was post-synchronization, so there was no frequency offset. I was able to demonstrate that the effect was being caused by the DC offset correction within the USRP. Thanks for your reply. - Martin On Fri, May 25, 2018 at 2:49 PM, Radio User via USRP-users < usrp-users@lists.ettus.com> wrote: > Could the "decay" you are seeing actually be the phase changing due to > offsets in the carrier frequency? Unless you are doing some kind of > phase-locking > on the RX signal to correct for frequency differences between the > transmitter > and receiver, the apparent phase will drift a bit. Especially over a > 200microsecond > step. > > (Consider that you're symbol time is about 0.8 mSec... Now assume that the > accuracy > of your carrier is 100 ppb. That says you could be off by 200Hz or so. In > 1 mS you > will have drifted (seen a phase shift) of 0.4pi radians. > > Does that make sense? > > matt > ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] IQ baseband fade?
to 8.000 MHz > | | _ > | |/ > | | | TX DSP: 1 > | | | > | | | Freq range: -8.000 to 8.000 MHz > | | _ > | |/ > | | | TX Dboard: A > | | | _ > | | |/ > | | | | TX Frontend: A > | | | | Name: FE-TX2 > | | | | Antennas: TX/RX > | | | | Sensors: temp, lo_locked > | | | | Freq range: 50.000 to 6000.000 MHz > | | | | Gain range PGA: 0.0 to 89.8 step 0.3 dB > | | | | Bandwidth range: 20.0 to 5600.0 step 0.0 Hz > | | | | Connection Type: IQ > | | | | Uses LO offset: No > | | | _ > | | |/ > | | | | TX Frontend: B > | | | | Name: FE-TX1 > | | | | Antennas: TX/RX > | | | | Sensors: temp, lo_locked > | | | | Freq range: 50.000 to 6000.000 MHz > | | | | Gain range PGA: 0.0 to 89.8 step 0.3 dB > | | | | Bandwidth range: 20.0 to 5600.0 step 0.0 Hz > | | | | Connection Type: IQ > | | | | Uses LO offset: No > | | | _ > | | |/ > | | | | TX Codec: A > | | | | Name: B210 TX dual DAC > | | | | Gain Elements: None > > > > > > On Wed, May 23, 2018 at 3:31 PM, Marcus D. Leech via USRP-users < > usrp-users@lists.ettus.com> wrote: > >> On 05/23/2018 03:13 PM, Martin K via USRP-users wrote: >> >> Hello, >> I have B210 hooked up to a signal generator putting out BPSK. >> When I look at the signal on a signal analyzer I see what I expect: the >> baseband, synchronized 'I' signal looks like a square wave. (Fig.1) >> >> When I capture the signal with the B210 and view it in GNU Radio or >> MATLAB, the square wave is not square, it turns into a decaying square (a >> sawtooth you could say) (Fig 2) >> >> It looks as if the baseband is being highpass filtered. I don't >> understand where this response could be coming from. I hope there is a >> simple explanation. >> >> I considered that the signal may be too powerful, however it is around >> -25dBm and I notice that the effect does not change over different signal >> power levels. >> >> I appreciate any help - thank you. >> >> >> >> >> >> -- >> Martin K. >> >> YOu're going to have to tell us a bit more about your setup. >> >> You're generating BPSK *baseband* and sending it to the USRP? Or you're >> generating a BPSK signal at some RF frequency? >> >> When you say you "capture" the signal, exactly how to you capture the >> signal? >> >> >> >> -- Martin K. ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
[USRP-users] IQ baseband fade?
Hello, I have B210 hooked up to a signal generator putting out BPSK. When I look at the signal on a signal analyzer I see what I expect: the baseband, synchronized 'I' signal looks like a square wave. (Fig.1) When I capture the signal with the B210 and view it in GNU Radio or MATLAB, the square wave is not square, it turns into a decaying square (a sawtooth you could say) (Fig 2) It looks as if the baseband is being highpass filtered. I don't understand where this response could be coming from. I hope there is a simple explanation. I considered that the signal may be too powerful, however it is around -25dBm and I notice that the effect does not change over different signal power levels. I appreciate any help - thank you. -- Martin K. ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] X310 - Vivado mig segfaults
I did some more searching and I found this github issue with a workaround: https://github.com/EttusResearch/uhd/issues/103 (begin quote): I hit the same ddr3_32bit build error on Windows: [IP_Flow 19-3475] Tcl error in ::ipgui_ddr3_32bit::updateAllModelParams procedure for IP 'ddr3_32bit'. Loading device for application Rf_Device from file '7k410t.nph' in environment C:/Xilinx/Vivado/2015.4/ids_lite/ISE. child killed: floating-point exception Workaround I found is the following: $ cd build-ip/xc7k410tffg900-2/ddr3_32bit/ $ rm mig_a.prj $ cp mig_xc7k410tffg900-2.prj mig_a.prj It looks like tcl does not like mig_a.prj being a link on Windows. (end quote) The build seems to successfully get past the mig however it fails on the "pga" block (much later in the build process): synth_ip: Time (s): cpu = 00:47:50 ; elapsed = 00:55:13 . Memory (MB): peak = 1815.309 ; gain = 1479.445 BUILDER: Adding file from Block Design list: C: pga pga-maintusrp3op ERROR: [Vivado 12-172] File or Directory 'pga' does not exist INFO: [Common 17-206] Exiting Vivado at Mon Jan 29 15:12:30 2018... make[1]: *** [Makefile.x300.inc:111: bin] Error 1 make[1]: Leaving directory '/cygdrive/c/fpga/fpga-maint/usrp3/top/x300' make: *** [Makefile:61: X310_HG] Error 2 I will switch over to the master branch if you think my time will be more productive there? I saw that you are working toward a new release very soon. On Mon, Jan 29, 2018 at 2:52 PM, Martin Braun via USRP-users < usrp-users@lists.ettus.com> wrote: > On 01/26/2018 03:49 PM, Martin K via USRP-users wrote: > > I have Cygwin64 setup in Windows 10 > > Vivado 15.4.2 installed and licensed. > > > > [...] > > Some web searching shows that other people have had trouble with the mig > > failing - on both Windows and Linux, but obviously it works for you > > guys. I appreciate any advice. > > We've had issues like this (not sure if exactly this issue), and > recently saw them again when we updated Vivado (I think). Maybe this is > a Cygwin issue, but maybe not. Which branch are you running? If it's > master, can you update to the latest and try 2017.4? > > -- M > > ___ > USRP-users mailing list > USRP-users@lists.ettus.com > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com > -- Martin K. ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
[USRP-users] X310 - Vivado mig segfaults
I have Cygwin64 setup in Windows 10 Vivado 15.4.2 installed and licensed. source setupenv.sh --vivado-path=/cygdrive/c/Xilinx/Vivado/ Setting up a 64-bit FPGA build environment for the USRP-X3x0... - Vivado: Found (/cygdrive/c/Xilinx/Vivado//2015.4/bin) - Vivado HLS: Found (/cygdrive/c/Xilinx/Vivado_HLS/2015.4/bin) Environment successfully initialized. $ make X310_HA [cut out a lot of successful operations] BUILDER: Refreshing IP INFO: [IP_Flow 19-1686] Generating 'Instantiation Template' target for IP 'ddr3_32bit'... Loading device for application Rf_Device from file '7k410t.nph' in environment C:/Xilinx/Vivado/2015.4/ids_lite/ISE. child killed: floating-point exception CRITICAL WARNING: [IP_Flow 19-1747] Failed to deliver file 'c:/Xilinx/Vivado/2015.4/data/ip/xilinx/mig_7series_v2_4/xit/instantiation_template.xit': Loading device for application Rf_Device from file '7k410t.nph' in environment C:/Xilinx/Vivado/2015.4/ids_lite/ISE. child killed: floating-point exception ERROR: [IP_Flow 19-167] Failed to deliver one or more file(s). ERROR: [IP_Flow 19-3505] IP Generation error: Failed to generate IP 'ddr3_32bit'. Failed to generate 'Verilog Instantiation Template' outputs: ERROR: [IP_Flow 19-98] Generation of the IP CORE failed. Failed to generate IP 'ddr3_32bit'. Failed to generate 'Verilog Instantiation Template' outputs: INFO: [Common 17-206] Exiting Vivado at Fri Jan 26 14:44:19 2018... It also failed with the X310_HG target. I don't suspect it would work for any targets. Some web searching shows that other people have had trouble with the mig failing - on both Windows and Linux, but obviously it works for you guys. I appreciate any advice. Thanks! ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
