[Discuss-gnuradio] Announcing GrExtras family of JIT blocks - clang + llvm, orc, opencl

Hey all, The JIT Blocks in GrExtras just keep growing (now its a family): https://github.com/guruofquality/grextras/wiki/Blocks#wiki-awesome-jit-blocks * I mentioned the OpenCl block in a previous email: https://github.com/guruofquality/grextras/wiki/Opencl * There is now and ORC block as well.

Re: [Discuss-gnuradio] swig/python memory leak

The .i file includes the .h file where "my_type" is defined. isn't that enough? Josh Blum a écrit : On 05/27/2013 11:10 AM, Nada ABDELKADER wrote: Hi, May be this is not the appropriate place to post this problem but I'm working on gnuradio and USRPs and trying to access c++ objects from

Re: [Discuss-gnuradio] Performing callback function in GRC

Perhaps it would work better to treat the input as one variable. Use a tuple of numbers instead. You can make a text entry widget w/ converter type "Evaluate". The callback would probably look more like this: set_user_register(*\$user_reg_args) -josh Thanks, thats already a good solution. How

Re: [Discuss-gnuradio] Performing callback function in GRC

Perhaps it would work better to treat the input as one variable. Use a tuple of numbers instead. You can make a text entry widget w/ converter type "Evaluate". The callback would probably look more like this: set_user_register(*\$user_reg_args) -josh Thanks, thats already a good solution. How

[Discuss-gnuradio] RTL-SDR for GNU Radio v3.7

Since we're moving now towards the release of version 3.7 and the master branch has been updated to track that progress, all libraries that build off of and talk to GNU Radio must be updated appropriately. I've already started to do this with gr-osmosdr. Right now, I've updated their interface to

Re: [Discuss-gnuradio] 3.7 - nothing works :)

On Tue, May 28, 2013 at 2:21 AM, Ralph A. Schmid, dk5ras wrote: > Hi, > > It is not as bad as it sounds, but almost :) > > With building the last "master" on a 32bit Kubuntu 12.04 none of my grc > files work. They are all with analog stuff, FM TX and RX stuff with USRP1 as > transceiver, some RTL2

Re: [Discuss-gnuradio] 3.7 - nothing works :)

Hi, > Yes, we made the big move the other day towards the 3.7.0 release. > Basically, we made next into master, so master is tracking the 3.7 API branch > now. You should have noticed the ~1100 updates when you pulled master. Yes, of course. > All blocks and code that come with GNU Radio shoul

Re: [Discuss-gnuradio] swig/python memory leak

Hi, > I've already started to do this with gr-osmosdr. Right now, I've > updated their > interface to the RTL-SDR (tested) and HackRF (untested) to compile > against the new master branch of GNU Radio. You can use my repo here > as a remote with your current gr-osmosdr to get the gr-next branc

Re: [Discuss-gnuradio] 3.7 - nothing works :)

On 05/28/2013 05:59 AM, Ralph A. Schmid, dk5ras wrote: Hi, Yes, we made the big move the other day towards the 3.7.0 release. Basically, we made next into master, so master is tracking the 3.7 API branch The up-to-date version of build-gnuradio has, for a couple of weeks, been tweaked so tha

Re: [Discuss-gnuradio] 3.7 - nothing works :)

Hi, > The up-to-date version of build-gnuradio has, for a couple of weeks, been > tweaked so that by default it pulls "maint", which I believe should >now correspond to the 3.6.5 release. So "old stuff" should still work if > you're purely using build-gnuradio. It now has a "-m" option to >

[Discuss-gnuradio] Branch for gr-air-modes receiver and GNU Radio master (3.7) branch

I've updated the gr-air-modes application to work with the latest GNU Radio master branch. This is the aircraft Mode S transponder receiver by Nick Foster. See branch 'gnuradio-3.7' on: https://github.com/jmcorgan/gr-air-modes.git As an example of the type of changes needed to go from 3.6 to 3.7

Re: [Discuss-gnuradio] Releases planned, merge of 3.7 next branch into master

Yes, this is exactly what I needed; thanks! - MLD On May 27, 2013, at 10:09 PM, Johnathan Corgan wrote: > "release" -> v3.6.5 > "devel" -> maint branch > "next" -> master branch > > It will be a few weeks at least before we're ready to call 3.7.0 stable; in > the interim, 3.6.5 is the stable re

Re: [Discuss-gnuradio] git pull fails

On 05/27/2013 01:09 AM, Johnathan Corgan wrote: > On Sun, May 26, 2013 at 9:57 PM, Richard Farina wrote: > > >> ozzie gnuradio.git # git remote update >> Fetching origin >> error: Unable to find f8a41c725b4d7e5a37655b8d274a4d62f92745a4 under >> http://gnuradio.org/git/gnuradio.git >> Cannot obta

Re: [Discuss-gnuradio] Branch for gr-air-modes receiver and GNU Radio master (3.7) branch

