Re: explaining i/q

[Anon Lister]

Oops small correction, prior to decimate by 2 in the conversion, you have to 
low pass filter by fs/4. (Or use a decimating filter)

Whoops.

-
Anon

> On Nov 4, 2020, at 08:47, Anon Lister  wrote:
> 
> Now decimate by two since you have two empty halves of visible bandwidth at 
> the edges.

Re: explaining i/q

[Anon Lister]

> On Nov 4, 2020, at 07:13, Fons Adriaensen  wrote:
> 
> Whenever I have to explain some DSP principles, I start with
> the complex valued version, and then showing the real-valued
> one as a special case.

This is absolutely correct here. If they are learning gnuradio, they obviously 
want to do digital signal processing. Much of DSP is far easier when you have a 
center frequency of 0hz and your visible bandwidth is = to your sample rate. 
(Not 2x as required by real sampling)

How about a view of how you convert one representation to the other:
Take the real values(sampled to meet nyquist, at 2x the desired bandwidth, or 
max frequency), and insert a 0 every other sample. Treat every pair real, 0 as 
a one complex sample.

There is fundamentally no change here yet except to double the data storage 
requirement. These however are now complex values. 

Now, since you can “use” the negative frequency space, since it no longer is 
required to be mirror image of the positive, you can(circularly!) shift all 
frequencies by -1/4 the sampling rate. 

This will give still not alter the actual information present, merely shift all 
frequencies present halfway into the now usable negative frequency axis. They 
are NO LONGER MIRRORS. 

Now decimate by two since you have two empty halves of visible bandwidth at the 
edges. You now represent a range (complex)[-bandwidth/2, bandwidth/2] as 
opposed to (real)[0, bandwidth*2]

This process is entirely reversible, just do the steps backwards, (interpolate 
by 2, shift by Fs/4, drop the complex part (now 0)).

Both require the same storage, and can view the same bandwidth. Real needs 2x 
samples per bandwidth, in complex visible bandwidth = sample rate, but you 
store two values per sample. 

From a storage perspective, they are entirely equivalent. It’s not that you are 
taking extra samples or whatever you said. To use ham numbers: instead of 
storing a 48khz real file representing 24khz of visible bandwidth from 0 to 
48000hz, you store a 24k file representing -12k to 12k. In both cases you have 
24k of usable bandwidth, and use the same number of bytes to store it. 

The advantage of using complex is that the maths behind many DSP operations are 
vastly simplified by having the center frequency at 0 and bandwidth = to sample 
rate(and due to other properties of complex numbers). For example, most 
filtering now is simply a low pass filter, symmetric around 0 as opposed to 
band pass(composed of a low and a high). 
Am detect is just squaring the complex samples.
Fm detect is just calling atan2 on the quardrature components (and optionally 
rescaling)
Etc...

(Weather you think one representation or the other is more fundamental is 
largely due to your background. I’m of the opinion that complex is the more 
fundamental representation of an electromagnetic wave, the quantum mechanical 
representation is complex too, real is just an inconvenient projection in the 
middle introduced by the fact that we measure via electrical voltage on a wire, 
necessitating doubling our sample rate to recover the underlying wave(still 
with a phase ambiguity), but that’s opinion)

-
Anon

Re: explaining i/q

[Anon Lister]

I always come back to the Lyons explaination: the pictures really help for the 
visual learners among us. If you did a workshop I’d definitely include a link 
to this in reference material:

http://www.dspguru.com/files/QuadSignals.pdf

There’s actually some of us who don’t come from formal electrical engineering 
backgrounds who learned this first and find equations and such more difficult 
when expressed in the “real“ interpretation of a signal. Heh.



> On Nov 2, 2020, at 18:06, Kristoff  wrote:
> 
> Hi all,
> 
> I was watching the webinar of Heather on GNU Radio today, when it came to me 
> that one of the most difficult part doing a presentation of GNU Radio is the 
> data-types, .. and especially these 'complex numbers'.
> The problem, or at least for me, is that when you mention 'GNU Radio complex 
> numbers', you also have to mention iq-signals, which is a topic that is very 
> difficult to explain in 10 seconds to an audience who has never seen anything 
> about i/q sampling before.
> 
> 
> I have been thinking on how to explain the concept of I/Q signalling in just 
> a few lines, e.g. in the context of -say- a workshop on GR.
> 
> 
> I have this idea in my head:
> 
> Statement:
> The main difference between sampling with reals ('floats') and i/q sampling 
> with complex numbers, is that the latter does not only provide the  
> instantaneous value (voltage) of a signal at a certain point of time, but 
> also includes phase information (i.e. the slope of the signal at that point).
> 
> 
> To make this visual:
> Take half a sine-wave and plot it out for every 45 degrees.
> This gives you 5 points: 0 (0 degrees), sqrt(2)/2 (45 degrees), 1 (90 
> degrees), sqrt(2)/2 (135 degrees) and 0 (180 degrees).
> 
> Now look at the 2nd and the 4th point (45 degrees and 135 degrees), if you 
> sample this using only real/float values, these two points are exactly the 
> same (sqrt(2)/2). Just based on these values by themselves (i.e. remove all 
> other points from the graph), there is no way you can tell that at the first 
> point (45 degrees) the graph was going up, while at the 135-degrees point the 
> graph was going down.
> 
> So, ... what i/q sampling does, is for every point "x", it not only provide 
> the value of the graph at that point of time, but also information of the 
> slope of the graphs at that time.
> 
> 
> This also explains while i/q sampling is done by not just taking the value of 
> a signal at point "t", but also at 1/4 period later (which is the information 
> you need to determine the 'slope' of that graph at point 't')
> 
> 
> So, ... is this statement correct?
> 
> If it is more-or-less correct and it can help provide a basic mental image of 
> the concept of i/q sampling, I would be more then happy! :-)
> 
> 
> 
> 
> 73
> kristoff - ON1ARF
> 
> 
> 
> 

Re: [Discuss-gnuradio] existing GUI for gnuradio?

[Anon Lister]

Check out gqrx, it uses gnuradio behind the scenes and should do what you
want. It should be in the repos assuming your using something like Debian
or Ubuntu.

On Sun, Nov 11, 2018, 19:44 Doug  Hi, all--
>
> I am new to gnuradio. I have an RTL+SDR module that includes a mixer and a
> 100 MHz oscillator to tune 100 KHz to 1.7 GHz, with a solid state switch
> and filters, using "R829T2 Tuner"--
>
> this printed on a yellow tag--on a block called SDR.RTL 2832 UNIT.
>
> I looked at the introductory information, but it is really no help to me.
> I haven't coded anything in over 20 years, and then in Pascal and BASIC,
> and I did look at Python some years ago,
>
> but decided that anything that depended on specific indents was not for
> me. I might add that I am now 81 years old.  I did RF engineering, not
> software, when I was employed.
>
> I would really* really* like an on-screen GUI which would allow me to see
> a spectrum of signals, tune to one and listen to it in CW, SSB, NBFM or
> WBFM. If guiradio has such an app
>
> pre-existing that will run on an rpm-based Linux machine, I would like to
> have a copy, please. If only in DEB format, I will try to convert it via
> alien.
>
> If guiradio does not have such an app, do you folks know of any Linux
> program that does? (I know that there are all sorts of Windows programs,
> but I'm trying to avoid Windows and
>
> all its keep-outs and problems.)
>
> Thanx--doug
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Error: Template 'vector' undefined.

[Anon Lister]

I'll also point out that the swig file referenced is located in the system
install path. So if you are using a pybombs install of source build, swig
is likely picking up some files from an apt install, which could be causing
issues.

On Fri, Aug 3, 2018, 10:39 Michael Dickens 
wrote:

> Could be that the gnuradio reinstall didn't get all of the files in place.
> Could be that your modifications to the gr-howto do something strange for
> SWIG purposes. Could be something entirely unexpected. Really hard to know
> without source code, a logfile, and info about your host computer: OS (name
> and version), compiler (name and version), GNU Radio (version and how
> installed). Sorry I can't provide more specific help. - MLD
>
> On Thu, Aug 2, 2018, at 6:34 PM, Linda20071 wrote:
>
> Reinstalled the workspace for gnuradio. Tried a test on the new workspace
> with the howto example, but didn't create the Python QA test file. Instead,
> I directly modified the "square_ff_impl.cc" file. "cmake" command has
> passed. While doing "make" command, I got:
>
> Swig source
> /usr/include/gnuradio/swig/pmt_swig.i:50: Error: Template 'vector'
> undefined.
> ..
>
> In the pmt_swig.i, there are lines:
>
>
> %include 
> %template(pmt_vector_int8) std::vector;
> %template(pmt_vector_uint8) std::vector;
> %template(pmt_vector_int16) std::vector;
> %template(pmt_vector_uint16) std::vector;
> %template(pmt_vector_int32) std::vector;
> %template(pmt_vector_uint32) std::vector;
> %template(pmt_vector_float) std::vector;
> %template(pmt_vector_double) std::vector;
> %template(pmt_vector_cfloat) std::vector< std::complex >;
> %template(pmt_vector_cdouble) std::vector< std::complex >;
>
> Being able to make it work before in another workspace. It looks like no
> changes in the swig. Does anybody know where the real problem is?
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] how to read .dat file saved via the file sink

[Anon Lister]

Incase you installed from apt, you can download a copy of the file from
here:

https://github.com/gnuradio/gnuradio/tree/master/gr-utils/octave



On Thu, Aug 2, 2018, 11:22 Linda20071  wrote:

> I simply don't have anything related to read_complex_binary.m in my
> utilities folder
> (/usr/include/boost/geometry/index/detail/rtree/utilities). I am not sure
> if I am the only one who has such an issue.
>
> On Tue, Jul 31, 2018 at 1:24 PM, sumit kumar  wrote:
>
>> There is an octave script in gnuradio utilities. read_complex_binary.m
>> It will show you the IQ data
>>
>> On Tue, 31 Jul 2018, 19:22 Linda20071,  wrote:
>>
>>> I saved the transmitted complex signal (I/Q data) in a .dat file using
>>> the file sink. How could I read the I/Q data in this saved .dat file?
>>>
>>> Thanks in advance!
>>> ___
>>> Discuss-gnuradio mailing list
>>> Discuss-gnuradio@gnu.org
>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>
>>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Too many ooooooooooooo

[Anon Lister]

Try using hackrf_transfer to save a recording to /dev/null.

If this is successful, then move on to saving the recording to disk. If
that is not successful, then the issue is saving to disk. If it is then you
have now successfully recorded at 8 Mhz.

On Sun, Apr 8, 2018, 10:40 Juan Antonio  wrote:

> The problem seems every time I raise the sample rate above 8 mhz
> approximately, for example when I record a dvb-t signal with gqrx.
>
> The SDR is a hackrf and, at the moment I am finding myself with the 
> because I am only recording, if I tried to do another type of operations I
> am almost sure that other types of bottleneck problems would appear, ,
> etc ...
>
> If I try to use 16 mhz to avoid dc offset, the problem is multiplied by two
>
> Best regards
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Best in-tree blocks for clock recovery of 8FSK

[Anon Lister]

I don't know if you saw his presentation but Andy Walls did a talk on the
new clock recovery block he wrote to address issues he had with existing
ones. I believe it's in tree now?

https://www.gnuradio.org/wp-content/uploads/2017/12/Andy-Walls-Samples-to-Digital-Symbols.pdf

On Mon, Apr 2, 2018, 08:55 Adrian Musceac  wrote:

