Re: [USRP-users] Poor Data Rates with the USRP E312
The E31x series really are intended for applications where all the high sample rate stuff happens in the FPGA. The ARM cpu is only dual core and runs at under 1Ghz. The scenario you describe is a lot like what we used to call “network mode” for the E31x, and it was never recommended for that type of scenario. Sent from my iPhone > On Nov 22, 2020, at 9:21 PM, Joe Crossen via USRP-users > wrote: > > > Hi all, > > I'm attempting to use the USRP E312 as a wifi node using the gr-ieee802.11 > module... > though for now I'm testing basic USRP functionality with a couple of simple > GNU graphs. > > Here's my setup: > - the host is an Ubuntu 18.04 virtual machine with a bridged adaptor. > Firewall disabled. > - the USRP is the E312, connected via ethernet to the host network. > - the host and USRP are both running GR3.8 and UHD4.0 (Zeus branch). > - the host can see the USRP with uhd_usrp_probe. > - the USRP is running the following GNU graph - UHD:USRP Source -> UDP Sink. > - host is running the following GNU graph - UDP Source -> QT GUI Sink. > - all block parameters are default. > > I'm experiencing the following issues: > 1. For sample rates > ~2Msps, the USRP spams overrun "O" and "D" characters > (what does the "D" signify?) , regardless of whether the host graph is > running or not. > 2. At any sample rate the host graph spams the following message (when the > USRP graph is running) - "gr::log :WARN: udp_source0 - Too much data; > dropping packet." > > And a question: > 3. What sample rates are realistic for this setup, and what are the > limitations? wifi channels span 20MHz, so I'm hoping to run at 20Msps > > Thanks, > Joe > > > > > ___ > USRP-users mailing list > usrp-us...@lists.ettus.com > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Poor Data Rates with the USRP E312
Hi all, I'm attempting to use the USRP E312 as a wifi node using the gr-ieee802.11 module... though for now I'm testing basic USRP functionality with a couple of simple GNU graphs. Here's my setup: - the host is an Ubuntu 18.04 virtual machine with a bridged adaptor. Firewall disabled. - the USRP is the E312, connected via ethernet to the host network. - the host and USRP are both running GR3.8 and UHD4.0 (Zeus branch). - the host can see the USRP with uhd_usrp_probe. - the USRP is running the following GNU graph - UHD:USRP Source -> UDP Sink. - host is running the following GNU graph - UDP Source -> QT GUI Sink. - all block parameters are default. I'm experiencing the following issues: 1. For sample rates > ~2Msps, the USRP spams overrun "O" and "D" characters (what does the "D" signify?) , regardless of whether the host graph is running or not. 2. At any sample rate the host graph spams the following message (when the USRP graph is running) - "gr::log :WARN: udp_source0 - Too much data; dropping packet." And a question: 3. What sample rates are realistic for this setup, and what are the limitations? wifi channels span 20MHz, so I'm hoping to run at 20Msps Thanks, Joe
Re: [USRP-users] daughter board coherency on N310
On 11/22/2020 10:30 AM, Cameron Matson wrote: Marcus, Yes it was all coming out of the same uhd_source object. I think I was able to resolve the issue for now by setting the "Sync" parameter to "unknown PPS" which I /believe/ is using the White Rabbit Ethernet based timing synchronization which we have connected at one of the SFP ports, though I need to dig in a bit more into the API. I agree 20 ms is *HUGE*; is it unexpected even without an external timing source? Should I still be concerned? Thanks, Cameron Actually, this isn't unexpected. For architectural reasons, there is a timstamp clock for each RF chain in th device--those clocks need to b synchronized, so a "set_time_next_pps" will take care of that. On Fri, Nov 20, 2020 at 12:43 PM Marcus D. Leech mailto:patchvonbr...@gmail.com>> wrote: On 11/20/2020 11:49 AM, Rob Kossler wrote: Hi Cameron, Yes, this is possible. I'm not too familiar with gnuradio but in the end you need to use a "timed start" to the receive streams. Rob On Fri, Nov 20, 2020 at 7:34 AM Cameron Matson via USRP-users mailto:usrp-us...@lists.ettus.com>> wrote: Hello all, I'm trying to implement a MIMO receiver using the 4 RF chains of the N310. To test the timing of the system, at the transmitter I'm simply sending a short pulse from one transmit antenna of one USRP. At the receiver it looks like there is up to a ~20 ms delay/offset between the pairs of antennas 0/1 and 2/3 and that this delay changes each time I restart my GNURadio flowgraph. I can see the delay both in GNURadio GUI Time Sink and in actual samples that I write to file. I've tried various pulse widths and sampling rates at both the tx and rx, and it seems invariant to these. I'd really like to be able to synchronize the 4 RF chains in time simultaneously. Is that possible? Thanks Cameron Matson ___ Cameron: Can you share a simple Gnu Radio flow-graph that displays this behavior? A 20ms offset is *HUGE*. Are all 4 streams being streamed out of the same uhd_source object?
[VOLK] Release v2.4.0
Hi everyone! We have another VOLK release! We're happy to announce VOLK v2.4.0! We want to thank all contributors. This release wouldn't have been possible without them. We introduce `cpu_features` as a private submodule in this release because we use it to detect CPU features during runtime now. This should enable more reliable feature detection. Further, it takes away the burden to implement platform specific code. As a result, optimized VOLK kernels build for MacOS and Windows with AppleClang/MSVC out-of-the-box now. You can find the release news on [libvolk.org](https://www.libvolk.org/category/news.html) ### Highlights * Documentation - Update README to be more verbose and to improve usefulness. * Compilers - MSVC: Handle compiler flags and thus architecture specific kernels correctly. This enables optimized kernels with MSVC builds. - AppleClang: Treat AppleClang as Clang. - Paired with the `cpu_features` introduction, this enables us to use architecture specific kernels on a broader set of platforms. * CI - Update to newest version of the Intel SDE - Test the rotator kernel with a realistic scalar - Introduce more test cases with newer GCC and newer Clang versions. * CMake - Enable to not install `volk_modtool`. - Remove "find_package_handle_standard_args" warning. * cpu_features - Use `cpu_features` v0.6.0 as a private submodule to detect available CPU features. - Fix incorrect feature detection for newer AVX versions. - Circumvent platform specific feature detection. - Enable more architecture specific kernels on more platforms. * Kernels - Disable slow and broken SSE4.1 kernel in `volk_32fc_x2_dot_prod_32fc` - Adjust min/max for `32f_s32f_convert_8i` kernel - Use `INT8_*` instead of `CHAR_*` ### Contributors * Adam Thompson * Andrej Rode * Christoph Mayer * Clayton Smith * Doron Behar * Johannes Demel , * Martin Kaesberger * Michael Dickens * Ron Economos ### Changes * Documentation - Update README to include ldconfig upon volk build and install completion - Update README based on review - readme: Fix wording - docs: Fix conversion inaccuracy * MSVC - archs: MSVC 2013 and greater don't have a SSE flag * CI - update to newest version of the Intel SDE - Test the rotator kernel with a realistic scalar * CMake - build: Enable to not install volk_modtool - cmake: Remove "find_package_handle_standard_args" warning. - cmake: Ensure that cpu_features is built as a static library. * cpu_features - readme: Add section on supported platforms - readme: Make supported compiler section more specific - travis: Add GCC 9 test on focal - travis: Add tests for clang 8, 9, 10 - travis: Fix incorrect CXX compiler assignment - cpu_features: Remove unused feature checks - ci: Update TravisCI for cpu_features - cpu_features: Fix MSVC build - pic: Fix BUILD_PIC issue - ci: Update CI system configuration - cpu_features: Bump submodule pointer to v0.6.0 - docs: Add hints how to handle required submodules - cpu_features: Switch to cpu_features - ci: Update CI system for cpu_features - cpu_features: Force PIC build flag - appveyor: Add recursive clone command - cpu_features: Remove xgetbv checks - pic: Cache and force BUILD_PIC - ci: Remove explicit BUILD_PIC from cmake args - ci: Remove BUILD_PIC from CI cmake args - cpu_features: Remove commented code - cpu_features: Assume AppleClang == Clang - cpu_features: Remove obsolete code in archs.xml - fix for ARM cross-compiling CI - ARM CI: remove unneeded environment variables * Housekeeping - structure: Move release scripts to scripts folder * Kernels - emit an emms instruction after using the mmx extension - volk_32fc_x2_dot_prod_32fc: disable slow & broken SSE4.1 kernel - fix: Adjust min/max for 32f_s32f_convert_8i kernel - fix: Use INT8_* instead of CHAR_*
Re: [USRP-users] daughter board coherency on N310
Marcus, Yes it was all coming out of the same uhd_source object. I think I was able to resolve the issue for now by setting the "Sync" parameter to "unknown PPS" which I *believe* is using the White Rabbit Ethernet based timing synchronization which we have connected at one of the SFP ports, though I need to dig in a bit more into the API. I agree 20 ms is *HUGE*; is it unexpected even without an external timing source? Should I still be concerned? Thanks, Cameron On Fri, Nov 20, 2020 at 12:43 PM Marcus D. Leech wrote: > On 11/20/2020 11:49 AM, Rob Kossler wrote: > > Hi Cameron, > Yes, this is possible. I'm not too familiar with gnuradio but in the end > you need to use a "timed start" to the receive streams. > Rob > > On Fri, Nov 20, 2020 at 7:34 AM Cameron Matson via USRP-users < > usrp-us...@lists.ettus.com> wrote: > >> Hello all, >> >> I'm trying to implement a MIMO receiver using the 4 RF chains of the >> N310. To test the timing of the system, at the transmitter I'm simply >> sending a short pulse from one transmit antenna of one USRP. At the >> receiver it looks like there is up to a ~20 ms delay/offset between the >> pairs of antennas 0/1 and 2/3 and that this delay changes each time I >> restart my GNURadio flowgraph. I can see the delay both in GNURadio GUI >> Time Sink and in actual samples that I write to file. I've tried various >> pulse widths and sampling rates at both the tx and rx, and it seems >> invariant to these. >> >> I'd really like to be able to synchronize the 4 RF chains in time >> simultaneously. Is that possible? >> >> Thanks >> Cameron Matson >> ___ >> >> Cameron: > > Can you share a simple Gnu Radio flow-graph that displays this behavior? > A 20ms offset is *HUGE*. Are all 4 streams being streamed out > of the same uhd_source object? > > > >
Re: How to import custom script to GRC?
Thanks for the info. I already stumbled accross this block, but a quick try did not worked as expected. Classical case of RTFM ;) You have to call the functions you define in there with idOfPythonModuleBlock.myFunction(): https://wiki.gnuradio.org/index.php/Python_Module Thanks a lot! Am 21.11.20 um 19:40 schrieb Marcus D. Leech: > On 11/21/2020 09:26 AM, Fabian Schwartau wrote: >> Hi everyone, >> I would like to built some flow graphs with GRC, but I need to write a >> few custom python functions which I want to use in the flow graph. For >> example I need to generate some filter coefficient and things like that. >> I thought I just create a python script in the same folder, define some >> functions, import the script with the Import block and I am good to go. >> However, the Import block complains that the import failed and I cannot >> start the flow graph. >> What am I missing? What the the typical workflow in such case? >> >> Best regards, >> Fabian >> >> > The "Python Module" block takes care of that quite handily. > > >
