Re: [Discuss-gnuradio] Setting cmake variable with pyBOMBS

Patrick, please don't get impatient with the mailing list, most people here are helping in their free time. Give it a day or two. In your case, there's no global config, but this might work. Add the following lines to your config.yml: ``` categories: hardware: vars: config_opt: ```

Re: [Discuss-gnuradio] 802.11 transceiver issue

I ran the volk_profile just after the installation so that is not an issue i guess. Also, I played around with the parameters of the message strobe ( the period parameter), it did have an effect on the underruns and the async message buffer overflow warning. Low values of the period parameter

Re: [Discuss-gnuradio] Setting cmake variable with pyBOMBS

Any suggestions ? Thanks, --Patrick From: wp...@hotmail.com To: discuss-gnuradio@gnu.org Date: Wed, 30 Mar 2016 00:03:10 -0700 Subject: [Discuss-gnuradio] Setting cmake variable with pyBOMBS Hi, I installed gnuradio and gr-osmosdr using the latest pyBOMBS from source. However none of

[Discuss-gnuradio] UHD clock rate in the usrp e310 - release 4

Hi all, I've developed a flowgraph wich includes a qpsk modulator and and audio encoder, I used to run it in the E310 using the first release ( http://files.ettus.com/e3xx_images/e3xx-release-001/) and now trying to use the release 4. The problem is: in the UHD sink and source the clock rate was

Re: [Discuss-gnuradio] topblock.wait() never returns even after i stop() it.

More information: I had a lock(), unlock() pair around the stop - which might have been causing the problem. i.e. topblock.lock() ... topblock.stop() topblock.unlock() Now the wait() returns in the loop that was waiting. It now works for USRP but I'd like to know why this bothered the USRP in

[Discuss-gnuradio] topblock.wait() never returns even after i stop() it.

Hello, I am trying to reconfigure a flow graph based on a signal. The signal handler does a stop on a flow graph but the routine that is running the flow graph and waiting on the top block, never returns from the wait on the top block of the flow graph. I am using osmosdr + gnuradio even though

Re: [Discuss-gnuradio] costas ambiguity and correlate-and-sync block in qpsk

Hi Arik, I just took a quick look at your flowgraph. Some things jump out at me: 1. You have the modulator set at 2 samples/symbol, but the reality is, most hardware is not going to transmit at 320 ksps. The X310 USRP for example requires a minimum of 500 ksps for Tx, so you might as well just

Re: [Discuss-gnuradio] Compiling Documentation with an OOT

I've asked this question a few times now on the mailing list, and each time I hope a different answer comes through. Each time though it's the answer Ron gave, which never works for me. I can't figure it out. So I've always resorted to the xml tags to get documentation into GRC, but for the

Re: [Discuss-gnuradio] Unable to build on 32-bit Slackware-Current system (cmake configuration problems)

Nathan, I'll read a little more carefully next time. My apologies. I will try the sed scripts with cmake 3.5. Thank you again. Cheers, Fred On 03/30/2016 03:08 PM, West, Nathan wrote: I'm in the habit of not downloading and extracting tarballs from strangers on the internet, so I don't

Re: [Discuss-gnuradio] Unable to build on 32-bit Slackware-Current system (cmake configuration problems)

I'm in the habit of not downloading and extracting tarballs from strangers on the internet, so I don't know what Tom's latest issue is, but the problem you refer to is an issue revealed by the release of cmake 3.5. cmake 3.5 was released after the latest VOLK and GNU Radio release. That bug has

Re: [Discuss-gnuradio] Unable to build on 32-bit Slackware-Current system (cmake configuration problems)

Hi, Just tried building on my machine. Slackware64-14.1 with cmake 3.5.1 built from Slackware64-current. I would have tried this on a 32 bit machine but I don't have any running any more. What I found is that cmake 3.5 fails with errors when configuring gnuradio 3.7.9.1 build. I modified

Re: [Discuss-gnuradio] events, Friedrichshafen (Germany), Linuxwochen (Vienna)