> I should add that the main problem I face is getting it synchronized fast
> enough for short bursts.
>
> Adrian
>
> On April 2, 2018 11:54:21 AM UTC, Thomas Habets  wrote:
>>
>> I just seem to recall that being said.
>>
>> I've used M successfully in the past, but it does require some
>> massaging of the data to not be "square wave" before it'll work. Also does
>> it work (well) for M-FSK?
>>
>> On 2 April 2018 at 11:16, Adrian Musceac  wrote:
>>
>>> Hi,
>>>
>>> Why is the M algorithm discouraged?
>>> I use successfully both in FSK and PSK demodulators. It seems to perform
>>> fine.
>>>
>>> Regards,
>>> Adrian
>>>
>>>
>>> On April 2, 2018 8:48:00 AM UTC, Thomas Habets  wrote:

 Hi.

 As an experiment I'm trying to decode an FT8 signal I've captured. I've
 gotten far enough that I can clearly see the packet (
 https://blog.habets.se/tmp/ft8_packet.png), but now I want to actually
 turn that into bits.

 I know it's 8FSK (the above screenshot is quad demod of that), but I
 have a few questions on clock recovery:

 * Is the GFSK block only for BFSK? If so then that's out.
 * Is there a "best" clock recovery block nowadays? I seem to recall
 "Clock Recovery MM" being discouraged in favor of "Polyphase Clock Sync".
 * I'm trying to read up on the parameters Polyphase Clock Sync wants,
 but any pointers would be helpful.
 * Would it be a good idea to throw in a costas loop for frequency
 tuning?
 * Does Polyphase Clock Sync have the same dislike of "staircase"
 inputs? That is, I should try to make the center of the bits more "pointy"?
 (e.g. lowpass filter them)

 I've done some custom OOT decoders before, so I'm not shy about that.
 Maybe the best thing is some whole-packet clock recovery[1]. But if I just
 write a block that takes the quad demod (see above screenshot) and finds
 the "platforms", outputting a message that is a list of floats, and then
 another block that takes a list of floats and the number 8 and decodes it
 as 8FSK, well it seems like I may be reimplementing things where I'm
 guessing someone might say "oh just use this block".

 Also for experimentation and my own understanding I'd like to turn it
 into bits using in-tree blocks, if possible.

 Maybe a correct Polyphase Clock Sync of the quad demod followed by a
 Constellation decoder? I could use the float as the phase, with magnitude
 1. Does that make sense? Is it a good idea?

 What I have so far is:
 Data:
   https://blog.habets.se/tmp/ft8-burst-10k.raw (10k samp_rate)

 GRC:
   https://blog.habets.se/tmp/ft8_decode.grc

 Screenshot:
   https://blog.habets.se/tmp/ft8_decode_grc.png
 (everything off-screen to the right is failed clock recovery
 experiments)

 Quad demod
   https://blog.habets.se/tmp/ft8_packet.png


 [1] Like https://www.youtube.com/watch?v=rQkBDMeODHc which I turned
 into
 https://github.com/ThomasHabets/radiostuff/blob/master/gr-habets/python/magic_decoder.py

 --
 typedef struct me_s {
  char name[]  = { "Thomas Habets" };
  char email[] = { "tho...@habets.se " };
  char kernel[]= { "Linux" };
  char *pgpKey[]   = { "http://www.habets.pp.se/pubkey.txt; };
  char pgp[] = { "9907 8698 8A24 F52F 1C2E  87F6 39A4 9EEA 460A 0169" };
  char coolcmd[]   = { "echo '. ./_&. ./_'>_;. ./_" };
 } me_t;

>>>
>>> ___
>>> Discuss-gnuradio mailing list
>>> Discuss-gnuradio@gnu.org
>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>
>>>
>>
>>
>> --
>> typedef struct me_s {
>>  char name[]  = { "Thomas Habets" };
>>  char email[] = { "tho...@habets.se " };
>>  char kernel[]= { "Linux" };
>>  char *pgpKey[]   = { "http://www.habets.pp.se/pubkey.txt; };
>>  char pgp[] = { "9907 8698 8A24 F52F 1C2E  87F6 39A4 9EEA 460A 0169" };
>>  char coolcmd[]   = { "echo '. ./_&. ./_'>_;. ./_" };
>> } me_t;
>>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Osmocom Source Block

[Anon Lister]

Not really an answer, more of an alternate solution, but if you use gqrx,
(set driver string to "driver=lime,soapy=0") gqrx should provide a dropdown
to choose antennas from whatever magic was deduced by querying osmocom to
query soapy to query the limesuite driver, and return a list of antennas.

On Oct 24, 2017 10:04 AM, "Ricardo Nuszkowski" 
wrote:

> Hello,
>
> I am trying to test our setup to see if there is any issues and I am not
> getting any results for FFT and waterfall plot. I am using a LimeSDR
> connected to a PC running the latest version of Debian. The LimeSDR is
> connected to an antenna a coworker brought in which operates in the
> 162.550MHz range. We have it connected to the LNAW port on the LimeSDR.
>
> I was wondering what do I input on the antenna channel parameter. I have
> inputed “LNAW” and that doesn’t seem to work. When I tested out a 2.4GHz on
> the LNAH_1 channel, I inputed LNAH for the channel0 antenna and still got
> nothing on our FFT and waterfall plots.
>
> This is an screenshot of our screen when attached to 2.4 GHz antenna.
> Sorry about the blurry image.
>
> Respectfully,
> Ricardo
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] RuntimeError: udp_sink(1): insufficient connected output ports

[Anon Lister]

Yeah I was getting crashes in apps like gqrx. Took a few days to debug.
There were some recent changes to logging. Log4cpp is going to be a
required dep soon, so might as well install it anyway, but in the interim
there is some more commentary on the issue here:

https://github.com/gnuradio/gnuradio/issues/1383

On Sep 1, 2017 7:41 PM, "Mike Rex"  wrote:

> Ron,
>
> You can take these caps as enthusiastic shouting:  THANK YOU, THANK YOU,
> THANK YOU.  That fixed my issue. I really needed that to enjoy my weekend :)
>
> Glad you also mentioned needing to rebuild GNU Radio.  That really was
> necessary.
>
> Have a really great weekend!
>
> Thanks,
> Mike
>
>
>
> On 2017-08-31 8:49 PM, Ron Economos wrote:
>
>> I've been having troubles with the master branch lately myself. I've
>> traced it to having liblog4cpp5 installed or not. If liblog4cpp5 is NOT
>> installed, GNU Radio seems oddly unstable, especially for OOT modules. Note
>> that build-gnuradio does NOT install liblog4cpp5.
>>
>> Try installing liblog4cpp5-dev (sudo apt-get install liblog4cpp5-dev) and
>> rebuilding GNU Radio.
>>
>> Ron
>>
>> On 08/31/2017 08:17 PM, Mike Rex wrote:
>>
>>> gnuradio version: 3.7.12git-218-g811bee8c installed from build-gnuradio
>>> script.
>>> Dev PC: Xubuntu 16.04 running in VM Workstation  (mentioned because some
>>> python bugs are hypervisor effected only)
>>> Problem: I am getting errors when running flow graphs in GRC after
>>> adding variables to the udp_sink_impl.h file.
>>>
>>> I've been struggling all week making changes to an existing project (
>>> https://github.com/ghostop14/gr-grnet) that are alternate versions of
>>> TCP/UDP sink/source. I planned on starting with this project, adding in
>>> some missing bits from the gr-blocks UDP sink/source, and then finally
>>> modifying it for our particular application (raw protocol instead of UDP
>>> with IP).
>>>
>>> I'm having problems adding variables to udp_sink_impl.h/udp_source_impl.h
>>> without getting errors when running the flow graph. I may be overlooking
>>> something simple, but I'm really just trying to append the new variable
>>> following the usage of other existing variables.  I think there is either
>>> something wrong with my python 2.7 on my xubuntu 16.04 PC, or there needs
>>> to be additional memory allocated somewhere. Typically, when adding a new
>>> variable to udp_sink_impl.h, I'll get the following, where the "NUM needed"
>>> varies from run to run:
>>>
>>> Traceback (most recent call last):
>>>   File "/home/mike/top_block.py", line 110, in 
>>> main()
>>>   File "/home/mike/top_block.py", line 99, in main
>>> tb.start()
>>>   File "/usr/local/lib/python2.7/dist-packages/gnuradio/gr/top_block.py",
>>> line 109, in start
>>> top_block_start_unlocked(self._impl, max_noutput_items)
>>>   File "/usr/local/lib/python2.7/dist-packages/gnuradio/gr/runtime_swig.py",
>>> line 5681, in top_block_start_unlocked
>>> return _runtime_swig.top_block_start_unlocked(r, max_noutput_items)
>>> RuntimeError: udp_sink(1): insufficient connected output ports (54929632
>>> needed, 0 connected)
>>>
>>>
>>> Other times, the flowgraph will start and then crash after the private
>>> constructor finishes and the error will be related to python2 and corrupted
>>> size vs prev_size...
>>>
>>> *** Error in `/usr/bin/python2': corrupted size vs. prev_size:
>>> 0x03428620 ***
>>>
>>> Comment out the variable, and then it runs every time.  Geez, while
>>> writing this email, I restored the variable to get the corrupted size
>>> error.  Pressed Play again and it ran.  Sometimes 2/3 tries works, and
>>> other times 2/3 tries gets the python error (I did not notice that behavior
>>> until just now). Added another variable, and then it went up to like 1 in 6
>>> worked or 1 in 10 worked, and with another variable added, it doesn't ever
>>> work again.  So this looks like a memory allocation/corruption problem that
>>> somehow randomly works.
>>>
>>> When testing block changes, what is the correct process to ensure
>>> gnuradio sees the newest installed code only? I've been doing:
>>>
>>> (current dir is build)
>>> sudo make uninstall && sudo ldconfig && cd .. && rm -rf build
>>> mkdir build
>>> cd build
>>> cmake -DCMAKE_BUILD_TYPE="Debug" ../
>>> make -j8 && sudo make install && sudo ldconfig
>>>
>>> Is there something I'm missing that completely removes old stuff or
>>> failing to import all the new stuff?
>>>
>>> I do have another local repo where I have many more changes and the
>>> payload_size is working (don't know what changed when it suddenly started
>>> working), but further adding variables like 'eof' result in the error in
>>> question.  The simplest changes I can make and reproduce this can be seen
>>> here: https://github.com/ghostop14/gr-grnet/compare/master...BCITM
>>> ike:master. I'm changing 4 files:
>>> modified: grc/grnet_udp_sink.xml
>>> modified: include/grnet/udp_sink.h
>>> modified: 

Re: [Discuss-gnuradio] Qt GUI: Water falls the wrong direction

[Anon Lister]

I fully support calling it  the water rise sink.

I once implemented a waterfall, was very proud of my implementation. It was
smooth, handled high bandwidths without taxing CPU. Showed to boss... I got
a blank stare "Uhh, well I've never seen one going up... It's going the
wrong way."

:(

Wish I had the wit to just tell him it was a waterrise sink, and smile.

Frankly the industry needs a shakeUP anyway. :P

On Aug 25, 2017 5:37 PM, "Martin Braun"  wrote:

> Kartik,
>
> I was joking about renaming it. Waterfall plot is a common term, even if
> it's upside down, people would get more confused with any other name.
>
> Cheers,
> Martin
>
> On 08/24/2017 04:00 PM, Kartik Patel wrote:
> > Hi.
> >
> > I was wondering why it's called Waterfall and now I understand it was a
> > mistake. :P
> >
> > Anyways, I can look into it sometime in next week if we don't want to
> > simply rename the plot. I am not sure if there's just a parameter that
> > we need to change or there is something more we may have to do.
> >
> > Thanks.
> >
> > Regards,
> > Kartik Patel
> >
> >
> > On Thu, Aug 24, 2017 at 3:12 PM, Martin Braun  > > wrote:
> >
> > On 08/24/2017 03:16 AM, Marcus Müller wrote:
> > > Hi Folks,
> > >
> > > while discussing the DABstep GUI's developer mode, we noticed that
> the
> > > QT GUI Waterfall sink doesn't fully deserve that name. It's a
> waterrise
> > > sink:
> > >
> > > http://marcus.hostalia.de/waterfall.webm
> > 
> > >
> > > Is there a (maybe unexposed) property to change the direction of
> flow?
> >
> > Seems easier to rename it :)
> >
> > -- M
> >
> >
> > ___
> > Discuss-gnuradio mailing list
> > Discuss-gnuradio@gnu.org 
> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> > 
> >
> >
> > ᐧ
> >
> >
> > ___
> > Discuss-gnuradio mailing list
> > Discuss-gnuradio@gnu.org
> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> >
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] GPS tracking on a map over mobile app software using RF

[Anon Lister]

Maybe something like this would fill your requirements. Transmits in MURS
freqs. Pro version looks to have an SDK.

https://www.gotenna.com/pages/gotenna

On Aug 14, 2017 12:33 PM, "Antti Ruohonen"  wrote:

Thank you for your reply, Marcus. Your suggestion of an attachable device
is totally fine, actually very good idea.

So, this SDR device would be the medium to the software radio (app in the
mobile phone), which controls the device. How would this scenario be
possible to achieve the goal? Goal is to send (GPS) data over the radio
frequencies to update the app's map. :)


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Stuck at WBFM Project :

[Anon Lister]

Idk if anyone mentioned, but things like samp_rate are just variables, they
do not propegate through the flowgraph and change based on the blocks they
go through. The flowgraph doesn't attach special meaning to samp_rate, it's
just a default param in alot of blocks. You could call it AshesFavVariable
and the flowgraph would work the same. In your case I think the sinks are
just defined to be samp_rate, so they will display whatever you set
samp_rate to be. Ideally you'd make a decimation variable, set it to say 4,
the set the Sample Rate parameter on downstream blocks to
samp_rate/decimation.

On Aug 13, 2017 12:15 PM, "Ash SDR"  wrote:

> Thanks everyone and sorry , I couldn't reply you all for inputs you gave
> me.  For Now , I kept aside the WBFM project which I asked about and
> working on the Guided Tutorials from GNU Radio and also tutorials from
> greatScott gadgets video series.
>
> I have a dumb question about Rational Resampler...Here is the snapshot
> from tutorials website..
>
> As far as I understand , the Rational resampler  modifies the sampling
> rate of the incoming signal based on Interpolation (or) decimation
> factor  Is it something like this
>
>
> *If my incoming Signal is of 10KHz  with Sampling Rate of 50 KHz  ,
> Rational Resampler (Interpolation : 4 , Decimation : 1)  gives me the
> output as signal of 10KHz and Sample Rate of 50*4 = 200 KHz ??*
>
> Am I Interpreting it correctly... ??
>
> If thats the case , In the following snapshot ,  Signal of 1KHz of 48KHz
> Sample rate is interpolated by factor 4 ,   Then Output Sampling Rate
> should be 48*4 = 192KHz which is much higher than the Required Nyquist rate
> , But the Frequency sink block shows frequency component at 0.25 Hz... Is
> it because of the "samp_rate" variable set in QT GUI Frequency Sink..
>
>
>
>
>
> [image: tutorial_two_4.png][image: resampling_output.png]
>
> On Tue, Aug 8, 2017 at 4:41 PM, Cinaed Simson 
> wrote:
>
>> On 08/07/2017 07:55 PM, Ash SDR wrote:
>> > Hello Everyone ,
>> >
>> > I am a GNU Radio beginner trying to implement Wideband FM Project and
>> > transmit it to my FM receiver at a very lower power.  I am choosing a
>> > frequency in a FM band such that my receiver is not picking anything
>> > from that station/..
>> >
>> > Attached is GRC file which i am working on .and the music file which i
>> > am trying to transmit..
>> >
>> > Can anyone please tell me where I am messing up ?
>>
>> Remove the first rational resampler. Set your audio rate to 48000 Hz,
>> and quadrature rate 192000 Hz.
>>
>> In the second re-sampler set the interpolation to 800 Hz and the
>> decimation to 192000 Hz.
>>
>> I'm going to guess you're using the HackRF based on your default values
>> (except for the transmit RF gain which should be 1.)
>>
>> I strongly recommend you spend some time on the going through the
>> tutorials at
>>
>>   http://www.greatscottgadgets.com/sdr
>>
>> and learn something about your hardware and how to build WBFM receiver
>> befor you try to transmit.
>>
>> -- Cinaed
>>
>>
>>
>>
>> >
>> >
>> > As a beginner , my learning curve is from implemented projects ,
>> > University lectures which are available on-line .. This one is from a
>> > book which i am using to get basic understanding ..
>> >
>> >
>> > Thanks
>> > Ash
>> >
>> >
>> > ___
>> > Discuss-gnuradio mailing list
>> > Discuss-gnuradio@gnu.org
>> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>> >
>>
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Adding Attenuation in GNU radio

[Anon Lister]

You can also check out the channel model block in GRC, there's also several
other useful blocks under the imparements category that may be useful for
modeling different kinds of environments like multipath or doppler.

On Jul 16, 2017 6:20 PM, "Jose Ruvalcaba"  wrote:

> Hi Marcus,
>
> Thanks for your response. I'm trying to make a channel simulator where my
> signal going into the USRP gets attenuated by free space path loss.
> Typically, I know that this is done through the use of hardware, like fixed
> attenuators, but I wanted to go into an all DSP approach with the use of
> GNU radio.
>
> Regards,
> Jose
>
> On Sun, Jul 16, 2017 at 3:38 AM, Marcus Müller 
> wrote:
>
>> Hi Jose,
>>
>> yep, multiply const with a real value |·| < 1 would be **equivalent** to
>> an analog attenuator.
>>
>> anyway, it's very uncommon to do such an operation in DSP, unless you
>> need a fair comparison between different signals or such.
>>
>> Maybe you'd want to explain why you want to do that?
>>
>> Best regards,
>>
>> Marcus
>>
>> On 07/16/2017 07:23 AM, Jose Ruvalcaba wrote:
>>
>> Hello,
>>
>> This may seem like a really simple question, but If I wanted to attenuate
>> my signal coming out from a USRP source block in GRC, say by 80 dB,, how
>> would I go ahead and do that? Would I just add a multiply constant block
>> after my USRP source block to scale down the incoming signal's amplitude?
>> Would I be able to check my attenuated signal through the QT frequency plot
>>  block?
>>
>>
>> Thanks,
>> Jose
>>
>>
>> ___
>> Discuss-gnuradio mailing 
>> listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Crash of gqrx in gr block deallocator when building gnuradio w/o log4cpp on Ubuntu 16-17

[Anon Lister]

Alrighty, thanks for another data point. If I end up trying to debug
further it'll be good to know.

On Jul 14, 2017 2:54 PM, "Geof Nieboer" <gnieb...@corpcomm.net> wrote:

> Doing this from memory, but as I recall the corruption happens because
> iqbal/gqrx libraries believe sizeof(block) is different than what
> gnuradio's libraries believe.  So one library malloc's a different amount
> of memory than the other library uses and frees.  If during debugging you
> call sizeof() from different parts of the call stack, it should become
> clear.
>
> The problem I found is that if logger.h is included without ENABLE_GR_LOG,
> it defines logger_ptr as a void*, whereas with it enabled and without
> log4cpp it defines it as a std::string... and those are not guaranteed to
> be the same size.
>
> Now having said that, this was on Windows, so perhaps on GCC
> sizeof(std::string) == sizeof(void*) and you are facing a completely
> different issue.  But it sounds likely it's the same.  Like yourself, I
> didn't have time to dig any further as to what code change caused this
> issue to surface at the time.
>
> Geof
>
>
> On Fri, Jul 14, 2017 at 11:07 AM, Anon Lister <listera...@gmail.com>
> wrote:
>
>> Hmm, so in my last test I completely skipped gr-iqbal. I had gnuradio,
>> osmosdr with only file playback and python modules enabled, and gqrx.
>> You'll still get a crash if you start file playback, then goto demod and
>> change the type to nbfm, then wbfm. Believe it hits some cout in gnuradio
>> like "Resampling audio from 96000 -> 48000."
>>
>> Given that line is just a cout, I'm geussing whatever logging facility is
>> hijacking cout and leaves it in a bad state after some destructor is
>> called.
>>
>> Also, if you build with -fsanitize=address, you do see that there's a
>> memory corruption way before that destructor gets called, but I'm not sure
>> if it's related.
>>
>> I gotta submit a PR for something in gr-dtv this weekend, so I might dig
>> in more while I have things setup.
>>
>>
>> On Jul 14, 2017 9:50 AM, "Geof Nieboer" <gnieb...@corpcomm.net> wrote:
>>
>> Don,
>>
>> I ran into the same exact issue while updating the windows build scripts.
>>
>>
>> Another fix is to manually define ENABLE_GR_LOG during build of iqbal and
>> gqrx to work around the issue without installing log4cpp.  It appears to
>> just affect those two so far.  The windows build does not currently include
>> log4cpp on 3.7.x builds.
>>
>> Geof
>>
>>
>> On Thu, Jul 13, 2017 at 10:55 AM, Anon Lister <listera...@gmail.com>
>> wrote:
>>
>>> Hey all, just an FYI,
>>>
>>> I don't have the time to go figure out what exactly is causing it, but
>>> if you build from source with the log4cpp dep missing after a merged PR in
>>> April/May(that fixed some log4cpp headers), then in certain circumstances,
>>> you will get a segfault, due to a heap buffer overflow.
>>>
>>> There are a few code paths that crash. If gr-iqbal is installed, it will
>>> crash right on opening gqrx. If not it will crash when switching demod
>>> type.
>>>
>>> I believe both cases a call to a destructor on at least 1 block,
>>> followed by some kind of printed message is the culprit.
>>>
>>> Took me a few days to find the "fix", as I thought it was related to
>>> some new hardware I had, but then upon pulling I was able to reproduce on
>>> my normal workstation and it went away when I installed log4cpp and
>>> recompiled GR. Just though I'd throw this out Incase anyone else was having
>>> the issue.
>>>
>>> I'll try to file a bug report, but ideally I would like to include more
>>> information and I don't have time for that atm, and from what I understand
>>> it might be OBE when 3.8 comes out as that's getting added as a required
>>> dependency.
>>>
>>> I have not reproduced the crash in anything besides gqrx, but it seems
>>> pretty solid that it's a bug in GR. I bet other apps that reconfigure
>>> flowgraphs like shinysdr would trigger it as well.
>>>
>>> -Don
>>>
>>> ___
>>> Discuss-gnuradio mailing list
>>> Discuss-gnuradio@gnu.org
>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>
>>>
>>
>>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Crash of gqrx in gr block deallocator when building gnuradio w/o log4cpp on Ubuntu 16-17

[Anon Lister]

Hmm, so in my last test I completely skipped gr-iqbal. I had gnuradio,
osmosdr with only file playback and python modules enabled, and gqrx.
You'll still get a crash if you start file playback, then goto demod and
change the type to nbfm, then wbfm. Believe it hits some cout in gnuradio
like "Resampling audio from 96000 -> 48000."

Given that line is just a cout, I'm geussing whatever logging facility is
hijacking cout and leaves it in a bad state after some destructor is
called.

Also, if you build with -fsanitize=address, you do see that there's a
memory corruption way before that destructor gets called, but I'm not sure
if it's related.

I gotta submit a PR for something in gr-dtv this weekend, so I might dig in
more while I have things setup.


On Jul 14, 2017 9:50 AM, "Geof Nieboer" <gnieb...@corpcomm.net> wrote:

Don,

I ran into the same exact issue while updating the windows build scripts.

Another fix is to manually define ENABLE_GR_LOG during build of iqbal and
gqrx to work around the issue without installing log4cpp.  It appears to
just affect those two so far.  The windows build does not currently include
log4cpp on 3.7.x builds.

Geof


On Thu, Jul 13, 2017 at 10:55 AM, Anon Lister <listera...@gmail.com> wrote:

> Hey all, just an FYI,
>
> I don't have the time to go figure out what exactly is causing it, but if
> you build from source with the log4cpp dep missing after a merged PR in
> April/May(that fixed some log4cpp headers), then in certain circumstances,
> you will get a segfault, due to a heap buffer overflow.
>
> There are a few code paths that crash. If gr-iqbal is installed, it will
> crash right on opening gqrx. If not it will crash when switching demod
> type.
>
> I believe both cases a call to a destructor on at least 1 block, followed
> by some kind of printed message is the culprit.
>
> Took me a few days to find the "fix", as I thought it was related to some
> new hardware I had, but then upon pulling I was able to reproduce on my
> normal workstation and it went away when I installed log4cpp and recompiled
> GR. Just though I'd throw this out Incase anyone else was having the issue.
>
> I'll try to file a bug report, but ideally I would like to include more
> information and I don't have time for that atm, and from what I understand
> it might be OBE when 3.8 comes out as that's getting added as a required
> dependency.
>
> I have not reproduced the crash in anything besides gqrx, but it seems
> pretty solid that it's a bug in GR. I bet other apps that reconfigure
> flowgraphs like shinysdr would trigger it as well.
>
> -Don
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Crash of gqrx in gr block deallocator when building gnuradio w/o log4cpp on Ubuntu 16-17

[Anon Lister]

Hey all, just an FYI,

I don't have the time to go figure out what exactly is causing it, but if
you build from source with the log4cpp dep missing after a merged PR in
April/May(that fixed some log4cpp headers), then in certain circumstances,
you will get a segfault, due to a heap buffer overflow.

There are a few code paths that crash. If gr-iqbal is installed, it will
crash right on opening gqrx. If not it will crash when switching demod
type.

I believe both cases a call to a destructor on at least 1 block, followed
by some kind of printed message is the culprit.

Took me a few days to find the "fix", as I thought it was related to some
new hardware I had, but then upon pulling I was able to reproduce on my
normal workstation and it went away when I installed log4cpp and recompiled
GR. Just though I'd throw this out Incase anyone else was having the issue.

I'll try to file a bug report, but ideally I would like to include more
information and I don't have time for that atm, and from what I understand
it might be OBE when 3.8 comes out as that's getting added as a required
dependency.

I have not reproduced the crash in anything besides gqrx, but it seems
pretty solid that it's a bug in GR. I bet other apps that reconfigure
flowgraphs like shinysdr would trigger it as well.

-Don
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Problem with Pybombs install of gr-analysis

[Anon Lister]

Oh, and I configure passing -std=c++11 in cflags.

On Jun 7, 2017 8:45 PM, "Anon Lister" <listera...@gmail.com> wrote:

> FYI this has nothing to do with pybombs, I get it source building. I use
> specrec all the time for high bw writes, really wish there was a osmocom
> version of it for non ettus devices.
>
> Anyway, it looks like maybe something in uhd changed, prolly in the 3.10
> transition. I usually just replace the variable they are using with a
> std:atomic,replace Inc with ++, Dec with -- and the get call with
> just a regular =. Would be great for someone to fix it properly though.
> Looks like it's just a counter of the current buffer size that is shared
> by the reader and writer threads.
>
>
> On Jun 7, 2017 3:42 PM, "gump" <gumpgra...@gmail.com> wrote:
>
>> Just did a clean pybombs install, everything looks good so far.  Having
>> trouble with gr-analysis.  Can't get past this error.  Same error if I
>> try to compile it outside of pybombs.
>>
>> # pybombs install of UHD, GnuRadio and other items goes just fine.
>>
>> user@gump-Lenovo:~$ sudo sudo pybombs install uhd gnuradio gr-iqbal
>> gr-gsm libosmocore libusb osmo-sdr rtl-sdr fftw liquid-dsp
>> PyBOMBS - INFO - PyBOMBS Version 2.3.0
>> PyBOMBS.Packager.apt - INFO - Install python-apt to speed up apt
>> processing.
>> PyBOMBS.install_manager - INFO - Phase 1: Creating install tree and
>> installing binary packages:
>> DEPRECATION: The default format will switch to columns in the future.
>> You can use --format=(legacy|columns) (or define a
>> format=(legacy|columns) in your pip.conf under the [list] section) to
>> disable this warning.
>> The directory '/home/user/.cache/pip/http' or its parent directory is
>> not owned by the current user and the cache has been disabled. Please
>> check the permissions and owner of that directory. If executing pip with
>> sudo, you may want sudo's -H flag.
>> Reading package lists... Done
>> Building dependency tree
>> Reading state information... Done
>> The following package was automatically installed and is no longer
>> required:
>>   ubuntu-core-launcher
>> Use 'sudo apt autoremove' to remove it.
>> The following NEW packages will be installed:
>>   python-cairo-dev
>> 0 upgraded, 1 newly installed, 0 to remove and 4 not upgraded.
>> Need to get 429 kB of archives.
>> After this operation, 1,165 kB of additional disk space will be used.
>> Get:1 http://us.archive.ubuntu.com/ubuntu xenial/main amd64
>> python-cairo-dev all 1.8.8-2 [429 kB]
>> Fetched 429 kB in 0s (4,926 kB/s)
>> Selecting previously unselected package python-cairo-dev.
>> (Reading database ... 252906 files and directories currently installed.)
>> Preparing to unpack .../python-cairo-dev_1.8.8-2_all.deb ...
>> Unpacking python-cairo-dev (1.8.8-2) ...
>> Setting up python-cairo-dev (1.8.8-2) ...
>> Reading package lists... Done
>> Building dependency tree
>> Reading state information... Done
>> libqwt5-qt4 is already the newest version (5.2.3-1).
>> libqwt5-qt4 set to manually installed.
>> The following package was automatically installed and is no longer
>> required:
>>   ubuntu-core-launcher
>> Use 'sudo apt autoremove' to remove it.
>> 0 upgraded, 0 newly installed, 0 to remove and 4 not upgraded.
>> Reading package lists... Done
>> Building dependency tree
>> Reading state information... Done
>> The following package was automatically installed and is no longer
>> required:
>>   ubuntu-core-launcher
>> Use 'sudo apt autoremove' to remove it.
>> The following additional packages will be installed:
>>   libqwt-headers
>> The following packages will be REMOVED:
>>   libqwt5-qt4-dev
>> The following NEW packages will be installed:
>>   libqwt-dev libqwt-headers
>> 0 upgraded, 2 newly installed, 1 to remove and 4 not upgraded.
>> Need to get 103 kB of archives.
>> After this operation, 154 kB of additional disk space will be used.
>> Get:1 http://us.archive.ubuntu.com/ubuntu xenial/universe amd64
>> libqwt-headers amd64 6.1.2-5 [69.5 kB]
>> Get:2 http://us.archive.ubuntu.com/ubuntu xenial/universe amd64
>> libqwt-dev amd64 6.1.2-5 [33.5 kB]
>> Fetched 103 kB in 0s (1,050 kB/s)
>> (Reading database ... 252986 files and directories currently installed.)
>> Removing libqwt5-qt4-dev (5.2.3-1) ...
>> Selecting previously unselected package libqwt-headers.
>> (Reading database ... 252909 files and directories currently installed.)
>> Preparing to unpack .../libqwt-headers_6.1.2-5_amd64.deb ...
>>

Re: [Discuss-gnuradio] Problem with Pybombs install of gr-analysis

[Anon Lister]

FYI this has nothing to do with pybombs, I get it source building. I use
specrec all the time for high bw writes, really wish there was a osmocom
version of it for non ettus devices.

Anyway, it looks like maybe something in uhd changed, prolly in the 3.10
transition. I usually just replace the variable they are using with a
std:atomic,replace Inc with ++, Dec with -- and the get call with
just a regular =. Would be great for someone to fix it properly though.
Looks like it's just a counter of the current buffer size that is shared by
the reader and writer threads.


On Jun 7, 2017 3:42 PM, "gump"  wrote:

> Just did a clean pybombs install, everything looks good so far.  Having
> trouble with gr-analysis.  Can't get past this error.  Same error if I
> try to compile it outside of pybombs.
>
> # pybombs install of UHD, GnuRadio and other items goes just fine.
>
> user@gump-Lenovo:~$ sudo sudo pybombs install uhd gnuradio gr-iqbal
> gr-gsm libosmocore libusb osmo-sdr rtl-sdr fftw liquid-dsp
> PyBOMBS - INFO - PyBOMBS Version 2.3.0
> PyBOMBS.Packager.apt - INFO - Install python-apt to speed up apt
> processing.
> PyBOMBS.install_manager - INFO - Phase 1: Creating install tree and
> installing binary packages:
> DEPRECATION: The default format will switch to columns in the future.
> You can use --format=(legacy|columns) (or define a
> format=(legacy|columns) in your pip.conf under the [list] section) to
> disable this warning.
> The directory '/home/user/.cache/pip/http' or its parent directory is
> not owned by the current user and the cache has been disabled. Please
> check the permissions and owner of that directory. If executing pip with
> sudo, you may want sudo's -H flag.
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> The following package was automatically installed and is no longer
> required:
>   ubuntu-core-launcher
> Use 'sudo apt autoremove' to remove it.
> The following NEW packages will be installed:
>   python-cairo-dev
> 0 upgraded, 1 newly installed, 0 to remove and 4 not upgraded.
> Need to get 429 kB of archives.
> After this operation, 1,165 kB of additional disk space will be used.
> Get:1 http://us.archive.ubuntu.com/ubuntu xenial/main amd64
> python-cairo-dev all 1.8.8-2 [429 kB]
> Fetched 429 kB in 0s (4,926 kB/s)
> Selecting previously unselected package python-cairo-dev.
> (Reading database ... 252906 files and directories currently installed.)
> Preparing to unpack .../python-cairo-dev_1.8.8-2_all.deb ...
> Unpacking python-cairo-dev (1.8.8-2) ...
> Setting up python-cairo-dev (1.8.8-2) ...
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> libqwt5-qt4 is already the newest version (5.2.3-1).
> libqwt5-qt4 set to manually installed.
> The following package was automatically installed and is no longer
> required:
>   ubuntu-core-launcher
> Use 'sudo apt autoremove' to remove it.
> 0 upgraded, 0 newly installed, 0 to remove and 4 not upgraded.
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> The following package was automatically installed and is no longer
> required:
>   ubuntu-core-launcher
> Use 'sudo apt autoremove' to remove it.
> The following additional packages will be installed:
>   libqwt-headers
> The following packages will be REMOVED:
>   libqwt5-qt4-dev
> The following NEW packages will be installed:
>   libqwt-dev libqwt-headers
> 0 upgraded, 2 newly installed, 1 to remove and 4 not upgraded.
> Need to get 103 kB of archives.
> After this operation, 154 kB of additional disk space will be used.
> Get:1 http://us.archive.ubuntu.com/ubuntu xenial/universe amd64
> libqwt-headers amd64 6.1.2-5 [69.5 kB]
> Get:2 http://us.archive.ubuntu.com/ubuntu xenial/universe amd64
> libqwt-dev amd64 6.1.2-5 [33.5 kB]
> Fetched 103 kB in 0s (1,050 kB/s)
> (Reading database ... 252986 files and directories currently installed.)
> Removing libqwt5-qt4-dev (5.2.3-1) ...
> Selecting previously unselected package libqwt-headers.
> (Reading database ... 252909 files and directories currently installed.)
> Preparing to unpack .../libqwt-headers_6.1.2-5_amd64.deb ...
> Unpacking libqwt-headers (6.1.2-5) ...
> Selecting previously unselected package libqwt-dev.
> Preparing to unpack .../libqwt-dev_6.1.2-5_amd64.deb ...
> Unpacking libqwt-dev (6.1.2-5) ...
> Setting up libqwt-headers (6.1.2-5) ...
> Setting up libqwt-dev (6.1.2-5) ...
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> The following package was automatically installed and is no longer
> required:
>   ubuntu-core-launcher
> Use 'sudo apt autoremove' to remove it.
> The following additional packages will be installed:
>   liblog4cpp5v5
> The following NEW packages will be installed:
>   liblog4cpp5-dev liblog4cpp5v5
> 0 upgraded, 2 newly installed, 0 to remove and 4 not upgraded.
> Need to get 190 kB of archives.
> 

Re: [Discuss-gnuradio] USRP sink clock rate

[Anon Lister]

What is the difference between these two methods? I seem to be able to use
them interchangeably and was wondering the reason to prefer the args
string?

I calculate it based on a multiple of my sample rate in either case. (B2xx
if that matters)

On Jun 7, 2017 5:34 AM, "Derek Kozel"  wrote:

> Hello Kim,
>
> The first two rates (200e6 and 184.32e6) are for the X310 which only
> supports those two ADC sampling rates. The third rate (120e6) is no longer
> supported, I'll get that removed. 30.72e6 is for the AD9361/AD9364 based
> USRPs (B2x0, E310).
>
> The field is a text field so you can enter any value you want. However for
> most applications it is best to initialize the device with the master clock
> rate set in the device arguments. You can supply a string such as
> "master_clock_rate=61.44e6" into the Device Arguments field in the sink
> block. If you have a source block using the same USRP the Device Arguments
> and Device Address fields must be identical between these blocks.
>
> Regards,
> Derek
>
>
> On Wed, Jun 7, 2017 at 9:37 AM, 김태영  wrote:
>
>> Hi all
>>
>>
>>
>> I'm using Ettus Research USRP device with GRC.
>>
>> And I have one question.
>>
>>   > the host commuter and the USRP.>
>>   > between FPGA and the RF front end.>
>>
>>
>>
>> Is there anybody who can explain me why the clock rate on UHD:USRP sink
>> block
>>
>> have only 4 choice? (200, 184.32, 120, 30.72MHz)
>>
>>
>>
>>
>>
>> Regards
>>
>> Kim taeyeong
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Rational Resampler no output.

[Anon Lister]

I have an AMD system with the same chip running Ubuntu 16.xx. I can
probably try to duplicate this weekend, if Cor doesn't get to it, as
another data point.

On Jun 5, 2017 3:14 PM, "Marcus Müller"  wrote:

Hi Cor,

Excuse the language, but frk. Ok, looks like we have a bug in low_pass.
Or in GCC. Or SWIG (which does the python-wrapping of the code in
firdes.cc). yay.

So, let's narrow this down: on intel and amd64, same number of taps, right?

Then: If I asked you to use GDB to verify the C++ low_pass function in
gr::filter::firdes::low_pass actually returned the right float values,
would you feel that, with a few hints, be able to do that?

Best regards,

Marcus

On 01.06.2017 07:20, Cor Legemaat wrote:

Hi:

filter.firdes.low_pass get called with:
 * fractional_bw = 0.4
 * trans_width = 0.1
 * mid_transition_band = 0.45
 * interpolation = 24

But return: (nan, <788 times nan>)

Regards:
Cor

On Tue, 2017-05-30 at 00:06 +0200, Marcus Müller wrote:

Hi Cor,

 * When using 1 as "taps" there is output.

 Aha!!
So, here's the thing: something might be going wrong in the python
code that sets up the taps automatically if you don't set them
explicitly.
Maybe you can figure out where things go wrong; the interesting part
(maybe add some `print`s here?) from [1]:

# If we don't have user-provided taps, reduce the interp and
# decim values by the GCD (if there is one) and then define
# the taps from these new values.
if taps is None:
interpolation = interpolation // d
decimation = decimation // d
taps = design_filter(interpolation, decimation,
fractional_bw)

and


def design_filter(interpolation, decimation, fractional_bw):
"""
Given the interpolation rate, decimation rate and a fractional
bandwidth,
design a set of taps.

Args:
interpolation: interpolation factor (integer > 0)
decimation: decimation factor (integer > 0)
fractional_bw: fractional bandwidth in (0, 0.5)  0.4 works
well. (float)
Returns:
: sequence of numbers
"""

if fractional_bw >= 0.5 or fractional_bw <= 0:
raise ValueError, "Invalid fractional_bandwidth, must be in
(0, 0.5)"

beta = 7.0
halfband = 0.5
rate = float(interpolation)/float(decimation)
if(rate >= 1.0):
trans_width = halfband - fractional_bw
mid_transition_band = halfband - trans_width/2.0
else:
trans_width = rate*(halfband - fractional_bw)
mid_transition_band = rate*halfband - trans_width/2.0

taps = filter.firdes.low_pass(interpolation,
# gain
  interpolation,
# Fs
  mid_transition_band,
# trans mid point
  trans_width,
# transition width
  filter.firdes.WIN_KAISER,
  beta)
# beta

return taps



Best regards,
Marcus

[1] https://github.com/gnuradio/gnuradio/blob/master/gr-filter/python
/filter/rational_resampler.py

On 29.05.2017 19:01, Cor Legemaat wrote:

Hi:

 * The only warning is about the thread priority but that's on
both.
 * Type "Complex->Complex (Complex Taps)"
 * When using 1 as "taps" there is output.

I can open it in Nemiver if I know where to put the break point...

Regards:
Cor

On Mon, 2017-05-29 at 11:36 +0200, Marcus Müller wrote:

Hi Cor,
that's kind of surprising¹. My first bet is that your AMD system
is
missing some dependency that the intel system has, so that
something
goes wrong during build. But then again, you shouldn't be seeing
the
rational resampler block at all in that case. Let's head straight
to
debugging:
* Do you get any warning/console output during the execution of
that
flow graph?
* Which is the input/output type (float or complex, orange or
blue
connector in GRC, if using that)
* If in GRC: when explicitly using [1,] as "taps", do you get
output?
Best regards,
Marcus

¹ "wat?!"

On 29.05.2017 06:35, Cor Legemaat wrote:

Hi:

I have 2 different hardware setup's with funtoo/gentoo and
gnuradio
installed. On the Intel system the "Rational Resampler" is
working
correctly but on the AMD system there is no output. This is on
a
flow
graph for an basic wide band fm receiver based on the USPR
10min fm
receiver tutorial.

AMD system:
 * AMD FX(tm)-8150 Eight-Core Processor
 * CPU_FLAGS_X86="aes avx fma4 mmx mmxext popcnt sse sse2 sse3
sse4_1 sse4_2 sse4a ssse3 xop"

Intel system:
 * Intel(R) Core(TM) i5-2430M CPU @ 2.40GHz
 * CPU_FLAGS_X86="aes avx mmx mmxext popcnt sse sse2 sse3
sse4_1
sse4_2
   ssse3"

Tried with different versions of GNURadio and gcc but the same
symptoms, both systems is compiled with CFLAGS="-march=native
-O2
-pipe". At the moment it is gcc:6.3.0  and net-
wireless/gnuradio-
3.7.11:0/3.7.11  USE="alsa analog atsc audio channels digital
doc
dtv
examples fec filter grc noaa pager performance-counters
portaudio
qt4
uhd utils vocoder wavelet wxwidgets 

Re: [Discuss-gnuradio] Major OpenCL Updates

[Anon Lister]

Ubuntu 16.04. I followed the notes for the nvidia install. Got me past
the incompatible headers. Would be cool to steal the cmake opencl
magic they use in gr-phosfor so it picks up the right includes and
whatnot paths. Anywho, now I get:

home/anon/gr-clenabled/lib/clFilter_impl.h:26:24: fatal error:
fir_filter.h: No such file or directory

I didn't poke around to see if this is auto-generated somehow, but
given the recent commits relating to the topic, is it possible it just
got missed in a commit? It is, indeed, not there:

anon@anon:~/gr-clenabled$ find . -name "fir_filter.h"
anon@anon:~/gr-clenabled$

On Sun, May 7, 2017 at 5:44 PM, GhostOp14 <ghosto...@gmail.com> wrote:
> Hi Anon.  I set it up for 1.2.  The biggest gotcha I've run into in the
> build process is missing the cl.hpp file, but how to get it can vary by OS.
> There's some setup notes in the setup_help directory for debian and Ubuntu
> that may help you out.  What OS are you running it on?
>
> On Sun, May 7, 2017 at 4:35 PM, Anon Lister <listera...@gmail.com> wrote:
>>
>> Neat. What opencl implementation are you building against?
>>
>> I get errors related to _svm_ parts of code. I.e.
>> cl_device_svm_capabilities was not declared in this scope. Trying to use the
>> Nvidia cuda sdk, just downloaded from their developer site (ver 8.0).
>>
>>
>>
>> On May 6, 2017 8:59 AM, "Ghost Op" <ghosto...@gmail.com> wrote:
>>>
>>> Hi everyone.  A number of you have asked me to keep you informed of
>>> any major updates on the OpenCL gr-clenabled project and the past
>>> couple of weeks have been pretty active.  There's now a version up in
>>> the repo with a significant number of updates and all blocks have been
>>> validated (at least in their basic modes).
>>>
>>> So here's the major updates:
>>>
>>> Validation flowgraphs - Almost all test flowgraphs have been posted in
>>> the examples directory.  You can run the comparisons on your own
>>> hardware for comparison.  This is important on older cards that don't
>>> support double precision (you can check with the included clview
>>> command-line tool).
>>>
>>> Signal Source Block  - A discrepancy in the output was due to an
>>> OpenCL issue.  Turns out single/float precision wasn't producing
>>> accurate enough numbers.  This block now uses double precision if the
>>> hardware supports it (most new hardware will) for an even cleaner
>>> signal than the native block (no secondary nodes).
>>>
>>> Quad Demod - Same single/double trig discrepancy due to precision
>>> which was corrected.
>>>
>>> Filters - A lot of work this week has been spent on filter validation
>>> (hence the few emails about TD vs. FD from yesterday)
>>>  - Both FIR and FFT implementations are now implemented and
>>> producing correct output
>>>  - A generic tap-based block was added for more flexibility
>>>  - A test-clfilter command-line tool was added to test performance
>>> given a number of taps across OpenCL FIR, GNURadio FIR, OpenCL FFT,
>>> and GNURadio FFT so you can pick the best performing filter given your
>>> implementation.
>>>
>>> Costas Loop - A Costas Loop was added, however the performance on a
>>> GPU kernel is horrible.  Because of the sequential calculations, it
>>> couldn't be SIMD parallel processed so it was written as an OpenCL
>>> task-based kernel.  This means it just runs single-threaded on a
>>> single core, which is why the performance is so bad.  However if
>>> anyone has an OpenCL-capable FPGA card like an Altera I'd love to see
>>> the result of running the included test-clenabled timing tool and see
>>> how the Costas Loop performs.  I just don't have access to one.
>>>
>>> Performance - Code was added to detect if the hardware supports Fused
>>> Multiply/Add functionality for added kernel performance.  If it's
>>> available it's used.
>>>
>>> OpenCL Setup Instructions - For those that may not have OpenCL set up,
>>> I added some installation guides in the setup_help directory for
>>> Ubuntu and Debian with step-by-steps on getting it up and running.
>>> I've taken both of those processes on several systems and been up and
>>> running pretty quickly.  I also pulled some of the important points
>>> into the main page's README, since in my experience that's generally
>>> all I look through too.
>>>
>>> Study - Based on the filter updates, the filter section in the study
>>> in the docs directory was completely rewritten.  The report was noted
>>> as updated.
>>>
>>> I think that's the biggest updates for now.  As always let me know if
>>> anyone runs into any issues.
>>>
>>> ___
>>> Discuss-gnuradio mailing list
>>> Discuss-gnuradio@gnu.org
>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Major OpenCL Updates

[Anon Lister]

Neat. What opencl implementation are you building against?

I get errors related to _svm_ parts of code. I.e.
cl_device_svm_capabilities was not declared in this scope. Trying to use
the Nvidia cuda sdk, just downloaded from their developer site (ver 8.0).



On May 6, 2017 8:59 AM, "Ghost Op"  wrote:

> Hi everyone.  A number of you have asked me to keep you informed of
> any major updates on the OpenCL gr-clenabled project and the past
> couple of weeks have been pretty active.  There's now a version up in
> the repo with a significant number of updates and all blocks have been
> validated (at least in their basic modes).
>
> So here's the major updates:
>
> Validation flowgraphs - Almost all test flowgraphs have been posted in
> the examples directory.  You can run the comparisons on your own
> hardware for comparison.  This is important on older cards that don't
> support double precision (you can check with the included clview
> command-line tool).
>
> Signal Source Block  - A discrepancy in the output was due to an
> OpenCL issue.  Turns out single/float precision wasn't producing
> accurate enough numbers.  This block now uses double precision if the
> hardware supports it (most new hardware will) for an even cleaner
> signal than the native block (no secondary nodes).
>
> Quad Demod - Same single/double trig discrepancy due to precision
> which was corrected.
>
> Filters - A lot of work this week has been spent on filter validation
> (hence the few emails about TD vs. FD from yesterday)
>  - Both FIR and FFT implementations are now implemented and
> producing correct output
>  - A generic tap-based block was added for more flexibility
>  - A test-clfilter command-line tool was added to test performance
> given a number of taps across OpenCL FIR, GNURadio FIR, OpenCL FFT,
> and GNURadio FFT so you can pick the best performing filter given your
> implementation.
>
> Costas Loop - A Costas Loop was added, however the performance on a
> GPU kernel is horrible.  Because of the sequential calculations, it
> couldn't be SIMD parallel processed so it was written as an OpenCL
> task-based kernel.  This means it just runs single-threaded on a
> single core, which is why the performance is so bad.  However if
> anyone has an OpenCL-capable FPGA card like an Altera I'd love to see
> the result of running the included test-clenabled timing tool and see
> how the Costas Loop performs.  I just don't have access to one.
>
> Performance - Code was added to detect if the hardware supports Fused
> Multiply/Add functionality for added kernel performance.  If it's
> available it's used.
>
> OpenCL Setup Instructions - For those that may not have OpenCL set up,
> I added some installation guides in the setup_help directory for
> Ubuntu and Debian with step-by-steps on getting it up and running.
> I've taken both of those processes on several systems and been up and
> running pretty quickly.  I also pulled some of the important points
> into the main page's README, since in my experience that's generally
> all I look through too.
>
> Study - Based on the filter updates, the filter section in the study
> in the docs directory was completely rewritten.  The report was noted
> as updated.
>
> I think that's the biggest updates for now.  As always let me know if
> anyone runs into any issues.
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] What do I do with this alert?

[Anon Lister]

Darn it, your right.

On Apr 26, 2017 2:31 AM, "Marcus Müller" <marcus.muel...@ettus.com> wrote:

> ... which we can rule out by the Gnome/Unity window decorator in his
> screenshot :)
>
> On 26.04.2017 05:02, Anon Lister wrote:
>
> Unless he is running on Windows?
>
> On Apr 25, 2017 6:56 AM, "Johannes Demel" <de...@ant.uni-bremen.de> wrote:
>
>> Hi Fred,
>>
>> this is a warning that you want to execute a 'No GUI' flowgraph without a
>> terminal.
>> GRC tries to run your flowgraph by opening a new terminal. All prints
>> etc. will go into this terminal. But GRC is missing the path to your
>> terminal application.
>>
>> How to fix this:
>> Go to ~/.gnuradio
>> edit 'config.conf' or create it if the file is not yet present.
>> Search for the section '[grc]' or add it if not present.
>> add a line in this section:
>> xterm_executable = /usr/bin/gnome-terminal
>> replace the part after '=' with the path to the shell of your choice.
>> Restart GRC!
>>
>> I hope this helps.
>> The result should be that a new terminal pops up as soon as you click on
>> EXECUTE in GRC if you want to run a 'no GUI' flowgraph.
>>
>> Cheers
>> Johannes
>>
>>
>> On 25.04.2017 04:53, Fred wrote:
>>
>>> Another newb question.  I received the enclosed alert and it looks like
>>> it is wanting me to change some profile setting in GNU Radio relating to
>>> xterm.  I closed it but dont know if I need to act on it (as if
>>> everything I do going forward will not work correctly) or if it is
>>> something I can just ignore.  Please let me know your thoughts.
>>>
>>> Best Regards-Fred
>>>
>>>
>>>
>>>
>>> ___
>>> Discuss-gnuradio mailing list
>>> Discuss-gnuradio@gnu.org
>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>
>>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>
>
> ___
> Discuss-gnuradio mailing 
> listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] What do I do with this alert?

[Anon Lister]

Unless he is running on Windows?

On Apr 25, 2017 6:56 AM, "Johannes Demel"  wrote:

> Hi Fred,
>
> this is a warning that you want to execute a 'No GUI' flowgraph without a
> terminal.
> GRC tries to run your flowgraph by opening a new terminal. All prints etc.
> will go into this terminal. But GRC is missing the path to your terminal
> application.
>
> How to fix this:
> Go to ~/.gnuradio
> edit 'config.conf' or create it if the file is not yet present.
> Search for the section '[grc]' or add it if not present.
> add a line in this section:
> xterm_executable = /usr/bin/gnome-terminal
> replace the part after '=' with the path to the shell of your choice.
> Restart GRC!
>
> I hope this helps.
> The result should be that a new terminal pops up as soon as you click on
> EXECUTE in GRC if you want to run a 'no GUI' flowgraph.
>
> Cheers
> Johannes
>
>
> On 25.04.2017 04:53, Fred wrote:
>
>> Another newb question.  I received the enclosed alert and it looks like
>> it is wanting me to change some profile setting in GNU Radio relating to
>> xterm.  I closed it but dont know if I need to act on it (as if
>> everything I do going forward will not work correctly) or if it is
>> something I can just ignore.  Please let me know your thoughts.
>>
>> Best Regards-Fred
>>
>>
>>
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Installing GNU Radio in CentOS 6.8

[Anon Lister]

This is awesome! I'll try getting it installed at some point next week and
will be happy to give any feedback. Thanks!

On Oct 14, 2016 3:41 PM, "Ben Hilburn"  wrote:

> Hey all -
>
> I've seen some traffic both on and off-list discussion getting GNU Radio
> running in CentOS. The most recent one was CentOS 7.0, I believe, but
> there's also been some discussion of CentOS 6.8.
>
> I backported the current `maint`, based on v3.7.10.1, to CentOS 6.8 and
> pushed the branch to my Github, which you can find here:
> https://github.com/bhilburn/gnuradio/tree/centos6.8-backport
>
> In addition to the backported changes, you'll also need to install
> boost-1.48 from the EPEL repositories.
>
> If you're interested in a complete walk-through of the commands, I threw
> them up in a blog post: http://bhilburn.org/installing-gnu-radio-on-
> centos-6-8/
>
> Hopefully this is useful to someone. I haven't spent a ton of time testing
> it, but at a quick glance things seem to be in order. If you use this and
> find any issues, please let me know.
>
> Cheers,
> Ben
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] UHD/gnuradio on CentOS 7 install problems

[Anon Lister]

For what it's worth, I have both working fine on a c7 box here, I did it
from source though, not through pybombs. I had to build a couple packages,
such as boost, but it definitely can be done, at least as of a few months
ago.

On Oct 7, 2016 11:55 AM, "Chad Spooner"  wrote:

> All I really need in the short term is UHD on CentOS 7.
>
> Is it the consensus of the group is that UHD/gnuradio is not installable
> on CentOS 7? I haven't seen any suggestions about the python-zmq
> problem below.
>
> Chad
>
>
> On Wed, 2016-10-05 at 10:34 -0700, Chad M. Spooner wrote:
>
> Martin, Marcus: Thanks for the helpful replies.
>
> All: I think I messed up on subscribing to the mail list by selecting
> Digest, and I've tried to undo that. For now, I have to reply to the Digest
> I got this morning.
>
> I updated the recipes as suggested, and did a new installation. The first
> error was that somehow QT 4 was not in my (root's) path, QT 3.3 was, so I
> fixed that. (The symptom was that 'qmake' was not found by the installer.)
>
> Then I did another install and got to the point where the installer wants
> to install python-zmq:
>
> checking whether g++ supports C++11 features with -std=c++11... yes
> ./configure: line 17775: syntax error near unexpected token `QT,'
> ./configure: line 17775: ` PKG_CHECK_MODULES(QT, QtCore >= 4.3, QtNetwork
> >= 4.3, have_qt=yes, have_qt=no)'
> PyBOMBS.Packager.source - ERROR - Configuration failed after running at
> least twice.
> PyBOMBS.Packager.source - ERROR - Problem occurred while building package
> apache-thrift:
> Configuration failed
> PyBOMBS.PackageManager - WARNING - Optional package apache-thrift failed
> to install.
> PyBOMBS.install_manager - INFO - Installation successful.
> PyBOMBS.install_manager - INFO - Installing package: liblog4cpp
> 00549 kB / 00549 kB (100%)
> Configuring: (100%) [=
> ===]
> Building: (100%) [=
> ===]
> Installing: (100%) [=
> ===]
> PyBOMBS.install_manager - INFO - Installation successful.
> PyBOMBS.install_manager - INFO - Installing package: zeromq
> 02084 kB / 02084 kB (100%)
> Configuring: (100%) [=
> ===]
> Building: (100%) [=
> ===]
> Installing: (100%) [=
> ===]
> PyBOMBS.install_manager - INFO - Installation successful.
> PyBOMBS.install_manager - INFO - Installing package: python-zmq
> PyBOMBS.Packager.source - WARNING - Cannot find a source URI for package
> python-zmq
> PyBOMBS.install_manager - ERROR - Error installing package python-zmq.
> Aborting.
>
> Chad
>
> On 2016-10-05 09:00, discuss-gnuradio-requ...@gnu.org wrote:
>
> Send Discuss-gnuradio mailing list submissions to
> discuss-gnuradio@gnu.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> or, via email, send a message with subject or body 'help' to
> discuss-gnuradio-requ...@gnu.org
>
> You can reach the person managing the list at
> discuss-gnuradio-ow...@gnu.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Discuss-gnuradio digest..."
>
>
> Today's Topics:
>
>1. Replacement for packet encoder/decoder (Damindra Bandara)
>2. Re: Block Thread question (Marcus M?ller)
>3. Re: Block Thread question (Garver, Paul W)
>4. Re: Fwd: Correlation Estimator in 3.7.10 (devin kelly)
>5. Re: Fwd: Correlation Estimator in 3.7.10 (Steven Knudsen)
>6. UHD/gnuradio on CentOS 7 install problems (Chad M. Spooner)
>7. Re: UHD/gnuradio on CentOS 7 install problems (Marcus M?ller)
>8. Re: UHD/gnuradio on CentOS 7 install problems (Martin Braun)
>
>
> --
>
> Message: 1
> Date: Tue, 4 Oct 2016 12:40:10 -0400
> From: Damindra Bandara 
> To: discuss-gnuradio@gnu.org
> Subject: [Discuss-gnuradio] Replacement for packet encoder/decoder
> Message-ID:
> 

Re: [Discuss-gnuradio] Errors using PyBombs recipe for RFNoC setup

[Anon Lister]

It was WX that was mentioned as being deprecated. Sorry I don't have much
to offer for your issue tho, except that you should run the pybombs command
with -v (pybombs -v . -vv works too for very verbose output. At
some point it's trying to fetch a QT installer, but failing. I would try
grabbing that URL by hand as a start go make sure it's not an issue on your
network. Then someone here can try to reproduce, Incase QT changed
something.

On Sep 23, 2016 11:29 AM, "Andrew Lanez"  wrote:

Here is that output again with more relevant info that I forgot to copy
over:

make[2]: Entering directory `/home/switchlanez/rfnoc/src/pyqt4/qpy/QtCore'
g++ -c -m64 -pipe -fno-strict-aliasing -O2 -fPIC -Wall -W -D_REENTRANT
-DQT_NO_DEBUG -DQT_GUI_LIB -DQT_CORE_LIB -DQT_SHARED
-I/usr/share/qt4/mkspecs/linux-g++-64 -I. -I/usr/include/qt4/QtCore
-I/usr/include/qt4/QtGui -I/usr/include/qt4 -I/usr/include/python2.7
-I../../QtCore -I. -I. -o qpycore_chimera.o qpycore_chimera.cpp
qpycore_chimera.cpp: In member function ‘void Chimera::set_flag()’:
qpycore_chimera.cpp:376:50: error: ‘pyqt4ClassTypeDef’ has no member named
‘qt4_flags’
 _is_flag = ((pyqt4ClassTypeDef *)_type)->qt4_flags & 0x01;
  ^
make[2]: *** [qpycore_chimera.o] Error 1
make[2]: Leaving directory `/home/switchlanez/rfnoc/src/pyqt4/qpy/QtCore'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/home/switchlanez/rfnoc/src/pyqt4/qpy'
make: *** [all] Error 2
PyBOMBS.Packager.source - ERROR - Build failed. See output above for error
messages.
PyBOMBS.Packager.source - ERROR - Problem occurred while building package
pyqt4:
Build failed.
PyBOMBS.install_manager - ERROR - Error installing package pyqt4. Aborting.


I was at GNU Radio Conference last week and remember mention of qt being
deprecated. Could this be why?

On Fri, Sep 23, 2016 at 8:20 AM, Andrew Lanez  wrote:

> Well, I wiped everything clearn and started from a fresh image of Linux to
> remove any doubt (3rd time doing this). This time I made sure to do sudo
> apt-get update liberally before running pybombs prefix init ~/rfnoc -R
> rfnoc -a alias
>
> The first time it showed boost failed to install even though the
> Installation progress bar showed 100%.
>
> I discovered that if I delete the ~/rfnoc directory I can rerun pybombs
> prefix init ~/rfnoc -R rfnoc -a alias without errors. So everytime I do
> that now I persistently get:
>
> Processing triggers for libc-bin (2.19-0ubuntu6.9) ...
> PyBOMBS.Fetcher.wget - ERROR - hostname 'download.qt.io' doesn't match
> either of '*.qt-project.org', 'qt-project.org', 'www.qt-project.org'
> PyBOMBS.Packager.source - ERROR - Problem occurred while building package
> qt4:
> Unable to fetch recipe qt4
> PyBOMBS.install_manager - ERROR - Error installing package qt4. Aborting.
>
>
> What can I do about this?
>
>
> On Thu, Sep 22, 2016 at 9:16 PM, Andrew Lanez  wrote:
>
>> New Linux user here, I don't mean to anger anyone with my naivete.
>>
>> I just ran sudo apt-get. That might fix the other non-showstopper errors
>> earlier. But I am not sure where to start to address that last error which
>> is the show stopper:
>>
>> checking for BASE_DEPENDENCIES... no
>> configure: error: Package requirements (glib-2.0 >= 2.25.10atk >=
>> 1.29.2pango >= 1.20cairo >= 1.6gdk-pixbuf-2.0 >= 2.21.0) were
>> not met:
>>
>> No package 'atk' found
>> No package 'pango' found
>> No package 'cairo' found
>>
>> Consider adjusting the PKG_CONFIG_PATH environment variable if you
>> installed software in a non-standard prefix.
>>
>> Alternatively, you may set the environment variables
>> BASE_DEPENDENCIES_CFLAGS
>> and BASE_DEPENDENCIES_LIBS to avoid the need to call pkg-config.
>> See the pkg-config man page for more details.
>> PyBOMBS.Packager.source - ERROR - Configuration failed after running at
>> least twice.
>> PyBOMBS.Packager.source - ERROR - Problem occurred while building package
>> gtk2:
>> Configuration failed
>> PyBOMBS.install_manager - ERROR - Error installing package gtk2. Aborting.
>>
>>
>> I tried running the same pybombs command and got:
>> $ pybombs prefix init ~/rfnoc -R rfnoc -a alias
>> PyBOMBS - INFO - PyBOMBS Version 2.2.0
>> PyBOMBS.prefix - ERROR - Ignoring. A prefix already exists in
>> `/home/switchlanez/rfnoc'
>>
>> So I took out what might be prefix-related stuff but these didn't work:
>> $ pybombs -R rfnoc -a alias
>> $ pybombs rfnoc -a alias
>> $ pybombs rfnoc
>>
>> How do I properly rerun the pybombs script?
>>
>
>

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Performance for GNU-Radio: Intel i3-6100 or AMD FX-4300

[Anon Lister]

The AMD only has 2 floating point units too, they just define "core"
differently(believe there was a class action lawsuit over this started
recently). Given GR is mostly FP math, I'd go with the intel.

On Sep 22, 2016 10:43 AM, "Fernando Peral"  wrote:

> I'm buying a new computer and two possible options will be intel
> i3-6100   and AMD FX-4300.
>
> Performance using GNU-Radio may be the key to the selection of one or
> the other.
>
> I guess the more cores the CPU, the better the performance.
>
> FX-4300 is 4 cores,  i3-6100 is only two cores but they say both of them
> runs 4 threads.
>
> I should think that a real core (AMD) will work faster than a "logic"
> one (intel), but reading benchmarks it seems that i3-6100 beats FX-4300
> .  but  what with GNU-Radio?
>
> Anyone has test both?
>
>
> regards
>
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] OOT Block on Windows feasible?

