[USRP-users] RFNOC OOT module no longer building

I added a new block to my OOT module and now when I run make from the build directory things don't build properly. I source my setup_env.sh and then run make from build and see the following: -- PyBOMBS installed GNU Radio. Setting CMAKE_INSTALL_PREFIX to /home/jmat/rfnoc -- Build type not spe

Re: [USRP-users] RFNOC OOT module no longer building

I think I solved this by blowing away everything within the testbench directory. I am not sure what happened, but this seems like the best fix for now. On 07/07/2017 12:04 PM, Jason Matusiak wrote: I added a new block to my OOT module and now when I run make from the build directory things do

[USRP-users] Bypass arm processor usrp e310/e312

Hello - For the USRP E310/E312 I was wondering if it is possible to bypass the 10 Msps bottleneck between FPGA and ARM processor when receiving and/or transmitting data. Does all data streaming in and out of the USRP have to go through the ARM processor or can we have the data bypass the ARM p

Re: [USRP-users] Bypass arm processor usrp e310/e312

There's no direct path between the FPGA and the PS-side Ethernet controller which would support this mode of operation. You have to go through the host at some point. --n On Fri, Jul 7, 2017 at 10:16 AM Cho, Daniel J (332C) via USRP-users < usrp-users@lists.ettus.com> wrote: > Hello – > > > > Fo

Re: [USRP-users] Random errors while transmitting certain BPSK/QPSK types on x310s

FYI I've noticed a very similar issue, isolated it to non usrp gnuradio blocks in tx chain. Specifically the constellation or *psk modulator blocks. Certain combos produced garbage IQ data(visible as several spikes in PSD display) at regular intervals (seemingly related to sample rate), this is vis

Re: [USRP-users] Random errors while transmitting certain BPSK/QPSK types on x310s

Hi Marcus, you are correct, reducing the magnitude did seem to fix the issue. I am wondering though, the gnuradio constellation modulator hier block also seems to suffer from the same issue and doesn't have any options for reduced magnitude output - do most people just throw in a downstream block

Re: [USRP-users] Random errors while transmitting certain BPSK/QPSK types on x310s

Hi Michael, point is that having a magnitude too close to 1 can lead to problems in the FPGA side of DSP – not in GNU Radio. Best regards, Marcus On 07/07/2017 07:20 PM, Michael Carosino via USRP-users wrote: > Hi Marcus, > > you are correct, reducing the magnitude did seem to fix the issue.

Re: [USRP-users] Random errors while transmitting certain BPSK/QPSK types on x310s

If the modulator blocks always produce in {-1,+1}, then a downstream multipier would be required to reduce the baseband magnitude. It will happen with any radio where there is a translation from floating point {-1.0,+1.0} into some integer representation on the wire, followed by interpolation/upc

Re: [USRP-users] Random errors while transmitting certain BPSK/QPSK types on x310s

Oh! If that is the case, yes, please do make an example FG, and if you find the time, also open an issue on https://github.com/gnuradio/gnuradio/issues . Thanks! Marcus On 07/07/2017 07:19 PM, Anon Lister via USRP-users wrote: > FYI I've noticed a very similar issue, isolated it to non usrp > g

Re: [USRP-users] Random errors while transmitting certain BPSK/QPSK types on x310s

You can change the gain setting on the interpolating FIR filter to accomplish this. The QT GUI Histogram Sink can be used to set a gain value that limits the IQ values to +1/-1. Ron On 07/07/2017 10:20 AM, Michael Carosino via USRP-users wrote: Hi Marcus, you are correct, reducing the magn

Re: [USRP-users] rfnoc-modtool cores

Circling back to this EJ, what should I make my Makefile.OOT.inc look like to include two directories, something like this?: OOT_DIR = /home/jmat/rfnoc-multiaperture/rfnoc OOT_DIR = /home/jmat/rfnoc-nocblocks/rfnoc include $(OOT_DIR)/Makefile.inc On 06/14/2017 08:43 PM, EJ Kreinar wrote: Yes,

Re: [USRP-users] Random errors while transmitting certain BPSK/QPSK types on x310s

I've created an OOT module with a little utility I use to print peak IQ levels. This allows for precise setting of the gain to insure IQ levels are within +1/-1. https://github.com/drmpeg/gr-iqlevels Ron On 07/07/2017 11:28 AM, Ron Economos via USRP-users wrote: You can change the gain sett

Re: [USRP-users] X310 transmit underflow when sampling rate is low

Sorry for the late reply, The MTU is set to 9000. The time spec was varied from a few dozen ms up to several seconds in the future with no change in behavior. chris From: Jonathon Pendlum [mailto:jonathon.pend...@ettus.com] Sent: Tuesday, June 27, 2017 12:18 PM To: Hood, Christopher L. Cc: us

Re: [USRP-users] ADC self-test failed

Hi Sam, Can you please email into supp...@ettus.com. We can debug further off the mailing list. Regards, Nate > On Jul 6, 2017, at 8:39 AM, Sam Vogel wrote: > > Hi Nate, > > Sure, our company is using a custom UHD and I will have to redact part of the > text. When I run the command it outp

Re: [USRP-users] Different streaming modes at the same time with same USRP hardware

Hi Felipe, If it works, it must be right! The code looks fine to me. Regards, Michael On Mon, Jul 3, 2017 at 3:58 AM, Felipe Augusto Pereira de Figueiredo < zz4...@gmail.com> wrote: > Dear Michael, > > I've followed your suggestion and hacked the rx_samples_c.c example. > It seems to be workin

Re: [USRP-users] Different streaming modes at the same time with same USRP hardware

Thanks Michael! Now I'm trying to create different streamers for TX and RX in channels 0 and 1, but my application running on a b210 returns the following error: Error opening RX stream for channel 1 with error code: 44 No compatible RF frontend found Error opening rf I checked and code 44 means

Re: [USRP-users] rfnoc-modtool cores

Sure: OOT_DIR = /home/jmat/rfnoc-multiaperture/rfnoc include $(OOT_DIR)/Makefile.inc OOT_DIR = /home/jmat/rfnoc-nocblocks/rfnoc include $(OOT_DIR)/Makefile.inc You'll also need your out-of-tree makefile to agree with the OOT_DIR format. See here for example (which I think you probably have corr