On 30/03/16 21:23, Markus Heller wrote: > Hi Daniel, > > let me organize something. I guess we'll arrange an informal SDR & > GNURadio dinner after the SDRA somewhere in the city, with the SDRA > speakers and all GNURadio folks. Of course it will be open to all open > source people. > > I'll

Re: [Discuss-gnuradio] events, Friedrichshafen (Germany), Linuxwochen (Vienna)

Hi Daniel, let me organize something. I guess we'll arrange an informal SDR & GNURadio dinner after the SDRA somewhere in the city, with the SDRA speakers and all GNURadio folks. Of course it will be open to all open source people. I'll let you know as soon as I have news. br markus Am

[Discuss-gnuradio] events, Friedrichshafen (Germany), Linuxwochen (Vienna)

Hi all, Is there any official GNU Radio table at Friedrichshafen[1] (24-26 June) or any interest in sharing a community table with any other free software projects? Does anybody plan to visit Linuxwochen[2] (Vienna, 28 - 30 April) or even do a talk there? Should things like this go into the

[Discuss-gnuradio] Idea for gr-osmosdr/rtlsdr drivers

How about a thingy that makes a note of the local high-precision time when the first samples arrive in the work() function, and then somehow make that available to higher layers, so that you can get a first-order approximation of the time skew between the streams?

[Discuss-gnuradio] problem with gr-osmosdr so file

My machine was modified at work and my home directory is a new name now. Part of the process went through and scrubbed my home directory names in files to point to the new one. Most things (my X310 script) are working fine as-is, but when I try to run an RTL-SDR script, it errors out. I can

Re: [Discuss-gnuradio] comparing SDR upconverters, thermal stability

Hi Daniel, shortly answering your questions: On 30.03.2016 17:50, Daniel Pocock wrote: > OK, so keeping the mixer cooled will help reduce loss but has nothing > to do with frequency stability? yes; well, the point is that the mixer is really just a multiplier, built from a nonlinear device, and

Re: [Discuss-gnuradio] gr-radar make problem

Hi, Sebastian is right, it's most likely a dependency problem. I've tested the source from git and it compiles fine with following dependencies: - gnuradio 3.7.9.1 - uhd 3.9.2 - boost 1.60.0 First check boost, old versions don't have the strerror function. If boost is the problem, I should

[Discuss-gnuradio] GRCon16 links

I see a link here: http://gnuradio.org/grcon-2016/ Is registration open? It says it starts today 3/30/16, but no link. Thanks, Lou -- View this message in context: http://gnuradio.4.n7.nabble.com/GRCon16-links-tp59207.html Sent from the GnuRadio mailing list archive at Nabble.com.

Re: [Discuss-gnuradio] gr-radar make problem

Hi Mostafa, have you checked your BOOST version? gr-radar needs 1.60.0 or higher. Also, see https://github.com/kit-cel/gr-radar/issues/10 for more info. Regards, Sebastian Am 30. März 2016 bei 09:57:22, Mostafa Alizadeh (m.alizade...@gmail.com) schrieb: Hi all,  I tried to build gr-radar

[Discuss-gnuradio] Unable to build on 32-bit Slackware-Current system (cmake configuration problems)

Dear All, I am attempting to build Gnuradio on a 32-bit x86 Slackware-current system but without success. I have tried several approaches. o Using the Slackbuilds scripts at https://slackbuilds.org/repository/14.1/development/gnuradio/ which builds gnuradio-3.7.8.1. o Using the

Re: [Discuss-gnuradio] comparing SDR upconverters, thermal stability

If you can synthesize the LO for the upconverter using the RTL XO as a reference, the drift may tend to cancel. I say "may" as this is a trick used in dual or triple down conversion chains. If you can alternate between low and high sided IFs, then the drifts will move in the opposite directions

Re: [Discuss-gnuradio] comparing SDR upconverters, thermal stability