[Anon Lister]

I'd suggest trying to just build gnuradio on windows following the scripts
setup by the author, available on the same site. AFAIK, the "release"
doesn't include all the build deps, just he runtime ones. That should at
least get all the dev libraries you will likley need. (There's something
like 25 of them, most standard on any Unix but not in Windows world, and
the one you encountered is one of the easier ones to build.) Also once
that's done you can launch into a shell with all the appropriate
environmental variables setup correctly. (Think it's called gnuradio
command prompt or some such) then you'll be in a much better place to start
your OOT development.
On Jun 26, 2016 4:55 PM, "Gavin Jacobs"  wrote:

> Marcus,
> Thanks for those words of encouragement; based on that I dived in.
> 1. Tutorial you mentioned says to clone the repository "git ...". Hmmm, I
> don't have git, but I can go the website, get a zip, extract to my working
> directory; different tool with same result.
>
> 2A. Tutorial says to use cmake. Hmmm, google search for cmake, download,
> install, and it detects that I have Visual Studio; it tests that and
> declares it usable (this is encouraging), but then barfs on a missing
> package called Boost.
>
> 2B. Google search for Boost turns up a nutritional supplement - probably
> not that. Second hit is a set of C++ libraries. Download, install, try
> cmake again: same problem - can't find Boost.
> Stuck here for now.
>
> 3. Meanwhile, further on in the tutorial, I will need a tool called
> gr_modtool. No gr_modtool.exe found, but I did locate a .py file. Tried
> with Python and got this:
> python "C:\Program Files\GNURadio-3.7\bin\gr_modtool.py" nm
> Name of the new module: how2
> Could not find gr-newmod source dir.
> I found a configuration file for location of the newmod directory, so I
> tried to override that to a local copy. No joy - same error.
> There was someone on this list in 2014 named PEEL Luke who said he had
> gr_modtool working on Windows - I would like to know the steps.
> Also stuck here for now.
>
> Did some further digging and learned that the windows binaries that I
> downloaded were just recently assembled (i.e. prior to spring of 2016 you
> had to build it yourself), so not surpisingly the OOT stuff hasn't been
> tackled yet. Also, the hoops he had to jump through were many and varied
> including numerous dependencies, so I'm not confident that I could figure
> it out just by hacking along.
>
> So, I still wanted to try creating a GRC block. I created a VM (Ubuntu
> 16.04) and installed the whole GR stuff there. Next I'll try that tutorial
> again.
>
> Jake
>
>
> > Message: 4
> > Date: Sun, 26 Jun 2016 14:15:41 +0200
> > From: Marcus M?ller 
> > To: discuss-gnuradio@gnu.org
> > Subject: Re: [Discuss-gnuradio] OOT Block on Windows feasible?
> > Message-ID: <576fc76d.9040...@ettus.com>
> > Content-Type: text/plain; charset="windows-1252"
> >
> > Hi Gavin,
> >
> > http://tutorials.gnuradio.org
> >
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] [PyBOMBS] Need your help!

