Re: [Discuss-gnuradio] Bug in GR runtime: Messages do not restart after reconfiguration

Hi Eugene, I haven't noticed whether you've seen any reaction – in case you haven't: It'd be a shame if this was lost! Could you please add an issue on the GNU Radio Github issue tracker? Best regards, Marcus On 09/21/2016 05:57 PM, Eugene Grayver wrote: > > Hello, > > > I found a bug in the GR

Re: [Discuss-gnuradio] gnuradio for Windows

Hi Lyman, to add to what Geof said, try the LiveSDR environment. It's kept for the sole purpose of offering people with a ready-to-run environment, even if they don't have a readily set up Linux box at hand. http://gnuradio.org/redmine/projects/gnuradio/wiki/GNURadioLiveDVD Best regards,

Re: [Discuss-gnuradio] ENABLE_PERFORMANCE_COUNTERS Crash

Neel, Sure it is the B4860QDS running the Yocto 1.8 ‘daisy’ build from the freescale website. I am using the 64-bit build. K- From: Neel Pandeya [mailto:neel.pand...@ettus.com] Sent: Wednesday, September 28, 2016 4:29 PM To: Unice, W. Kyle @ CSG - CSW Cc: discuss-gnuradio@gnu.org Subject:

Re: [Discuss-gnuradio] ENABLE_PERFORMANCE_COUNTERS Crash

Hello Kyle: Yeah, I had a feeling as I looked more closely at the error messages. Could you tell me more about your hardware and your Linux distro/version? --Neel Pandeya On 28 September 2016 at 15:22, wrote: > *Neel,* > > > > *Actually I am running on a PPC 64-bit

Re: [Discuss-gnuradio] ENABLE_PERFORMANCE_COUNTERS Crash

Hello Kyle: You're running on the E310, right? Where did you build GNU Radio, on the E310, or on the external host? Could you post the output of the following: gcc --version uname -a echo $LD_LIBRARY_PATH --Neel Pandeya On 28 September 2016 at 15:13, wrote: > I

[Discuss-gnuradio] ENABLE_PERFORMANCE_COUNTERS Crash

I compile GNU Radio with the -DENABLE_PERFORMANCE_COUNTERS=ON, edit the /etc/gnuradio/conf.d/gnuradio-runtime.conf file to enable 'ctrlport' etc. I bring up my graph and add the CtrlPort Performance Monitor and CtrlPort Monitor blocks to my graph and then run the graph. I get a page fault in

Re: [Discuss-gnuradio] GNU flow graph containing a UHD block - unable to detect USRP E310

> If you do want to stream samples across the network you will need to compile UHD with custom settings. The other option that I've done occasionally is having a flowgraph running on the E310 and another one running on my PC. Then via UDP source/sink blocks, I can pass data to my PC (though

Re: [Discuss-gnuradio] GNU flow graph containing a UHD block - unable to detect USRP E310

Hello John, The E310 is designed to have GNU Radio run onboard the radio rather than on an external computer. By default the USRP driver does not include support for using the E310 remotely across a network. This is because network mode was implemented primarily as a debugging aid. The sample

[Discuss-gnuradio] Control the speed of a source block based on the sample rate

Hi, I have created a source block as an oot module that gets an application layer message(message size is 160bytes) to send via USRP. The source block is connected to a packet encoder followed by QPSK modulator and a USRP sink block. If the application message rate is low, the source block

Re: [Discuss-gnuradio] GNU flow graph containing a UHD block - unable to detect USRP E310

On 09/28/2016 08:32 AM, Jason Matusiak wrote: > I have an E310 device connected over an Ethernet link to a laptop running GNU Radio. You want to run the GNURadio script on the E310 itself. The E310 has its own processor so you can think of it as a PC with a USRP attached to it. Your host PC

Re: [Discuss-gnuradio] Rectangular Pulse Shape w/ PFB Clock Sync

I haven't tried it myself, but wouldn't using a raised cosine or Gaussian filter for your taps still provide some pulse shaping for the PFB clock sync to track? You're essentially leap-frogging the RRC matched filters at transmitter and receiver, and placing the entire burden at the receiver, but

Re: [Discuss-gnuradio] Rectangular Pulse Shape w/ PFB Clock Sync

> From: > John Malsbury > Subject: > [Discuss-gnuradio] Rectangular > Pulse Shape w/ PFB Clock Sync > Date: > Wed, 28 Sep 2016 00:07:46 -0700 > >

[Discuss-gnuradio] GNU flow graph containing a UHD block - unable to detect USRP E310

> I have an E310 device connected over an Ethernet link to a laptop running GNU Radio. You want to run the GNURadio script on the E310 itself. The E310 has its own processor so you can think of it as a PC with a USRP attached to it. Your host PC doesn't know about the USRP attached to the ARM

Re: [Discuss-gnuradio] Rectangular Pulse Shape w/ PFB Clock Sync

I have tried to use PFB clock sync without success on rectangular pulses as well. Presumably you've seen the documentation [1] on nfilts and taps. I tried making the filter a rectangular pulse with x sps upsampled by nfilts. One theory I have is that the polyphase clock sync may not work with

[Discuss-gnuradio] GNU flow graph containing a UHD block - unable to detect USRP E310

I have an E310 device connected over an Ethernet link to a laptop running GNU Radio. When I attempted to execute a GNU flow graph containing a UHD block, I got the following error: RuntimeError: LookupError: KeyError: No devicesfound for -> Empty Device Address I have entered the device

[Discuss-gnuradio] Rectangular Pulse Shape w/ PFB Clock Sync

I'm struggling with something pretty basic. I am trying to achieve near theoretical performance detection of a rectangular (no RRC) QPSK signal at 2 or 4 sps. I have an existing solution that uses a discrete FIR filter followed by a Gardner timing recovery loop. The taps of the FIR filter are