On 05/28/2013 09:42 AM, Johnathan Corgan wrote: > I've updated the gr-air-modes application to work with the latest GNU Radio > master branch. This is the aircraft Mode S transponder receiver by Nick > Foster. > > See branch 'gnuradio-3.7' on: > > https://github.com/jmcorgan/gr-air-modes.git > I

Re: [Discuss-gnuradio] 3.7 - nothing works :)

On Tue, May 28, 2013 at 5:59 AM, Ralph A. Schmid, dk5ras wrote: > Hi, > >> Yes, we made the big move the other day towards the 3.7.0 release. >> Basically, we made next into master, so master is tracking the 3.7 API > branch >> now. You should have noticed the ~1100 updates when you pulled master.

Re: [Discuss-gnuradio] 3.7 - nothing works :)

> As my email said, this branch only currently supports the RTL-SDR and HackRF > interfaces. I haven't tried to update the interface to the osmosdr library, > which is what you are seeing. I think you can use -DENABLE_OSMOSDR=False > to turn this off. But then, you'll only be able to use the RTL-SD

Re: [Discuss-gnuradio] git pull fails

On Tue, May 28, 2013 at 7:18 AM, Richard Farina wrote: > Things are updating normally on all my systems at this time. Not sure > exactly what changed but my auto-{update,build} scripts started working > again sometime yesterday. > I suspect it was an result of aggressive caching by our CDN pro

Re: [Discuss-gnuradio] Branch for gr-air-modes receiver and GNU Radio master (3.7) branch

On Tue, May 28, 2013 at 7:15 AM, Richard Farina wrote: > If I may be so bold, it may be better for your consumers (us lowly > people that use the software) if you were to make an actual release > tarball (call it 0.0.0.0.1 for all I care) with support for the released > version of gnuradio and l

[Discuss-gnuradio] pmt_int.h error while building gnuradio 3.6.5 release in fedora 18

Hi, while compiling gnuradio 3.6.5 release on fedora 18 i got the following warning, how is it going to affect me: ### [ 3%] Generating documentation with doxygen /home/swrangsar/gnuradio-3.6.5/gruel/src/lib/pmt/pmt_int.h:243: Warning: include file pmt_un

Re: [Discuss-gnuradio] Branch for gr-air-modes receiver and GNU Radio master (3.7) branch

On 05/28/2013 10:48 AM, Johnathan Corgan wrote: > On Tue, May 28, 2013 at 7:15 AM, Richard Farina wrote: > > >> If I may be so bold, it may be better for your consumers (us lowly >> people that use the software) if you were to make an actual release >> tarball (call it 0.0.0.0.1 for all I care)

Re: [Discuss-gnuradio] pmt_int.h error while building gnuradio 3.6.5 release in fedora 18

sorry for that post, i think it just affects the documentation. thanks, swrangsar On Tue, May 28, 2013 at 9:23 PM, swrangsar basumatary wrote: > Hi, > > while compiling gnuradio 3.6.5 release on fedora 18 i got the following > warning, how is it going to affect me: > > #

Re: [Discuss-gnuradio] pmt_int.h error while building gnuradio 3.6.5 release in fedora 18

On Tue, May 28, 2013 at 8:55 AM, swrangsar basumatary wrote: > sorry for that post, i think it just affects the documentation. > No worries. Unfortunately, we don't get a lot of test coverage with Fedora, so these things tend to go unnoticed. What version of doxygen are you using? -- Johnath

[Discuss-gnuradio] build-gnuradio statistics

So, I've added a exit-handler routine to build-gnuradio to try to capture some basic statistics about success/failure when the script is run. I'd like some suggestions about automating uploading of this one-liner of stats data to some website somewhere so that I can review it. Maybe somethin

Re: [Discuss-gnuradio] build-gnuradio statistics

On Tue, May 28, 2013 at 9:14 AM, Marcus D. Leech wrote: > I'd like some suggestions about automating uploading of this one-liner of > stats data to some website somewhere so that I can review it. > Maybe something we can turn on on the gnuradio.org website? > You could ask in the script if th

Re: [Discuss-gnuradio] build-gnuradio statistics

On 05/28/2013 12:30 PM, Johnathan Corgan wrote: On Tue, May 28, 2013 at 9:14 AM, Marcus D. Leech > wrote: I'd like some suggestions about automating uploading of this one-liner of stats data to some website somewhere so that I can review it. Maybe some

Re: [Discuss-gnuradio] build-gnuradio statistics

Hi, I would solve this with a small PHP Script on the webserver (or whatever scripting language is available on the webserver). The script can evaluate the called URL including parameters. So in the build gnuradio script you would call something like this wget http://example.com/script.php?pa

Re: [Discuss-gnuradio] build-gnuradio statistics

On 05/28/2013 12:44 PM, Martin Lülf wrote: Hi, I would solve this with a small PHP Script on the webserver (or whatever scripting language is available on the webserver). The script can evaluate the called URL including parameters. So in the build gnuradio script you would call something lik

[Discuss-gnuradio] build-gnuradio updated