[Anon Lister]

Yeah, I hear you, issue for us is we are on el6 for at least a couple more
years as it's what our primary customer uses so all our other tools are
built to it. Sofar I ripped deps from the windows build and have compiled
most of them along with current GCC. Making decent progress(working a
couple hours a week on it), when I'm done I should be able to post said big
nasty bash script. However I didn't think of a chrooted modern distro, I
know there was some docker work going on. That shouldn't take any real
performance penalty so may be a way to go if a chrooted Ubuntu doesn't crap
out with a 2.6 kernel.

-Anon
On May 18, 2016 9:26 AM, "Andy Walls" <a...@silverblocksystems.net> wrote:

> On Wed, 2016-05-18 at 03:11 -0400, Anon Lister wrote:
> > Andy,
> [snip]
>
> > Since I'm replying in the pybombs thread, I did try it and it broke
> > pretty badly. Missing deps and such, I'd be willing to try to help get
> > with that after I get the build down by hand and know what I can use
> > from yum and what I have to source build (which I expect is almost
> > everything).
>
> Building on SciLinux 6.x (and probably CentOS 6.x) with PyBOMBS is a
> fool's errand.  Take it from a fool who tried.
>
> PyBOMBS should *not* target RHEL/CentOS/SciLinux 6.x as the Python is
> too old, and the old Qt4 version forces maximum versions for Qwt, SIP,
> PyQwt, and maybe other libraries.  M4, autoconf and automake are too
> old.  libcurses.so is also broken in a funny way, so libuhd examples
> won't compile without fixing it.  A few items need patches to build.  It
> goes on and on
>
> A big nasty Bash script, a chroot-ed modern distro install, or a more
> capable build system (like bitbake), is needed for GNURadio on those
> distros.
>
>
> > Did get el7 build without much issue, don't think I needed to source
> > build GCC or anything, there were only a few packages that needed
> > source build, boost I think was the only big one.
>
> And since el7 *is* available to people, any hard work on el6 is
> something I would not encourage.
>
> Regards,
> Andy
>
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] [PyBOMBS] Need your help!