Tsys is essentially irrelevant for HF receivers, since Tambient is much, much higher (thousands of K) than even some really-poor RF engineering scenarios. At HF, galactic background can be very high--1e4K or more. On 2016-03-30 10:30, Marcus Müller wrote: > Hi Daniel, > > haven't made

Re: [Discuss-gnuradio] comparing SDR upconverters, thermal stability

On 30/03/16 16:49, mle...@ripnet.com wrote: > All of them use reasonably good crystals or crystal XOs. Certainly a > lot better than the RTLSDRs most of these were intended for. > > I assume that you're talking about frequency stability, rather than gain > stability? > Yes, frequency

Re: [Discuss-gnuradio] comparing SDR upconverters, thermal stability

On 30/03/16 16:30, Marcus Müller wrote: > Hi Daniel, > > haven't made experience with any of these upconverters; but: > > The really temperature-sensitive aspect of an upconverter is probably > the oscillator, not the mixer. So the trick might really be keeping > your upconverter in the same

Re: [Discuss-gnuradio] comparing SDR upconverters, thermal stability

I know that some of them, like the HAMITUP, use a socket for the XO, which one could easily replace with a TCXO. Check with the manufacturers about the XO spec they use. On 2016-03-30 11:43, Daniel Pocock wrote: > On 30/03/16 16:49, mle...@ripnet.com wrote: > >> All of them use reasonably

Re: [Discuss-gnuradio] Compiling Documentation with an OOT

On Mon, Mar 28, 2016 at 9:25 PM, Tom McDermott wrote: > Hi Richard - > > When you say 'propagate through to GRC' do you mean 'How to display on > the GRC documentation tab in the open block properties window'? (select > block, double-click, or rt-click-properties). > > I do

Re: [Discuss-gnuradio] comparing SDR upconverters, thermal stability

All of them use reasonably good crystals or crystal XOs. Certainly a lot better than the RTLSDRs most of these were intended for. I assume that you're talking about frequency stability, rather than gain stability? On 2016-03-30 03:18, Daniel Pocock wrote: > Hi all, > > Has anybody been

Re: [Discuss-gnuradio] comparing SDR upconverters, thermal stability

Hi Daniel, haven't made experience with any of these upconverters; but: The really temperature-sensitive aspect of an upconverter is probably the oscillator, not the mixer. So the trick might really be keeping your upconverter in the same environment as your SDR receiver (assuming both don't

Re: [Discuss-gnuradio] Rx overflow problem related with sample rate

Dear Marcus, Thanks for your help. I'm tried to understand your advices about interrupt coalescing and I changed interrupt coalescing options My default setting like below: Coalesce parameters for eth0: Adaptive RX: off TX: off stats-block-usecs: 0 sample-interval: 0 pkt-rate-low: 0

[Discuss-gnuradio] gr-radar make problem

Hi all, I tried to build gr-radar master branch but I got the error: /home/mostafa/RADAR/gr-radar-master/lib/usrp_echotimer_cc_impl.cc: In member function ‘void gr::radar::usrp_echotimer_cc_impl::receive()’:

[Discuss-gnuradio] comparing SDR upconverters, thermal stability

Hi all, Has anybody been using any of the upconverters for SDR and has anybody made any comparison of them? I've seen some comments suggesting that many of the low cost models have poor thermal stability[1], has anybody seen problems with this in practice for receiving modes like SSB on

[Discuss-gnuradio] Setting cmake variable with pyBOMBS

Hi, I installed gnuradio and gr-osmosdr using the latest pyBOMBS from source. However none of the hardware directories got configured with -DINSTALL_UDEV_RULES=ON. Is there a pybombs config command that I can use to set this cmake option globally ? I do not want to cd into each of the build

Re: [Discuss-gnuradio] implementation of tdma using USRPs

Thanks for your answer, Derek. I got an attenuator between them. Maybe i can ask in a different direction: I got problems with the virtual interfaces provided by tunnel.py. Do I really need them? In GRC there are the adresses of the USRPs inside the USRP-source/sink-block, not any virtual