I just updated build-gnuradio -- after the change to the repo, a check that the script was doing was failing, due to the change in file structure between 3.6 and 3.7. Thanks to Jim Friel for finding this. -- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://

Re: [Discuss-gnuradio] Performing callback function in GRC

On 05/28/2013 04:32 AM, Florian Schlembach wrote: >> Perhaps it would work better to treat the input as one variable. Use a >> tuple of numbers instead. You can make a text entry widget w/ converter >> type "Evaluate". >> >> The callback would probably look more like this: >> set_user_register(*\

[Discuss-gnuradio] Bins smaller than pixels. was: WX GUI FFT Sink Performance

On 17-05-13 02:22, Marcus D. Leech wrote: Again, given the fact that your display geometry is likely less than 1280 wide, you'll simply lose information for FFTs larger than that. I one is looking for weak CW signals, in a waterfall, wouldn't a wide bin, make this signal invisible in among th

Re: [Discuss-gnuradio] Performing callback function in GRC

On 05/28/2013 01:15 PM, Josh Blum wrote: I guess at some point, the builtin GRC functionality isnt smart enough. I think you could obtain this with some custom python code. For example, howabout a custom xml for grc that calls self.my_usrp_source_block_id.set_user_reg, but all caches the address

Re: [Discuss-gnuradio] Bins smaller than pixels. was: WX GUI FFT Sink Performance

On 05/28/2013 01:28 PM, Simon IJskes wrote: On 17-05-13 02:22, Marcus D. Leech wrote: Again, given the fact that your display geometry is likely less than 1280 wide, you'll simply lose information for FFTs larger than that. I one is looking for weak CW signals, in a waterfall, wouldn't a wide

Re: [Discuss-gnuradio] Bins smaller than pixels. was: WX GUI FFT Sink Performance

On 5/28/2013 1:28 PM, Simon IJskes wrote: On 17-05-13 02:22, Marcus D. Leech wrote: Again, given the fact that your display geometry is likely less than 1280 wide, you'll simply lose information for FFTs larger than that. I one is looking for weak CW signals, in a waterfall, wouldn't a wide b

Re: [Discuss-gnuradio] Bins smaller than pixels. was: WX GUI FFT Sink Performance

I think the best approach is just to include every possible method in GNURadio. This can only make the platform more versatile. I make use of overlapping a lot because computation times are a pain. The trade-off in resolution is acceptable to me because it has limits that I can work around.

Re: [Discuss-gnuradio] Bins smaller than pixels. was: WX GUI FFT Sink Performance

On 05/28/2013 01:54 PM, Mark McCarron wrote: I think the best approach is just to include every possible method in GNURadio. This can only make the platform more versatile. I make use of overlapping a lot because computation times are a pain. The trade-off in resolution is acceptable to me b

Re: [Discuss-gnuradio] Import error of grextras, undefined symbol

can it be a permission problem? I tried added a print before the error and discovered this file it located succesfully many times when I use grc: /usr/local/lib/python2.7/dist-packages/gnuradio/extras/extras_swig.py /usr/local/lib/python2.7/dist-packages/gnuradio/extras/_extras_swig.so ('.so', 'r

[Discuss-gnuradio] A Clarification

Hi, I would appreciate if the following are clarified regarding USRP, 1.Is it necessary to have two daughter boards in USRP1 to receive data at two different frequencies? 2.If one daughterboard is used,can it receive the data individually and separately at different frequencies? Thanks!!

Re: [Discuss-gnuradio] A Clarification

Hi, I would appreciate if the following are clarified regarding USRP, 1.Is it necessary to have two daughter boards in USRP1 to receive data at two different frequencies? 2.If one daughterboard is used,can it receive the data individually and separately at different frequencies? Thanks!! It

Re: [Discuss-gnuradio] build-gnuradio statistics

So, given that my website maintains raw access logs that are available to me, I've updated build-gnuradio to do a wget call to a non-actually-there .php so that I can grab some parameters that will show up in the raw logs, that I can process from time to time. Easy peasy. The exit() handler

Re: [Discuss-gnuradio] A Clarification

Hope i am not asking a silly question.. Where can i find the "Dual -DDC"feature.Is it confined to a particular version.Since i don't find it . Thanks! - Manjusha -- View this message in context: http://gnuradio.4.n7.nabble.com/A-Clarification-tp41661p41664.html Sent from the GnuRadio mail

Re: [Discuss-gnuradio] A Clarification

Hope i am not asking a silly question.. Where can i find the "Dual -DDC"feature.Is it confined to a particular version.Since i don't find it . Thanks! For USRP1 and N2XX, you get it by default, and UHD figures out what to do (for the most part) based on your configuration. For B100, you need

[Discuss-gnuradio] tx & rx using 2-usrp N210 and RFX2400 setup

I am new to the gnu radio community, and want to know how my set up works over the air. I am using GNU Radio and 2- usrp N210's with RFX2400. Can some one provide an example .grc files for a digital modulation (like qpsk) so as to verify over the air transmission.I need to know how UHD works and ho