[Anon Lister]

Erm, sorry to mislead. I mean I built it by hand without problem. I didn't
try pybombs there. Only on el6. Sorry :(
On May 18, 2016 6:29 AM, "Marcus Müller" <marcus.muel...@ettus.com> wrote:

> Wait, pybombs builds GR including thrift without problems on your EL7?
> That's awesome! I'm constantly failing to get it to build on a fresh
> minimal CentOS7, but if it works on RHEL7, I'll just leave it at that.
>
> On 18.05.2016 09:11, Anon Lister wrote:
>
> Andy,
> If you ever find your self building on an el6 like system again, any
> script (even bash history) of doing so would be awesome. I'm working on
> building on cent 6 when I get spare time (rarely) and would love if someone
> else had a head start.
>
> Since I'm replying in the pybombs thread, I did try it and it broke pretty
> badly. Missing deps and such, I'd be willing to try to help get with that
> after I get the build down by hand and know what I can use from yum and
> what I have to source build (which I expect is almost everything).
>
> Did get el7 build without much issue, don't think I needed to source build
> GCC or anything, there were only a few packages that needed source build,
> boost I think was the only big one.
>
> -Anon
> On May 17, 2016 1:39 PM, "Andy Walls" <a...@silverblocksystems.net> wrote:
>
> On Tue, 2016-05-17 at 12:44 -0400, discuss-gnuradio-requ...@gnu.org
> wrote:
> > Date: Mon, 16 May 2016 22:51:45 +0200
> > From: Marcus M?ller
> > To: discuss-gnuradio@gnu.org
> >
> > Hi Martin,
> >
> > first of all: thanks for jumping through all these hoops to push
> > PyBOMBS!
> >
> > So, trying to make things (especially recipe fixes etc) easier to test
> > for me, I've built myself a small set of script to log in to a set of
> > VMs, install pip & git there, install pybombs in the vm, adding a test
> > user, getting pyBOMBS and then install a package of my choice.
> > That all's built atop of ansible and I hope the stuff one needs to do
> > to
> > test this on one's own VMs is documented well enough:
> >
> > https://github.com/marcusmueller/ansible-pybombs-testing
> >
> > I can only second the call for people to look at building thrift
> > 0.9.3,
> > especially on something that's not Ubuntu. As it is now, I really
> > can't
> > find a way to do so on CentOS7, and that's one of the platforms I'd
> > really love to support.
>
> Huh, that's one of the few things that built with no problems on
> Scientific Linux 6.x, after I did this:
>
> mkdir -p ${HOME}/target/share/aclocal
> echo `/usr/bin/aclocal --print-ac-dir` >>
> ${HOME}/target/share/aclocal/dirlist
> export
> LD_LIBRARY_PATH=${HOME}/target/lib64:${HOME}/target/lib:${LD_LIBRARY_PATH}
> export LIBRARY_PATH=${HOME}/target/lib64:${HOME}/target/lib
> export PATH=${HOME}/target/bin:/usr/lib64/qt4/bin:${PATH}
> export PYTHONDOCS=${HOME}/target/share/doc/python-2.7.11
> export
> PKG_CONFIG_PATH=${HOME}/target/lib64/pkgconfig:${HOME}/target/lib/pkgconfig:${HOME}/target/share/pkgconfig
>
> and I installed the following from source or PIP:
>
> binutils-2.26.tar.gz (source)
> gcc-4.9.3.tar.gz (source)
>gmp-4.3.2.tar.bz2
>mpfr-2.4.2.tar.gz
>mpc-0.8.1.tar.gz
>isl-0.12.2.tar.bz2
>cloog-0.18.1.tar.gz
> m4-1.4.17.tar.gz (source)
> autoconf-2.69.tar.gz (source)
> automake-1.15.tar.gz (source)
> bison-3.0.4.tar.gz (source)
> Python-2.7.11.tgz (source)
> boost_1_53_0.tar.bz2 (source)
> pip (using get-pip.py)
> libevent-2.0.22-stable.tar.gz (source)
> twisted (pip)
>
> I can't recall the thrift deps that I installed with YUM, but they are
> most certainly old and from the SciLinux or EPEL repos.
>
> Then this thrift build process worked:
>
> git clone https://github.com/apache/thrift.git
> cd thrift
> git checkout 0.9.3
> ./bootstrap.sh && ./configure --prefix=${HOME}/target \
>   --with-c_glib --with-cpp --with-libevent --with-python \
>   --without-csharp --without-d --without-erlang --without-go \
>   --without-haskell --without-java --without-lua --without-nodejs \
>   --without-perl --without-php --without-ruby --without-zlib \
>   --without-qt4 --without-qt5 \
>   --disable-tests --disable-tutorial \
>   CC=gcc CXX=g++ PY_PREFIX=${HOME}/target CXXFLAGS="-DNDEBUG"
> make -j 5
> make install
> cd ..
>
> I recall a nagging dependency was the libevent 2.x stuff.  There's
> headers for  or something like that, which thrift needs,
> that is not in older versions of libevent.
>
> FWIW, Thift lists its requirements here:
> http://thrift.apache.org/docs/install/
> http://thrift.apache.org/docs/install/centos
>
>

Re: [Discuss-gnuradio] [PyBOMBS] Need your help!

[Anon Lister]

Andy,
If you ever find your self building on an el6 like system again, any script
(even bash history) of doing so would be awesome. I'm working on building
on cent 6 when I get spare time (rarely) and would love if someone else had
a head start.

Since I'm replying in the pybombs thread, I did try it and it broke pretty
badly. Missing deps and such, I'd be willing to try to help get with that
after I get the build down by hand and know what I can use from yum and
what I have to source build (which I expect is almost everything).

Did get el7 build without much issue, don't think I needed to source build
GCC or anything, there were only a few packages that needed source build,
boost I think was the only big one.

-Anon
On May 17, 2016 1:39 PM, "Andy Walls"  wrote:

On Tue, 2016-05-17 at 12:44 -0400, discuss-gnuradio-requ...@gnu.org
wrote:
> Date: Mon, 16 May 2016 22:51:45 +0200
> From: Marcus M?ller
> To: discuss-gnuradio@gnu.org
>
> Hi Martin,
>
> first of all: thanks for jumping through all these hoops to push
> PyBOMBS!
>
> So, trying to make things (especially recipe fixes etc) easier to test
> for me, I've built myself a small set of script to log in to a set of
> VMs, install pip & git there, install pybombs in the vm, adding a test
> user, getting pyBOMBS and then install a package of my choice.
> That all's built atop of ansible and I hope the stuff one needs to do
> to
> test this on one's own VMs is documented well enough:
>
> https://github.com/marcusmueller/ansible-pybombs-testing
>
> I can only second the call for people to look at building thrift
> 0.9.3,
> especially on something that's not Ubuntu. As it is now, I really
> can't
> find a way to do so on CentOS7, and that's one of the platforms I'd
> really love to support.

Huh, that's one of the few things that built with no problems on
Scientific Linux 6.x, after I did this:

mkdir -p ${HOME}/target/share/aclocal
echo `/usr/bin/aclocal --print-ac-dir` >>
${HOME}/target/share/aclocal/dirlist
export
LD_LIBRARY_PATH=${HOME}/target/lib64:${HOME}/target/lib:${LD_LIBRARY_PATH}
export LIBRARY_PATH=${HOME}/target/lib64:${HOME}/target/lib
export PATH=${HOME}/target/bin:/usr/lib64/qt4/bin:${PATH}
export PYTHONDOCS=${HOME}/target/share/doc/python-2.7.11
export
PKG_CONFIG_PATH=${HOME}/target/lib64/pkgconfig:${HOME}/target/lib/pkgconfig:${HOME}/target/share/pkgconfig

and I installed the following from source or PIP:

binutils-2.26.tar.gz (source)
gcc-4.9.3.tar.gz (source)
   gmp-4.3.2.tar.bz2
   mpfr-2.4.2.tar.gz
   mpc-0.8.1.tar.gz
   isl-0.12.2.tar.bz2
   cloog-0.18.1.tar.gz
m4-1.4.17.tar.gz (source)
autoconf-2.69.tar.gz (source)
automake-1.15.tar.gz (source)
bison-3.0.4.tar.gz (source)
Python-2.7.11.tgz (source)
boost_1_53_0.tar.bz2 (source)
pip (using get-pip.py)
libevent-2.0.22-stable.tar.gz (source)
twisted (pip)

I can't recall the thrift deps that I installed with YUM, but they are
most certainly old and from the SciLinux or EPEL repos.

Then this thrift build process worked:

git clone https://github.com/apache/thrift.git
cd thrift
git checkout 0.9.3
./bootstrap.sh && ./configure --prefix=${HOME}/target \
  --with-c_glib --with-cpp --with-libevent --with-python \
  --without-csharp --without-d --without-erlang --without-go \
  --without-haskell --without-java --without-lua --without-nodejs \
  --without-perl --without-php --without-ruby --without-zlib \
  --without-qt4 --without-qt5 \
  --disable-tests --disable-tutorial \
  CC=gcc CXX=g++ PY_PREFIX=${HOME}/target CXXFLAGS="-DNDEBUG"
make -j 5
make install
cd ..

I recall a nagging dependency was the libevent 2.x stuff.  There's
headers for  or something like that, which thrift needs,
that is not in older versions of libevent.

FWIW, Thift lists its requirements here:
http://thrift.apache.org/docs/install/
http://thrift.apache.org/docs/install/centos

Regards,
Andy

>
> Cheers,
> Marcus



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] GR win64 binaries v1.1 posted

[Anon Lister]

So, with gqrx, aside from the known issues with B200 crashing when
changing demod settings, it seems I have missing icons, any thoughts?

http://imgur.com/cNXLa7G

-Anon

On Wed, May 4, 2016 at 4:33 PM, Geof Nieboer  wrote:
> Jim,
>
> I found the problem.  Qt5 threw me a nice curveball.  I've got a fix, check
> back tomorrow for v1.1.1 :(.
>
> Apologies.
>
> Geof
>
> On Wed, May 4, 2016 at 9:56 PM, Geof Nieboer  wrote:
>>
>> Jim,
>>
>> Try dropping the below file in the c:\Program Files\gnuradio-3.7\bin
>> directory and see if it works, or at least if the error changes.  It's a Qt5
>> platform plugin that did not appear necessary (I only included the Qt5 files
>> that appeared needed to keep the size down)
>>
>> Geof
>>
>> On Wed, May 4, 2016 at 8:47 PM, James C Mankin  wrote:
>>>
>>> After uninstalling v1.0 and installing V1.1 , I was not able to run gqrx
>>> under Windows 7.I see a command
>>> line window that says "setting gnuradio environment" and then a pop-up
>>> that says:
>>>
>>>This application failed to start because it could not find or load the
>>> Qt
>>> platform plugin  "windows"
>>> in "".
>>>
>>>Reinstalling the application may fix this problem.
>>>
>>> Otherwise things seem to work OK.
>>>
>>> Jim kb3kj
>>> n...@psu.edu
>>>
>>>
>>> On 05/03/2016 09:05 PM, Geof Nieboer wrote:
>>>
>>> All,
>>>
>>> An updated set of windows binaries and build scripts have been posted.
>>> Quick summary:
>>> 1- Added gqrx to package
>>> 2- Patched 2 x issues which would cause the generic version to crash on
>>> non-AVX systems (one in volk, one in FFTW)
>>> 3- Added gr-newmod to package
>>>
>>> Plus a number of improvements to make the scripts more robust.
>>>
>>> Binaries at http://www.gcndevelopment.com/gnuradio/downloads.htm
>>> Scripts at https://github.com/gnieboer/GNURadio_Windows_Build_Scripts
>>>
>>> A couple gqrx known bugs:
>>> 1- Toolbar icons do not appear (our Qt5 issue)
>>> 2- Switching a USRP to another modulation will cause a crash (upstream
>>> UHD)
>>> 3- Switching between a RTL-SDR device and a USRP device will cause a
>>> crash (upstream gqrx)
>>>
>>> Cheers,
>>>
>>> Geof
>>>
>>>
>>> ___
>>> Discuss-gnuradio mailing list
>>> Discuss-gnuradio@gnu.org
>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>
>>>
>>>
>>> ___
>>> Discuss-gnuradio mailing list
>>> Discuss-gnuradio@gnu.org
>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>
>>
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] GR win64 binaries v1.1 posted

[Anon Lister]

Nice. Will def check this out.
On May 3, 2016 5:05 PM, "Geof Nieboer"  wrote:

> All,
>
> An updated set of windows binaries and build scripts have been posted.
> Quick summary:
> 1- Added gqrx to package
> 2- Patched 2 x issues which would cause the generic version to crash on
> non-AVX systems (one in volk, one in FFTW)
> 3- Added gr-newmod to package
>
> Plus a number of improvements to make the scripts more robust.
>
> Binaries at http://www.gcndevelopment.com/gnuradio/downloads.htm
> Scripts at https://github.com/gnieboer/GNURadio_Windows_Build_Scripts
>
> A couple gqrx known bugs:
> 1- Toolbar icons do not appear (our Qt5 issue)
> 2- Switching a USRP to another modulation will cause a crash (upstream UHD)
> 3- Switching between a RTL-SDR device and a USRP device will cause a crash
> (upstream gqrx)
>
> Cheers,
>
> Geof
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Building on ODroid C2 running CentOS 7 report.

[Anon Lister]

You can just add a bigger file-backed swap partition. From my experience
building on the Pi3, the time that it spends building stuff at a high mem
requirement is low. This will allow it to not die on a burst of mem needed,
but allow the build to continue with fairly little oversight.
On Apr 29, 2016 10:33 AM, "Lamar Owen"  wrote:

> On 04/28/2016 07:40 PM, Marcus Müller wrote:
>
>> before I head to bed:
>> I was actually thinking about using a SPEC from any other platform (ie.
>> prolly x86_64) and just fixing a few flags, if at all necessary – the
>> cmake build system will usually deal just fine! So really, if you want
>> bleeding edge, go for it :) and don't wait for EPEL.
>>
> I will be doing this once I get a known good build using the
> build-gnuradio script, as I know it works.  I have pulled the appropriate
> source RPMs from EPEL and will go about updating them for 3.7.9.2, then
> rebuild them, both on x86_64 and on aarch64.
>
> I did get all of the builreqs built and/or installed yesterday, and got
> the build-gnuradio script started, and it ran for a while, but anything
> other than -j1 creates issues, but only with a couple of files (all of the
> *_swigPYTHON_wrap.cxx.o files take huge amounts of virt mem to compile
> (>2GB); is there a good way to let the make be parallelized except for
> these files?).
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Problem with SWIG on Windows

[Anon Lister]

Also, does gnuradio companion run from the start menu?
On Apr 24, 2016 5:57 PM, "Camera Parts"  wrote:

> Hi,
>
>   I am new to GnuRadio.
>
>   I installed on Windows 8 using gnuradio_3.7.9.2_win64.msi.  I am looking
> for a simple example in order to test the installation. When I try to run
> mono_tone.py located in \share\gnuradio\examples\audio, I got an error
> saying "ImportError: DLL load failed: %1 is not a valid Win32 application."
>
>   Could someone help?
>
> Thanks
>
>
> C:\GNURadio-3.7\share\gnuradio\examples\audio>python mono_tone.py
> Traceback (most recent call last):
>   File "mono_tone.py", line 23, in 
> from gnuradio import gr
>   File "C:\GNURadio-3.7\lib\site-packages\gnuradio\gr\__init__.py", line
> 41, in
> 
> from runtime_swig import *
>   File "C:\GNURadio-3.7\lib\site-packages\gnuradio\gr\runtime_swig.py",
> line 28,
>  in 
> _runtime_swig = swig_import_helper()
>   File "C:\GNURadio-3.7\lib\site-packages\gnuradio\gr\runtime_swig.py",
> line 24,
>  in swig_import_helper
> _mod = imp.load_module('_runtime_swig', fp, pathname, description)
> ImportError: DLL load failed: %1 is not a valid Win32 application.
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Pybomb installation error

[Anon Lister]

How much RAM do you have? With higher parallelization, uhd requires a good
bit of RAM during compile. Idk what pybombs does to calculate the level to
use, if you can override it try with only 1 thread being passed to make.
On Apr 21, 2016 8:52 PM, "Shahnaz Shirazi"  wrote:

Hi,
I updated Pybombs to latest today and then run install command.
Got bellow error

c++: internal compiler error: Killed (program cc1plus)
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make[2]: ***
[lib/CMakeFiles/uhd.dir/transport/nirio/niusrprio_session.cpp.o] Error 4
make[2]: *** Waiting for unfinished jobs
make[1]: *** [lib/CMakeFiles/uhd.dir/all] Error 2
make: *** [all] Error 2

PyBombs.monitor_process() - DEBUG - Thread signaled termination or returned
PyBombs.monitor_process() - DEBUG - Return value: 2

PyBombs.Packager.source - ERROR - Problem occurred while building package
uhd:
Process returned value: 2

PyBombs.install - ERROR - Error installing package uhd. Aborting.

Bug report is attached

Thanks,
Shahnaz


On Thu, Apr 21, 2016 at 8:53 AM, West, Nathan 
wrote:

> This was a bug that's been fixed recently.
> https://github.com/gnuradio/pybombs/commit/38ed9d169ed67ef090e6015b07c4918f7c112209
>
> On Thu, Apr 21, 2016 at 11:23 AM, Jason Matusiak <
> ja...@gardettoengineering.com> wrote:
>
>> > $ pybombs [-p myprefix] install gnuradio gr-osmosdr -v
>>
>> I ran it, but it thinks that -v is a recipe and it errors out there.  If
>> instead I run $ pybombs -v [-p myprefix] -v install gnuradio gr-osmosdr, i
>> get:
>> 
>> PyBombs.Packager.source - DEBUG - Configuring recipe uhd
>> PyBombs.Packager.source - DEBUG - Using vars - {'config_opt': '',
>> 'builddir': '/home/jmat/gnuradio/src/uhd/build'}
>> PyBombs.Packager.source - DEBUG - In cwd -
>> /home/jmat/gnuradio/src/uhd/build
>> PyBombs._process_thread() - DEBUG - Executing command `CC= CXX= cmake ..
>> -DCMAKE_BUILD_TYPE=RelWithDebInfo
>> -DCMAKE_INSTALL_PREFIX=/home/jmat/gnuradio  -Wno-dev'
>> CMake Error: The source directory "/home/jmat/gnuradio/src/uhd" does not
>> appear to contain CMakeLists.txt.
>> Specify --help for usage, or press the help button on the CMake GUI.
>> PyBombs.monitor_process() - DEBUG - Thread signaled termination or
>> returned
>> PyBombs.monitor_process() - DEBUG - Return value: 1
>> PyBombs.Packager.source - ERROR - Problem occurred while building package
>> uhd:
>> Process returned value: 1
>> PyBombs.install - ERROR - Error installing package uhd. Aborting.
>> jmatusiak@wk-jmatusiak-02:~/.pybombs/recipes/gr-recipes$
>> 
>>
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>
>

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Pybomb installation error

[Anon Lister]

You'll prolly run into same prob with hackrf. I did when I tried to use
pybombs for some reason the other day. It's looking for the cmakelists file
in the root, it's in host or something similar. I ended up just building
everything by hand. And deleting pybombs.
On Apr 21, 2016 7:20 PM, "Shahnaz Shirazi"  wrote:

> as suggested run it without gr-osmosdr  and with -v
> below is the error.
>
> PyBombs.Packager.source - DEBUG - In cwd - /home/shahnaz/Lab3/src/uhd/build
> PyBombs._process_thread() - DEBUG - Executing command `CC= CXX= cmake ..
> -DCMAKE_BUILD_TYPE=RelWithDebInfo
> -DCMAKE_INSTALL_PREFIX=/home/shahnaz/Lab3  -Wno-dev'
> CMake Error: The source directory "/home/shahnaz/Lab3/src/uhd" does not
> appear to contain CMakeLists.txt.
> Specify --help for usage, or press the help button on the CMake GUI.
> PyBombs.monitor_process() - DEBUG - Thread signaled termination or returned
> PyBombs.monitor_process() - DEBUG - Return value: 1
> PyBombs.Packager.source - ERROR - Problem occurred while building package
> uhd:
> Process returned value: 1
> PyBombs.install - ERROR - Error installing package uhd. Aborting.
>
> same error but this time for UHD folder.
> going to uninstall the pybombs and try it again.
>
>
> On Thu, Apr 21, 2016 at 8:06 AM, James Humphries <
> james.humphr...@ettus.com> wrote:
>
>> Hi Shahnaz,
>>
>> Could you run the install step again but with the verbose flag (-v)?
>>
>> $ pybombs [-p myprefix] install gnuradio gr-osmosdr -v
>>
>> It might produce more helpful debugging information. Can you post the
>> relevant output here when it hits the error?
>>
>> -Trip
>>
>> On Wed, Apr 20, 2016 at 9:12 PM, Shahnaz Shirazi 
>> wrote:
>>
>>> Hi All,
>>>
>>> I'm trying to install Gnu radio through Pybombs.
>>> I followed the steps from instruction as listed below without error
>>> until step 4.
>>> Quickstart
>>>
>>> For the impatient:
>>>
>>>1. Install PyBOMBS as per the previous section
>>>2.
>>>
>>>Add a list of recipes, e.g. by running
>>>
>>>$ pybombs recipes add gr-recipes 
>>> git+https://github.com/gnuradio/gr-recipes.git
>>>$ pybombs recipes add gr-etcetera 
>>> git+https://github.com/gnuradio/gr-etcetera.git
>>>
>>>3.
>>>
>>>Create a prefix (a place to store your local installation):
>>>
>>>$ pybombs prefix init /path/to/prefix -a myprefix
>>>
>>>All commands after this will use myprefix as the default prefix. You
>>>can change the default prefix later by runningpybombs config
>>>default_prefix NEWPREFIX
>>>4.
>>>
>>>Start installing:
>>>
>>>$ pybombs [-p myprefix] install gnuradio gr-osmosdr
>>>
>>>
>>> After step 4 I'm getting the below error:
>>>
>>> *CMake Error: The source directory "/home/shahnaz/Lab3/src/osmo-**sdr"
>>> does not appear to contain CMakeLists.txt.*
>>> *Specify --help for usage, or press the help button on the CMake GUI.*
>>> *PyBombs.monitor_process() - DEBUG - Thread signaled termination or
>>> returned*
>>> *PyBombs.monitor_process() - DEBUG - Return value: 1*
>>> *PyBombs.Packager.source - ERROR - Problem occurred while building
>>> package osmo-sdr:*
>>> *Process returned value: 1*
>>> *PyBombs.install - ERROR - Error installing package osmo-sdr. Aborting.*
>>>
>>> I don't know why the osmo-sdr folder is not getting build correctly.
>>> when I look at the folder  the Cmake file is under
>>> "/home/shahnaz/Lab3/src/osmo-sdr/software/libosmosdr"  subfler not in the
>>> main folder.
>>>
>>> Did some one now how can I fix it?
>>>
>>>
>>> Thanks,
>>> shahnaz
>>>
>>>
>>> ___
>>> Discuss-gnuradio mailing list
>>> Discuss-gnuradio@gnu.org
>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>
>>>
>>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Pybomb installation error

[Anon Lister]

-v has to go before install. Ran into this the other day.
On Apr 21, 2016 11:29 AM, "Jason Matusiak" 
wrote:

> > $ pybombs [-p myprefix] install gnuradio gr-osmosdr -v
>
> I ran it, but it thinks that -v is a recipe and it errors out there.  If
> instead I run $ pybombs -v [-p myprefix] -v install gnuradio gr-osmosdr, i
> get:
> 
> PyBombs.Packager.source - DEBUG - Configuring recipe uhd
> PyBombs.Packager.source - DEBUG - Using vars - {'config_opt': '',
> 'builddir': '/home/jmat/gnuradio/src/uhd/build'}
> PyBombs.Packager.source - DEBUG - In cwd -
> /home/jmat/gnuradio/src/uhd/build
> PyBombs._process_thread() - DEBUG - Executing command `CC= CXX= cmake ..
> -DCMAKE_BUILD_TYPE=RelWithDebInfo
> -DCMAKE_INSTALL_PREFIX=/home/jmat/gnuradio  -Wno-dev'
> CMake Error: The source directory "/home/jmat/gnuradio/src/uhd" does not
> appear to contain CMakeLists.txt.
> Specify --help for usage, or press the help button on the CMake GUI.
> PyBombs.monitor_process() - DEBUG - Thread signaled termination or returned
> PyBombs.monitor_process() - DEBUG - Return value: 1
> PyBombs.Packager.source - ERROR - Problem occurred while building package
> uhd:
> Process returned value: 1
> PyBombs.install - ERROR - Error installing package uhd. Aborting.
> jmatusiak@wk-jmatusiak-02:~/.pybombs/recipes/gr-recipes$
> 
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] 3.7.9.2 Win64 binaries ready + Build scripts

[Anon Lister]

You can run powershell in VS? Neat. I've been doing it all in the
powershell terminal, (and I fell back to a cygwin terminal when I had
a moment of weakness trying to tail -f something and not wanting to
type gc -wai -ta1 ) To be honest I haven't even opened VS.
However, when in Rome...lets see, I had to install an extension, also
found they have a vim extension. Tab completion is nice. Will try
this.

Yeah I saw that in the comment at the top of the script. For debugging
I actually copied the Python script and removed all the other sections
but wx, because you weren't kidding about it taking a while. I guess
from what I read nmake doesn't do parallel builds. Shame. Looks like 4
and 5 completed successfully though.


So on step 6... ran into:
"glfw...shallow cloned
cloning GNURadio...fatal: Not a git repository (or any of the parent
directories): .git
fatal: Not a git repository (or any of the parent directories): .git
complete"

Cryptic. Anywho. Log:
"Submodule 'volk' (https://github.com/gnuradio/volk.git) registered
for path 'volk'
Cloning into 'volk'...
error: no such remote ref fcfc49dbb6e1e861c4fbdb02502bf18599b2fd0c
Fetched in submodule path 'volk', but it did not contain
fcfc49dbb6e1e861c4fbdb02502bf18599b2fd0c. Direct fetching of that
commit failed."

Its odd, I can get to that path on github,
https://github.com/gnuradio/volk/tree/fcfc49dbb6e1e861c4fbdb02502bf18599b2fd0c
but it doesn't show up in git log, and wont work in git checkout. It
looks like this commit's parent was merged by Nathan West on Jan 29.
Perhaps he squashed the commit somehow when he did the merge? The code
changes in that commit do appear to be in place in maint. Anyway, I'll
pick this up tonight, but I'll probably just checkout the latest, or
at least your latest commit from maint and build with that, assuming
that you will eventually point the submodule to a newer commit anyway
as this seems to be just a git issue.

-Anon

On Apr 18, 2016 10:11 AM, "Geof Nieboer" <gnieb...@corpcomm.net> wrote:
>
> Good news.  The out-file fix must have missed a commit somehow, I distinctly 
> remember making and fixing that.  Oh well, thanks.
> The other is interesting, I'm not sure why it worked on mine then.  I'm 
> already patching that file to recognize VC14, so just need to amend the patch.
>
> As you continue to experiment, in case you haven't already figured it out, 
> once you open the scripts project the first time in VS 2015, just run 
> Setup.ps1 once to set the environment, then you can run any of the scripts 
> individually, and by setting the $configuration variable (shortcuts at bottom 
> of several scripts) you can usually just run any individual "sub-build" on 
> it's own to save time and incrementally move forward.  But it looks like 
> you've already gotten past the toughest part, so that's excellent..
>
> On Mon, Apr 18, 2016 at 2:27 PM, Anon Lister <listera...@gmail.com> wrote:
>>
>> Aha. Found the error. I don't know how you didn't encounter it in your
>> builds, but in the build-wxpython.py script, line 443 fails, it's up
>> in the log. It sets install_dir to some variables defined in a if not
>> windows block higher up. This causes the script to bomb at install due
>> to an undefined variable. I just set install_dir to "" and validate
>> was successful.
>>
>> Thanks for the tip on looking for the _core_.pyd, that's what lead me
>> to it, it wasn't present anywhere but in the build directory (and a
>> few other places on my box, but all from timestamps way before the
>> build). Anyway, that step of the script is rebuilding now, just to be
>> sure it works.
>>
>> I dug into the Step5-consolidation error a bit, it looks like its failing 
>> with
>>
>> "Consolidating Qt...Out-File : A parameter cannot be found that
>> matches parameter name 'path'.
>> At C:\gr-build\scripts\Step5-ConsolidateLibs.ps1:67 char:23
>> + "[Paths]" | out-file -path $root/build/$configuration/bin/qt.conf ...
>> +  ~
>> + CategoryInfo  : InvalidArgument: (:) [Out-File],
>> ParentContainsErrorRecordException
>> + FullyQualifiedErrorId :
>> NamedParameterNotFound,Microsoft.PowerShell.Commands.OutFileCommand"
>>
>> According to [1] out-file accepts -FilePath as an option. I switched
>> to that (actually just ran that line on console) and it seemed to
>> work, so that one may be an easy fix. I'll kick it off once the python
>> builds finish. Probably wont get back to it till tonight.
>>
>> Yeah my goal here is mainly to reproduce the build, (and use it as a
>> motivating project to learn a little powershell), then hopefully
>> contribute to getting my favorite OOT'

Re: [Discuss-gnuradio] 3.7.9.2 Win64 binaries ready + Build scripts

[Anon Lister]

Aha. Found the error. I don't know how you didn't encounter it in your
builds, but in the build-wxpython.py script, line 443 fails, it's up
in the log. It sets install_dir to some variables defined in a if not
windows block higher up. This causes the script to bomb at install due
to an undefined variable. I just set install_dir to "" and validate
was successful.

Thanks for the tip on looking for the _core_.pyd, that's what lead me
to it, it wasn't present anywhere but in the build directory (and a
few other places on my box, but all from timestamps way before the
build). Anyway, that step of the script is rebuilding now, just to be
sure it works.

I dug into the Step5-consolidation error a bit, it looks like its failing with

"Consolidating Qt...Out-File : A parameter cannot be found that
matches parameter name 'path'.
At C:\gr-build\scripts\Step5-ConsolidateLibs.ps1:67 char:23
+ "[Paths]" | out-file -path $root/build/$configuration/bin/qt.conf ...
+  ~
+ CategoryInfo  : InvalidArgument: (:) [Out-File],
ParentContainsErrorRecordException
+ FullyQualifiedErrorId :
NamedParameterNotFound,Microsoft.PowerShell.Commands.OutFileCommand"

According to [1] out-file accepts -FilePath as an option. I switched
to that (actually just ran that line on console) and it seemed to
work, so that one may be an easy fix. I'll kick it off once the python
builds finish. Probably wont get back to it till tonight.

Yeah my goal here is mainly to reproduce the build, (and use it as a
motivating project to learn a little powershell), then hopefully
contribute to getting my favorite OOT's building. So no taking the
cheap route. :) I'm still amazed you got all this stuff building on
windows, most of it is a pain to build even on its native platform.
heh.

-Anon


[1] https://technet.microsoft.com/en-us/library/hh849882.aspx

On Apr 18, 2016 4:02 AM, "Geof Nieboer" <gnieb...@corpcomm.net> wrote:
>
> Anon,
>
>>
>> which seems to just be a sanity check that something we expected to build 
>> was not
>
>
> Exactly right.  It's not perfect but usually works.
>
>> ran setup.ps1 before I saw the ~RUNME_FIRST.ps1
>
>
> ~RUNME_FIRST creates the basic directory tree for the build in the location 
> you specify. You will want to re-run that with I:/gr-build as the root to 
> ensure all the directories you need were created (but that's likely not the 
> problem with WX but might be related to the consolidation fail).  You can 
> abort it after it starts running the Step1 script.
>
>>  just symlinked C:/gr-build to I:/gr-build
>
>
> Hmm, you shouldn't have had to do that, I will dig deeper there.
>
>> whats special about wx
>
>
> WX is just plain special.  It was problematic to get to build consistently, 
> so I'm not surprised that it is where your build failed, unfortunately.
>
>> I did see in the comments something about debug builds not working 
>> correctly,  and there's a workaround
>
>
> Yes, that comment is about building WX itself in a debug mode, not the 
> overall build.  The workaround is already in place which just to always 
> builds WX in release.
>
>> Any ideas what could be wrong?
>
>
> Well, like you said, the build logs look clean, which is certainly odd.  I 
> think I would start with trying to search the computer for _core_.pyd and see 
> where copies of it are, perhaps it's installing the package in the wrong 
> location?  Then I'd also look for the slew of Wx DLLs, they should be in 
> $pythonroot/DLLs  I'm fairly certain.
>
> Later when I'm back at the machine I will rebuild mine and compare the logs 
> side by side and perhaps something with jump out.  Obviously a cheap 
> workaround is to download the dependency pack and manually copy over the 
> WX-related dirs in site-packages and the DLLs into /DLLs.  But that doesn't 
> fix the underlying issue.
>
> Geof
>
> On Sun, Apr 17, 2016 at 9:20 PM, Anon Lister <listera...@gmail.com> wrote:
>>
>> Yep, my bad on UHD, used to doing git builds and seeing 3.10. Cool yeah gqrx 
>> would be the priority, baz is just a nice to have (and its a bit dated as 
>> its all in WX which seems to be going the route of deprecation).
>> So for some feedback, I installed the binaries and everything seems to work 
>> good. Hooked up the UHD and was able to receive a decent sample rate without 
>> issue. Only small issue is was a popup on first run that said:
>>
>> "The xterm executable 'xterm' is missing.
>>
>> You can change this setting in your gnuradio.conf, in section [grc], 
>> 'xterm_executable'.
>>
>> (This message is shown only once)"
>>
>> Which is understandable, as xterm is not built.  

Re: [Discuss-gnuradio] 3.7.9.2 Win64 binaries ready + Build scripts

[Anon Lister]

Yep, my bad on UHD, used to doing git builds and seeing 3.10. Cool yeah
gqrx would be the priority, baz is just a nice to have (and its a bit dated
as its all in WX which seems to be going the route of deprecation).
So for some feedback, I installed the binaries and everything seems to work
good. Hooked up the UHD and was able to receive a decent sample rate
without issue. Only small issue is was a popup on first run that said:

"The xterm executable 'xterm' is missing.

You can change this setting in your gnuradio.conf, in section [grc],
'xterm_executable'.

(This message is shown only once)"

Which is understandable, as xterm is not built.  Anyway, after clicking ok
everything works.

On the build side, first off, I'll say while I'm quite proficient on the
Linux side, on the windows side I'm pretty noobish, so the first errors I
received (missing io.h header, among other errors), appeared to be due to
me having old VS 2012 only half removed which confused 14.. Anywho, after
figuring that out and cleaning it up everything went good till the WX
python build. But first I'll throw in that I did install VS2014 into an
alternate path, this caused several issues with checks, I ended up creating
the windows equivalent of a symlink (or maybe multi-disk hardlink, think
its called a junction) and that solved that issue, but also the scripts ask
for a location to place its build files, I tried I:/gr-build but received
errors where directories in C:/gr-build were missing, I just symlinked
C:/gr-build to I:/gr-build and things seemed fine. I only bring it up since
the build scripts asked for a location. Perhaps it was something I did as I
first ran setup.ps1 before I saw the ~RUNME_FIRST.ps1. Anyway, back to the
WX error:

Got the error "Validation Failed,
C:/gr-build\src-stage2-python\gr-python27\lib\site-packages\wx-3.0-msw\wx\_core_.pyd
was not found and is required" which seems to just be a sanity check that
something we expected to build was not(i did independently verify its not
there, theres no wx* in site-packages), I've uploaded the log for
wx-python[1], let me know if you need any more info.

The build appears to stop there. Not sure where to go with debugging as
there appears to be no error, only some warnings? I'm also not familiar
with wheel, though one would assume it produces the whl installer files. I
did test removing the WX block and Step4 runs to completion. So it appears
to be something with WX. I did see in the comments something about debug
builds not working correctly,  and there's a workaround. For completeness,
I went ahead and commented out the Verify line and all builds (AVX,
ReleaseDLL, Debug ) appear to generate this same log (except for folder
names and such), and all do not generate the appropriate pyd file.

Any ideas what could be wrong? Or maybe whats special about wx as compared
to the other python modules? If it was a bunch I would suspect something in
my env may just be incorrect(Which, very well may be the case), but it
seems just that one library.

P.S. I did just try to bypass it for debugging purposes, but I ended up
with a different error on the consolidation step(not with WX) but lets take
those one at a time.

Also, if you want, I can take this to github/issues.

-Anon

[1] http://filebin.ca/2e5LIv6ROV29/39-ReleaseDLLwxpython.txt

On Fri, Apr 15, 2016 at 3:43 AM, Geof Nieboer <gnieb...@corpcomm.net> wrote:

> Anon,
>
> UHD 3.9.3 is the most current release from Ettus.
>
> gqrx is on my to-do list, and in fact there are code stubs in the scripts
> already for it.  What stopped me is that it needs qt5 built, whereas GR is
> on qt4 still, so I wanted to get out what I had first before re-attacking
> that one.  But once I have that done (and Qt5 appears way easier to build
> than 4), then I'll get cracking on it.  gr-baz I have not taken a look at,
> but I will do so.
>
> On the downloads page in the website, I tried to keep track of which
> library required what other libraries as I was going through it, so you'll
> see that listed, perhaps that might be useful in creating a dependency
> graph.  I don't guarantee it's 100% complete, though.
>
> Yes, please let me know how the build goes.  Take a look at the "Issues"
> in the readme.  Biggest recurring irritation I had was downloads that would
> fail partway through then appear later as build failures.  I would like to
> move to a hash verification step after the download, but for the moment it
> is what it is.  And once the downloads have been successful once, you
> should be smooth sailing as it will keep them cached in the 'packages'
> subdir.
>
> Geof
>
> On Fri, Apr 15, 2016 at 9:41 AM, Anon Lister <listera...@gmail.com> wrote:
>
>> This is awesome, I will test out the build process this weekend on 10.
>> Any reason for the slightly older uhd release? I'd love to get gr-baz and
&

Re: [Discuss-gnuradio] 3.7.9.2 Win64 binaries ready + Build scripts

[Anon Lister]

This is awesome, I will test out the build process this weekend on 10. Any
reason for the slightly older uhd release? I'd love to get gr-baz and gqrx
working on Win.

I'm also somewhat interested in stealing a pre-compiled list of
dependencies for my somewhat crazy project of building GR + some OOTs on
RHEL 6. Talk about dependency hell. ;p
On Apr 14, 2016 6:24 AM, "Geof Nieboer"  wrote:

> All,
>
> Some may recall in the fall I posted a link to a beta windows installer.
> I'm happy to report that I'm releasing new versions today for the 3.7.9.2
> release, compatible with Windows 7/8/10.  All dependencies are included,
> and all are built natively using MSVC 2015, no Cygwin or MinGW required.
> It's about a 300MB package download.
>
> I've also refactored the entire build process used to make the msi's and
> gotten it down to a series of Powershell scripts that can either:
> 1- Build the entire GNURadio windows dependency chain from source and then
> build GNURadio itself.
> 2- Download a prebuilt "dependency pack" as binaries and then
> build GNURadio and a couple OOT modules
>
> The binaries (for both GR and the dependencies) can be found at
> http://www.gcndevelopment.com/gnuradio.  The scripts themselves are
> hosted at http://github.com/gnieboer/gnuradio_windows_build_scripts.
> While the binaries have no dependencies, the build scripts have several,
> but all mandatory dependencies are free to install.  The various patches
> required to make everything build on Win32/MSVC are either workarounds
> built into the scripts, patches downloadable on the website, or forked
> repos on my github account.  For the most part pull requests have been
> submitted upstream.
>
> All GR components except gr-comedi are installed, and several OOT blocks
> are also included by default, including UHD 3.9.3, gr-fosphor,
> and gr-osmosdr with most drivers.  The windows audio sink has also been
> refactored to double buffer to avoid the skipping others have reported.
>
> It uses OpenBLAS for numpy/scipy to stay GPLv3 compliant...users can
> replace it with an MKL-based version as a wheel from the downloads page
> should more performance be desired.
>
> More information is available on the website.  I hope both the binaries
> and scripts are useful and look forward to feedback.
>
> Geof
>
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] raspi FAQ/HOWTO/recipe ??????

[Anon Lister]

Have you seen [1]? it looks like he hit all the same issues I did when
building on a pi3(raspberrian, not Debian but you might run into some of
the same). The newer 3, as long as you give it some swap space can get the
compile done in only a few hours with a make -j 3 or 4.

http://lukeberndt.com/2016/compiling-gnuradio-on-a-raspberry-pi/
On Apr 12, 2016 10:25 PM, "Rob Roschewsk"  wrote:

> Hi all,
>
> I'd like to compile GR from source for a raspberry pi (arm) ... I know
> there are some flags that need to be passed to cmake but I can't find a
> complete list ... or at least a consistent list
>
> Is there a reference I could use???
>
> Thanks!
>
> --> Rob, KA2PBT
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] dive into gnu-radio

[Anon Lister]

(oops, didn't reply list).

Ahahaha. I was thinking of that block when I made my last comment.

On Wed, Mar 16, 2016 at 8:40 PM, Anon Lister <listera...@gmail.com> wrote:

> Ahahaha. I was thinking of that block when I made my last comment.
>
> On Wed, Mar 16, 2016 at 8:34 PM, Timothée COCAULT <
> timothee.coca...@gmail.com> wrote:
>
>> Hi,
>>
>> 2016-03-16 20:36 GMT+01:00 Desmond Crozby <hup...@gmail.com>:
>>
>>> What I need is:
>>> 1) understand the blocks, their purpose and what they do
>>> 2) learn how to create a minimal scenario using grc
>>> 3) learn how to create blocks of my own
>>> 4) create more complicated scenario.
>>>
>>> I think there is cruel lack of explanation (not documentation) for the
>> GNU Radio blocks.
>> The example that struck me is the M clock recovery block.
>> The resources available are the code, the documentation, and the paper
>> cited in the documentation (not available for free though).
>> However, the best resource I found was a blog post [1] giving some notes,
>> facts and illustration on how this block works.
>> It's not an in-depth view of the algorithm used, but gives some hints on
>> how to use the block in practice.
>>
>> This is really the kind of things I would love to see (and contribute !)
>> for each block, but AFAIK, there is no place in the gnuradio ecosystem for
>> such documentation.
>>
>> [1]
>> https://www.tablix.org/~avian/blog/archives/2015/03/notes_on_m_m_clock_recovery/
>>
>>
>>
>> 2016-03-16 22:10 GMT+01:00 Martin Braun <martin.br...@ettus.com>:
>>
>>> Now, there's lots of very good books out there that go into DSP and
>>> wireless communication. They're usually written to address
>>> university-level students. But how do we condense them into nice and
>>> easy tutorials? It's hard.
>>>
>>
>> Now concerning learning DSP theory, I feel that "book knowledge" or
>> tutorials isn't enough for using GNU Radio.
>> For example, sometimes I can't stay if my signal looks good or if it's
>> just noise. If my demodulation flowgraph doesn't work, I don't know which
>> step messed up, how to check if my data makes sense, which parameter I
>> should change.
>>
>> This is the kind of things you get by seeing experimented people tackle
>> real life problems.
>> I watched a workshop of Balint Seeber (at DEF CON) and learned some great
>> things on DSP, analysis, and GNU Radio.
>> These kind of resources are really great, and I'd love to see more of
>> them.
>>
>> Cheers,
>>
>> Timothée.
>>
>> 2016-03-16 22:53 GMT+01:00 Tom Coleman <t...@soaringclub.org>:
>>
>>>
>>> On Mar 16, 2016, at 3:36 PM, Desmond Crozby <hup...@gmail.com> wrote:
>>>
>>> …
>>>
>>>
>>> I saw this reading suggestion:
>>> https://gnuradio.org/redmine/projects/gnuradio/wiki/SuggestedReading ,
>>> but the list is extensive and grouped by topic, basically I don't know
>>> where to start from.
>>>
>>>
>>> Software Radio in General
>>> Has anyone bothered to check these links lately?
>>>
>>>
>>>
>>> ___
>>> Discuss-gnuradio mailing list
>>> Discuss-gnuradio@gnu.org
>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>
>>>
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] dive into gnu-radio

[Anon Lister]

Also coming from a formal software engineering background, I found Michael
Ossman's SDR with HackRF(https://greatscottgadgets.com/sdr/) series very
informative. It has "homework" sections and starts with very little in
assumptions of your prior knowledge. You dont need a hackrf, any sdr,
including $15 RTL stick will do for most things. Or you can use GR to
follow along and you'll get quite a bit out even without an SDR.  Sofar it
doesn't go very deep, but he covers demodulation of FM and getting data off
a Wireless Key Fob from a car, which uses OOK modulation, and he adds new
lessons every now and then.  This will not tell you when you need to use a
particular type of filter, but its good at getting you thinking about the
problem your trying to solve. You mentioned wanting to go lower in the
protocol stack. Modern digital communications are usually complicated
protocols utilizing several types of modulations. I would start with older
or simpler protocols first, but either way this will involve knowledge of
digital modulations. Most of the time people recommend starting from the
analog side, but I find the digital side easier from a CS background. I
would also start by familiarizing yourself with basic digital modulations
OOK, ASK, FSK, PSK, then move onto their variants, such as MSK, QPSK, QAM,
etc(https://en.wikipedia.org/wiki/Modulation#Digital_modulation_methods).
GR has blocks for almost all the basic modulators and demodulators built
in. Basically all of these are ways to map a stream of bits onto the
communication medium. If you start with a stream of bits, ask yourself how
each of the above modulations would get those bits from point a to point
b.  Try implementing them in GR. Setup something like  ->
 -> channel model -> < demodulator >   -> . The key
here is the channel model. Its an awesome learning tool because it will
allow you to model some typical problems of communication systems. When you
lower the signal-to-noise ratio, for example you'll find you may need to
add new blocks to compensate for the loss of signal quality. If you ask
these more pointed questions, such as which block would help compensate for
X,  the list, I'm sure, will be willing to help you along. Also, make sure
you attach constellation and FFT sinks everywhere, then you can actually
see the effects of various blocks on your data stream (The QT GUI sink has
most built in). Normally with digital modulations you map bits to a symbol
of some kind, these symbols are usually displayed in a constellation sink.
Observe the effect of channel model parameters on the constellation plot of
your data, and the integrity of your output file. Attach sliders to
basically any parameter in any block and adjust them at run time to see the
effect on your stream.

As to documentation, as Martin said, documentation is amazingly hard when
you know the things involved. Think of typical code comments you've seen as
a developer. How many times do you see Function X(param1, param2, param3);
And above it a comment, #Does X on param1 and param2 using param3. Alot of
GR blocks have some documentation, they usually state what the block does
in math, which is great, if your coming from that background, but they dont
include things like "You will probably need to use this block when your
constellation looks like  or to correct for ." Even given that,
the documentation on the blocks themselves is somewhat helpful. It is on
the last tab in the properties window for all the blocks. The best person
to contribute to the documentation is probably you. As you learn things,
write it down, why you think it worked or didn't, and then revise as you go
along and offer it up for inclusion in the wiki.


On Mar 16, 2016 5:54 PM, "Tom Coleman"  wrote:

>
> On Mar 16, 2016, at 3:36 PM, Desmond Crozby  wrote:
>
> …
>
>
> I saw this reading suggestion:
> https://gnuradio.org/redmine/projects/gnuradio/wiki/SuggestedReading ,
> but the list is extensive and grouped by topic, basically I don't know
> where to start from.
>
>
> Software Radio in General
> Has anyone bothered to check these links lately?
>
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Segfault in volk_32fc_x2_multiply_32fc_a_avx2_fma

[Anon Lister]

To answer your question however, he's misguided. Fftw and volk both have
methods (volk_profile, fftw-wisdom) to profile and determine the best
instructions to use for cases where they have multiple options, it's not
going to get noticeably slower by compiling the extra stuff in.
On Mar 9, 2016 8:47 AM, "devin kelly"  wrote:

> Thanks for the help, I don't think I could have figured this out on my own.
>
> This is because I'm on RHEL7 (argh!).  My libfftw.so doesn't contain any
> references to AVX. For me there are a couple of options for fixing this:
>
> 1) Use Nathan's branch.
> 2) Rebuild fftw with AVX support
> 3) Rebuild GR and Volk without AVX.
>
> I tried 2) first and noticed this in the spec file that was in the source
> RPM I was trying to rebuild:
>
> %ifarch %{ix86} x86_64
> # Enable SSE2 support for x86 and x86_64
> # (no avx as it is claimed to drastically slower)
> for((i=0;i<2;i++)); do
>  prec_flags[i]+=" --enable-sse2"
> done
> %endif
>
> Is the spec file author right?  Now I'm a little confused about the
> approach I should take.  I'll probably just go with 1) in the mean time.
>
> Thanks again Nathan,
> Devin
>
> On Wed, Mar 9, 2016 at 1:06 AM, West, Nathan 
> wrote:
>
>> The a and c vectors come from gr:fft objects' internal buffers. These are
>> internally created with fftwf_malloc (lines 152/156 of gr-fft/lib/fft.cc).
>> fftwf_malloc is obviously not generating buffers with proper alignment so
>> you're seeing a 50% (per buffer) that this segfaults. I'll note that this
>> is also only an issue with fftwf buffers when fftwf isn't built with AVX
>> support (and therefore nothing in fftwf requires  a 32-byte aligned buffer).
>>
>> Andy Walls (thanks!) pointed out on IRC that we had a similar issue years
>> ago with a QT sink.
>>
>> I have a branch that should fix this (
>> https://github.com/n-west/gnuradio/tree/fft-avx-alignment). I also
>> suggest you look in to getting a version of fftwf built with AVX. I don't
>> know if there's a good way to tell, but if I run readelf -a on my
>> libfftw3.so I see some functions with avx in the name.
>>
>> Cheers,
>> nw
>>
>>
>> On Tue, Mar 8, 2016 at 1:31 PM, devin kelly  wrote:
>>
>>> OK, here's my C program:
>>>
>>> #include 
>>> #include 
>>> #include 
>>> #include 
>>>
>>> int main() {
>>>
>>> size_t alignment = volk_get_alignment();
>>>
>>> uint8_t* ptr;
>>>
>>> ptr = (uint8_t*)volk_malloc(1000 * sizeof(uint8_t), alignment);
>>> printf("alignment = %lu, ptr = %x, *ptr = %u\n", alignment, ptr,
>>> *ptr);
>>> volk_free((void*)ptr);
>>> ptr = NULL;
>>>
>>>
>>> return 0;
>>> }
>>>
>>>
>>> Compile:
>>>
>>> $ gcc volk_test.c -o volk_test -lvolk -L/local_disk/gr_3.7.9_debug/lib
>>>
>>> It's output:
>>>
>>> $ ./volk_test
>>> Using Volk machine: avx2_64_mmx_orc
>>> alignment = 32, ptr = 151b040, *ptr = 00
>>>
>>> Also, I've attached the output from the preprocessor, this command:
>>>
>>> $ /usr/bin/cc  -DHAVE_AVX_CVTPI32_PS -DHAVE_CPUID_H -DHAVE_DLFCN_H
>>> -DHAVE_FENV_H -DHAVE_POSIX_MEMALIGN -DHAVE_XGETBV -Wall -fvisibility=hidden
>>> -g -I/local_disk/gr_3.7.9_src/volk/build_debug/include
>>> -I/local_disk/gr_3.7.9_src/volk/include
>>> -I/local_disk/gr_3.7.9_src/volk/kernels
>>> -I/local_disk/gr_3.7.9_src/volk/build_debug/lib
>>> -I/local_disk/gr_3.7.9_src/volk/lib -I/usr/include/orc-0.4  -E  -fPIC -o
>>> volk_malloc_preprocessed   -c
>>> /local_disk/gr_3.7.9_src/volk/lib/volk_malloc.c
>>>
>>> I just found the compiler step from from doing 'VERBOSE=1 make' then
>>> changed the output and added -E.  I attached volk_malloc_preprocessed as
>>> well.
>>>
>>> It looks like this is my volk_malloc():
>>>
>>>
>>> void *volk_malloc(size_t size, size_t alignment)
>>> {
>>>   void *ptr;
>>>
>>>
>>>
>>>
>>>   if (alignment == 1)
>>> return malloc(size);
>>>
>>>   int err = posix_memalign(, alignment, size);
>>>   if(err == 0) {
>>> return ptr;
>>>   }
>>>   else {
>>> fprintf(stderr,
>>> "VOLK: Error allocating memory "
>>> "(posix_memalign: error %d: %s)\n", err, strerror(err));
>>> return ((void *)0);
>>>   }
>>> }
>>>
>>>
>>>
>>> Devin
>>>
>>>
>>>
>>> On Tue, Mar 8, 2016 at 11:37 AM, West, Nathan <
>>> n...@ostatemail.okstate.edu> wrote:
>>>

 On Tue, Mar 8, 2016 at 10:58 AM, devin kelly 
 wrote:

> Calling 'info variables' (or args or locals) the last few frames
> didn't give me any real info so I built a copy of GR/Volk with debug
> symbols.  I ran the FG again, this time from GDB, here's my back trace.  
> In
> this backtrace you can see the arguments passed in each call.  I have an
> i7-5600U CPU @ 2.60GHz, the volk_profile is appended at the bottom.
>

 Excellent. Thanks for going through that extra step. It really helps.


>
> Here's are the links for the relevant code:
>
>
> 

Re: [Discuss-gnuradio] Segfault in volk_32fc_x2_multiply_32fc_a_avx2_fma

[Anon Lister]

I would use fftw source from their site not rhels source rpm, unless you
need to deploy it on a large number of machines. (Even then I would pull
latest source and update the srpm)

You can just build fftw from source. Add almost all the configure options.
We do this on rhel 6 because their version doesn't support wisdom or take
advantage of any recent CPU releases. It should install in /usr/local by
default. Just add the library path to /etc/ld.so.conf and run ldconfig and
you'll be set.
On Mar 9, 2016 8:47 AM, "devin kelly"  wrote:

> Thanks for the help, I don't think I could have figured this out on my own.
>
> This is because I'm on RHEL7 (argh!).  My libfftw.so doesn't contain any
> references to AVX. For me there are a couple of options for fixing this:
>
> 1) Use Nathan's branch.
> 2) Rebuild fftw with AVX support
> 3) Rebuild GR and Volk without AVX.
>
> I tried 2) first and noticed this in the spec file that was in the source
> RPM I was trying to rebuild:
>
> %ifarch %{ix86} x86_64
> # Enable SSE2 support for x86 and x86_64
> # (no avx as it is claimed to drastically slower)
> for((i=0;i<2;i++)); do
>  prec_flags[i]+=" --enable-sse2"
> done
> %endif
>
> Is the spec file author right?  Now I'm a little confused about the
> approach I should take.  I'll probably just go with 1) in the mean time.
>
> Thanks again Nathan,
> Devin
>
> On Wed, Mar 9, 2016 at 1:06 AM, West, Nathan 
> wrote:
>
>> The a and c vectors come from gr:fft objects' internal buffers. These are
>> internally created with fftwf_malloc (lines 152/156 of gr-fft/lib/fft.cc).
>> fftwf_malloc is obviously not generating buffers with proper alignment so
>> you're seeing a 50% (per buffer) that this segfaults. I'll note that this
>> is also only an issue with fftwf buffers when fftwf isn't built with AVX
>> support (and therefore nothing in fftwf requires  a 32-byte aligned buffer).
>>
>> Andy Walls (thanks!) pointed out on IRC that we had a similar issue years
>> ago with a QT sink.
>>
>> I have a branch that should fix this (
>> https://github.com/n-west/gnuradio/tree/fft-avx-alignment). I also
>> suggest you look in to getting a version of fftwf built with AVX. I don't
>> know if there's a good way to tell, but if I run readelf -a on my
>> libfftw3.so I see some functions with avx in the name.
>>
>> Cheers,
>> nw
>>
>>
>> On Tue, Mar 8, 2016 at 1:31 PM, devin kelly  wrote:
>>
>>> OK, here's my C program:
>>>
>>> #include 
>>> #include 
>>> #include 
>>> #include 
>>>
>>> int main() {
>>>
>>> size_t alignment = volk_get_alignment();
>>>
>>> uint8_t* ptr;
>>>
>>> ptr = (uint8_t*)volk_malloc(1000 * sizeof(uint8_t), alignment);
>>> printf("alignment = %lu, ptr = %x, *ptr = %u\n", alignment, ptr,
>>> *ptr);
>>> volk_free((void*)ptr);
>>> ptr = NULL;
>>>
>>>
>>> return 0;
>>> }
>>>
>>>
>>> Compile:
>>>
>>> $ gcc volk_test.c -o volk_test -lvolk -L/local_disk/gr_3.7.9_debug/lib
>>>
>>> It's output:
>>>
>>> $ ./volk_test
>>> Using Volk machine: avx2_64_mmx_orc
>>> alignment = 32, ptr = 151b040, *ptr = 00
>>>
>>> Also, I've attached the output from the preprocessor, this command:
>>>
>>> $ /usr/bin/cc  -DHAVE_AVX_CVTPI32_PS -DHAVE_CPUID_H -DHAVE_DLFCN_H
>>> -DHAVE_FENV_H -DHAVE_POSIX_MEMALIGN -DHAVE_XGETBV -Wall -fvisibility=hidden
>>> -g -I/local_disk/gr_3.7.9_src/volk/build_debug/include
>>> -I/local_disk/gr_3.7.9_src/volk/include
>>> -I/local_disk/gr_3.7.9_src/volk/kernels
>>> -I/local_disk/gr_3.7.9_src/volk/build_debug/lib
>>> -I/local_disk/gr_3.7.9_src/volk/lib -I/usr/include/orc-0.4  -E  -fPIC -o
>>> volk_malloc_preprocessed   -c
>>> /local_disk/gr_3.7.9_src/volk/lib/volk_malloc.c
>>>
>>> I just found the compiler step from from doing 'VERBOSE=1 make' then
>>> changed the output and added -E.  I attached volk_malloc_preprocessed as
>>> well.
>>>
>>> It looks like this is my volk_malloc():
>>>
>>>
>>> void *volk_malloc(size_t size, size_t alignment)
>>> {
>>>   void *ptr;
>>>
>>>
>>>
>>>
>>>   if (alignment == 1)
>>> return malloc(size);
>>>
>>>   int err = posix_memalign(, alignment, size);
>>>   if(err == 0) {
>>> return ptr;
>>>   }
>>>   else {
>>> fprintf(stderr,
>>> "VOLK: Error allocating memory "
>>> "(posix_memalign: error %d: %s)\n", err, strerror(err));
>>> return ((void *)0);
>>>   }
>>> }
>>>
>>>
>>>
>>> Devin
>>>
>>>
>>>
>>> On Tue, Mar 8, 2016 at 11:37 AM, West, Nathan <
>>> n...@ostatemail.okstate.edu> wrote:
>>>

 On Tue, Mar 8, 2016 at 10:58 AM, devin kelly 
 wrote:

> Calling 'info variables' (or args or locals) the last few frames
> didn't give me any real info so I built a copy of GR/Volk with debug
> symbols.  I ran the FG again, this time from GDB, here's my back trace.  
> In
> this backtrace you can see the arguments passed in each call.  I have an
> i7-5600U CPU @ 2.60GHz, the volk_profile is appended at the bottom.