Re: [Discuss-gnuradio] FSK demodulation

[Marc Miller]

On Thu, Jun 19, 2014 at 12:35 PM, Marcus Müller 
wrote:

> Hi Marc,
>
> > Currently, I am trying to implement correlation receiver using FIR
> filters. I am looking into polyphase filterbank channelizer to implement
> correlation, but currently unable to do so because I currently do not
> know how to assign taps for channelizer.
>
> I should have pointed you at Tom's article on PFB channelizers and
> synthesizers [1].
>

Thanks, nice article! I am going to test it soon.


> > Oversampling at baseband ? I am currently sampling at 1Msps (usrp sink
> > sampling rate) for a tone spacing of 125KHz. You mean after the USRP sink
> > block I should upsample again and then do the correlation?  Or you mean
> > something else ? Please forgive me for asking too many question, I am
> still
> > learning.
> don't worry; this list is meant for GNU Radio discussion, I think things
> like exploring possibilities to do certain tasks in GNU Radio fit
> nicely, especially because you are considering using something "cool and
> new" like the PFBs in your approach. GNU Radio can always use more
> people actually trying to implement stuff!
>
> So: Oversampling is what you do when getting more samples out of your
> ADC than nyquist forces you to do. If you do 125k spacing 4FSK, then you
> have a total bandwidth of 750kHz + X, so 1MS/s is "just enough"; anyway,
> if you sample with let's say 3.125MS/s, than you'll have more samples.
> Within that received bandwidth, you will have the same signal as before,
> but now correlating against your known tone will give you a higher value
> than with only 1MS/s, and because noise stays uncorrelated, this will
> increase SNR. This is processing gain!
>
>
ADC in N210 is sampling at 100Msps, so you are saying that I can get
processing gain (better SNR) if I set the USRP sink sample rate higher than
IMsps i.e usrp_sink.sample_rate(3.125e6) instead of
usrp_sink.sample_rate(1e6) . Right ?

Also I read [1] that if I oversample by 2 then I gain 3dB in SNR, if
oversample by 4 I gain 6dB in SNR and so on, is that TRUE ? If this is true
I can get a lot of SNR improvement because ADCs are operating at 100Msps.



> >> ... encourage you to read a lot of books [1] and papers on this.
>
>
> > Thanks for the link, nice stuff.
> If you find something interesting, don't hesitate to add a new heading
> like "FSK demodulator technology" and add the references there; I think
> this list is something that could use broader usage :)
>

Sure! I 'll do that.


> >> Assuming you don't want phase jumps between symbols, why not just use
> >> the VCO block to generate frequencies out of your input values?
> > Wow! modulation is easy using VCO. A question, why would someone want
> phase
> > jump between symbols?
> In FSK systems, you'd usually want to avoid that, because phase jumps
> lead to spectral components that are not at  the frequency you shifted to.
> With PSK, phase jumps is your only way to encode data, and with QAM
> "half" of the information is encoded in phase. However, you usually see
> a pulse shaper after these, because transmitting a real phase
> discontinuity is somewhat physically impossible[2]. So these modulations
> get the spectrum of a phase-jumping system, smoothed by the spectral
> shape of the pulse shaping.
>
>
Thanks for the detail. Also, I got FSK modulator working using the VCO :)


Marc
[1]
http://www.dsprelated.com/showmessage/72731/1.php



> Greetings,
> Marcus
>
> [1]
>
> http://www.trondeau.com/examples/2014/1/23/pfb-channelizers-and-synthesizers.html
> [2] Basically, imagine the baseband signal as a sequence of rectangles
> in time; now, the fourier transform of a rectangle is a sin(x)/x, and
> that has a support that doesn't fit into a limited bandwidth.
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] usrp e110 in standalone mode ?

[Wafa Elhajhmida]

Hi,

I made an application on usrp e110 to send datas.

I would like to make it operate in a standalone mode.

Have you any suggestions to deal with this issue ?

Thanks for help.

Best regards,

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

Re: [Discuss-gnuradio] FSK demodulation

[Marcus Müller]

Hi Marc,
On 20.06.2014 09:38, Marc Miller wrote:
> ADC in N210 is sampling at 100Msps, so you are saying that I can get
> processing gain (better SNR) if I set the USRP sink sample rate higher
> than IMsps i.e usrp_sink.sample_rate(3.125e6) instead of
> usrp_sink.sample_rate(1e6) . Right ? Also I read [1] that if I
> oversample by 2 then I gain 3dB in SNR, if oversample by 4 I gain 6dB
> in SNR and so on, is that TRUE ? If this is true I can get a lot of
> SNR improvement because ADCs are operating at 100Msps. 
As long as your noise stays uncorrelated, and your signal samples do the
opposite, you will have this processing gain; so yes, this is basically
what is done.

So, the limiting factors here
a) the fact that you have but GigE between your host and your USRP,
meaning that you can't do more than
1e9b/s / (16 b/sample) / (2 sample/complex) = 31.25Msample/s over that
link at all, and since the the USRP can only do integer fractions of the
100MHz master rate, this will effectively be 25MS/s [1]; but even more
b) the fact that millions of samples are just *really much data* to
process, and if you can't keep up with the sample rate, then at some
point, UHD will have to drop samples, which will greatly distort your
signal.
> Thanks for the detail. Also, I got FSK modulator working using the VCO :)
Keep this going! The nice thing about GNU Radio is that you can test
your modulator in software only by replacing your USRP sink by your
receiver flow graph, usually adding a throttle[2!] to limit the CPU
usage. Have you tried looking at the spectrum of the signal you
generated, e.g. with the QT GUI waterfall sink [3]? There is BER probes,
so you can test and compare different implementations of your receiver.

I think this is a good point to drop you off to your own
experimentation, and study of the effects coming up. Have fun!

Greetings,
Marcus

[1] You can configure the device to just send 8 bit samples, but that
will limit the SNR because it introduces quantization noise, and is
usually the opposite of what you want to do in a bad-SNR situation
[2] you never use throttle in a flowgraph with hardware, because the
hardware will be there to limit your sample flow. I only mention this
because we see this mistake so often.
[3] Remember to set the Generate Option in the Options Block to QT, if
you use QT sinks.

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

[Discuss-gnuradio] Why SWIG has been selected as C++ wrapper for Python for GNURadio ?

[Joe D]

Hi All

This is a question intended  for the Software designers and maintainers of
the GNURadio

Is there a specific reason / advantage of using SWIG as a C++ wrapper over
using other avaialble  wrappers  for C++ as Boost.Python , Cython etc 
in the context of GNURadio ?

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

Re: [Discuss-gnuradio] Why SWIG has been selected as C++ wrapper for Python for GNURadio ?

[Martin Braun]

On 06/20/2014 10:34 AM, Joe D wrote:
> This is a question intended  for the Software designers and maintainers
> of the GNURadio
> 
> Is there a specific reason / advantage of using SWIG as a C++ wrapper
> over  using other avaialble  wrappers  for C++ as Boost.Python , Cython
> etc  in the context of GNURadio ?

First, you need to realize that the decision to use SWIG was made a long
way back, when there were less alternatives. At the time, one important
argument was that Python wasn't the only scripting language that was to
be supported.
At this point, we know a lot of SWIG's quirks, and there is little
reason to change. It does all we need (although it could do somethings a
bit faster, the build times are still annoying), and it integrates well
with our code structure.
To be honest: Few of us are 100% happy with SWIG, but it's the devil we
know :)

However, while there are alternatives to SWIG worth considering, Cython
is not suitable for what we need. I haven't looked into Boost.Python
closely, though.

M

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

[Discuss-gnuradio] Creating OOT module

[sreena p h]

Hi

I have written a block in python and was trying to create an out of tree module 
as given in the gnuradio tutorial. 
While using cmake ../ the following error occured. 
CMake Error: CMake can not determine linker language for target:gnuradio-dec
CMake Error: Cannot determine link language for target "gnuradio-dec".

this was rectified by removing the lib directory and the cmake file was created 
without error. Then i run the make install and found following error: 

Scanning dependencies of target _dec_swig
[ 46%] Building CXX object 
swig/CMakeFiles/_dec_swig.dir/dec_swigPYTHON_wrap.cxx.o
Linking CXX shared module _dec_swig.so
/usr/bin/ld: cannot find -lgnuradio-dec
collect2: error: ld returned 1 exit status
make[2]: *** [swig/_dec_swig.so] Error 1
make[1]: *** [swig/CMakeFiles/_dec_swig.dir/all] Error 2
make: *** [all] Error 2

what should i do to rectify this linking  error.. 


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

Re: [Discuss-gnuradio] Why SWIG has been selected as C++ wrapper for Python for GNURadio ?

[Marcus Müller]

Hi Joe,

Disclaimer: I haven't been around when SWIG was introduced into GNU
Radio. These are somewhat educated guesses, but since I've had *some*
fun with SWIG, I wondered myself and this is what I rationalized.

- SWIG was around at the time GNU Radio was rewritten, which must have
been around 2004. I think the choice to use SWIG was made before that
[1]. SWIG has been around since '96, so I guess it was expected to be
somewhat stable/reliable. Boost.Python was started in '03, and if the
guys behind it decided that they had to conceptually rework something,
the second year it exists sounds like a dangerous time to use it. ctypes
is (I think) python-2.5esque, so this couldn't have been around back in
the day, and only does basic C wrapping.
- It does what GNU Radio needed: Generate python wrapper classes without
the developers needing to actually write code; defining the interface
was enough for a "normal" block to be SWIG'ed, and specialized wrapper
classes only had to be written for some of the core things so that
things like connect()ing blocks would work. It is arguable if writing
and maintaining the SWIG .i files (especially since we're talking about
the autohell era) was worth the trouble of avoiding that, but for the
only comparable competitor Boost.Python, you had to define wrapper
classes, and references to the classes wrapped and their members.
Pyrex/Cython now is a complete different language and would have made
GNU Radio something much more multi-paradigmatic, whilst adding even
more to the "active" codebase that had to be maintained by hand.
- It was expected that if SWIG wasdone right, GNU Radio could end up
with multiple scripting language interfaces [2]. Nowadays, people are
content to use python, especially since we now (feels like yesterday)
have support to write gr::block classes in python, which of course
needed a lot of gateway work, so (to my knowledge) there haven't been
efforts to make use of more than the C++ and Python SWIG capabilities[3].

Greetings,
Marcus

[1]
http://lists.gnu.org/archive/cgi-bin/namazu.cgi?query=SWIG&submit=Search!&idxname=discuss-gnuradio&max=20&result=normal&sort=date%3Aearly
[2] http://lists.gnu.org/archive/html/discuss-gnuradio/2003-03/msg00135.html
[3] After all, for scripting python works really nice and is easy to
learn. If you wanted to use a fast Matrix operation in Fortran, there is
no stopping you from doing that from C++, which is the programming
language of choice for performance-critical blocks, anyway, as long as
your Fortran and C++ compilers are ABI-compliant. If you wanted
On 20.06.2014 10:34, Joe D wrote:
> Hi All
>
> This is a question intended  for the Software designers and maintainers of
> the GNURadio
>
> Is there a specific reason / advantage of using SWIG as a C++ wrapper over
> using other avaialble  wrappers  for C++ as Boost.Python , Cython etc 
> in the context of GNURadio ?
>
> Thanks!
> Joe
>
>
>
> ___
> 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] Creating OOT module

[Marcus Müller]

Hi Sreena,

1. have you added your block using gr_modtool? otherwise, cmake won't
notice it's there.
2. if you have, what version of GNU Radio are you using? Support for
python-only OOT modules have but recently been added.

Greetings,
Marcus

On 20.06.2014 11:41, sreena p h wrote:
> Hi
>
> I have written a block in python and was trying to create an out of tree 
> module as given in the gnuradio tutorial. 
> While using cmake ../ the following error occured. 
> CMake Error: CMake can not determine linker language for target:gnuradio-dec
> CMake Error: Cannot determine link language for target "gnuradio-dec".
>
> this was rectified by removing the lib directory and the cmake file was 
> created without error. Then i run the make install and found following error: 
>
> Scanning dependencies of target _dec_swig
> [ 46%] Building CXX object 
> swig/CMakeFiles/_dec_swig.dir/dec_swigPYTHON_wrap.cxx.o
> Linking CXX shared module _dec_swig.so
> /usr/bin/ld: cannot find -lgnuradio-dec
> collect2: error: ld returned 1 exit status
> make[2]: *** [swig/_dec_swig.so] Error 1
> make[1]: *** [swig/CMakeFiles/_dec_swig.dir/all] Error 2
> make: *** [all] Error 2
>
> what should i do to rectify this linking  error.. 
>
>
> 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] usrp e110 in standalone mode ?

[Mike Jameson]

I use the Linux program called 'screen' to manage remote Linux instances
and the same tool is great for running non graphical flow graphs too.  If
you start a program from within a 'screen' session then it will continue to
run if you close your Terminal window:

1) use 'ssh username@192.168.10.x' to remotely log into the e110 box from
another computer.
2) run 'screen -RD' which will detatch any running screen sessions (there
won't be any the first time you do it however running the same command
every time you use it saves confusion) and reattach them to your console.
3) run your command such as './go_go_go.py'
4) press 'ctrl-a d' to detatch the session or just close your Terminal
window with the knowledge that the program will still be running.

Google for the 'screen man page' for instructions on creating more than one
session at a time such as with the use of 'ctrl-a c' to create a new
session and switch to the next one with 'ctrl-a n'.

To log back into the box again after closing the Terminal window on your
remote computer, just ssh back in and run 'screen -RD', voilà!

Mike

--
Mike Jameson M0MIK BSc MIET
Ettus Research Technical Support
Email: supp...@ettus.com
Web: http://ettus.com


On Fri, Jun 20, 2014 at 9:01 AM, Wafa Elhajhmida  wrote:

> Hi,
>
> I made an application on usrp e110 to send datas.
>
> I would like to make it operate in a standalone mode.
>
> Have you any suggestions to deal with this issue ?
>
> Thanks for help.
>
> Best regards,
>
> Wafa HAJ HMIDA
>
> ___
> 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] Problem with firdes segfault

[Bill Dailey]

I had gnuradio working on my ubuntu system and was hoping I wouldnt have to
clutter with something like this.  I have reinstalled a couple of times and
am geting this odd error.

when I run my test block I get this:
Executing: "/home/willy/top_block.py"

Traceback (most recent call last):
  File "/home/willy/top_block.py", line 13, in 
from gnuradio.filter import firdes
  File
"/usr/local/lib/python2.7/dist-packages/gnuradio/filter/__init__.py", line
32, in 
from filter_swig import *
  File
"/usr/local/lib/python2.7/dist-packages/gnuradio/filter/filter_swig.py",
line 28, in 
_filter_swig = swig_import_helper()
  File
"/usr/local/lib/python2.7/dist-packages/gnuradio/filter/filter_swig.py",
line 24, in swig_import_helper
_mod = imp.load_module('_filter_swig', fp, pathname, description)
ImportError: /usr/local/lib/libgnuradio-filter-3.7.4git.so.0.0.0: undefined
symbol: volk_malloc

SO I go to a python prompt:

>>> from gnuradio.filter import firdes
Segmentation fault (core dumped)


I have never see this before.

I had a working install before installing qt5 and qt creator... this seemed
to have broken something.  I havent gone back and completely undone that
but I will this evening if someone doesnt save me.

Hardware is netsdr but it doesnt look like it gets near the hardware.
-- 
Doc

Bill Dailey
KXØO
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Difficulty with File Meta Source block

[dushyant.marathe]

Hi all,

I want to use "File Meta source" & "File Meta sink" block from Gnu Radio.

My flow graph configuration is as follows : signal source (sine wave) ->
throttle -> Meta file sink (Output.out)
   
Using above configuration I am able to write meta file (Output.out) with
header information. 
But I want to see / separate the header information & data from this file
(Output.out). I am not able to do so.

To do this, I tried to use "File Meta source" block but I am finding
difficult to understand it.

Please help me out with "File Meta source" block & how to separate the
header & data from meta file ?

My objective is to separate out header and data/samples from .wav file.

Thanks & Regards,
Dushyant



--
View this message in context: 
http://gnuradio.4.n7.nabble.com/Difficulty-with-File-Meta-Source-block-tp49025.html
Sent from the GnuRadio mailing list archive at Nabble.com.

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

Re: [Discuss-gnuradio] Difficulty with File Meta Source block

[Tom Rondeau]

On Fri, Jun 20, 2014 at 9:22 AM, dushyant.marathe  wrote:

> Hi all,
>
> I want to use "File Meta source" & "File Meta sink" block from Gnu Radio.
>
> My flow graph configuration is as follows : signal source (sine wave) ->
> throttle -> Meta file sink (Output.out)
>
> Using above configuration I am able to write meta file (Output.out) with
> header information.
> But I want to see / separate the header information & data from this file
> (Output.out). I am not able to do so.
>
> To do this, I tried to use "File Meta source" block but I am finding
> difficult to understand it.
>
> Please help me out with "File Meta source" block & how to separate the
> header & data from meta file ?
>
> My objective is to separate out header and data/samples from .wav file.
>
> Thanks & Regards,
> Dushyant
>

Have you looked at the manual page describing the metadata file structure?

http://gnuradio.org/doc/doxygen/page_metadata.html

It shows you how to use a tool that comes with GNU Radio that reads the
header information out.

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

Re: [Discuss-gnuradio] Problem with firdes segfault

[Tom Rondeau]

On Fri, Jun 20, 2014 at 7:59 AM, Bill Dailey  wrote:

>
> I had gnuradio working on my ubuntu system and was hoping I wouldnt have
> to clutter with something like this.  I have reinstalled a couple of times
> and am geting this odd error.
>
> when I run my test block I get this:
> Executing: "/home/willy/top_block.py"
>
> Traceback (most recent call last):
>   File "/home/willy/top_block.py", line 13, in 
> from gnuradio.filter import firdes
>   File
> "/usr/local/lib/python2.7/dist-packages/gnuradio/filter/__init__.py", line
> 32, in 
> from filter_swig import *
>   File
> "/usr/local/lib/python2.7/dist-packages/gnuradio/filter/filter_swig.py",
> line 28, in 
> _filter_swig = swig_import_helper()
>   File
> "/usr/local/lib/python2.7/dist-packages/gnuradio/filter/filter_swig.py",
> line 24, in swig_import_helper
> _mod = imp.load_module('_filter_swig', fp, pathname, description)
> ImportError: /usr/local/lib/libgnuradio-filter-3.7.4git.so.0.0.0:
> undefined symbol: volk_malloc
>
> SO I go to a python prompt:
>
> >>> from gnuradio.filter import firdes
> Segmentation fault (core dumped)
>
>
> I have never see this before.
>
> I had a working install before installing qt5 and qt creator... this
> seemed to have broken something.  I havent gone back and completely undone
> that but I will this evening if someone doesnt save me.
>
> Hardware is netsdr but it doesnt look like it gets near the hardware.
> --
> Doc
>
> Bill Dailey
> KXØO
>


volk_malloc was introduced in 3.7.3 and is now relied upon by many GNU
Radio blocks and functions. What you're seeing here suggests that you have
multiple versions of GNU Radio installed and are linking against the wrong
version somewhere. Make sure you only have one version of the library
installed. Probably just clean up any installed libraries, header files,
and Python files and re-install. Using apt-get install gnuradio will get
you a working version.

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

Re: [Discuss-gnuradio] Why SWIG has been selected as C++ wrapper for Python for GNURadio ?

[Tom Rondeau]

On Fri, Jun 20, 2014 at 5:42 AM, Marcus Müller 
wrote:

>  Hi Joe,
>
> Disclaimer: I haven't been around when SWIG was introduced into GNU Radio.
> These are somewhat educated guesses, but since I've had *some* fun with
> SWIG, I wondered myself and this is what I rationalized.
>
> - SWIG was around at the time GNU Radio was rewritten, which must have
> been around 2004. I think the choice to use SWIG was made before that [1].
> SWIG has been around since '96, so I guess it was expected to be somewhat
> stable/reliable. Boost.Python was started in '03, and if the guys behind it
> decided that they had to conceptually rework something, the second year it
> exists sounds like a dangerous time to use it. ctypes is (I think)
> python-2.5esque, so this couldn't have been around back in the day, and
> only does basic C wrapping.
> - It does what GNU Radio needed: Generate python wrapper classes without
> the developers needing to actually write code; defining the interface was
> enough for a "normal" block to be SWIG'ed, and specialized wrapper classes
> only had to be written for some of the core things so that things like
> connect()ing blocks would work. It is arguable if writing and maintaining
> the SWIG .i files (especially since we're talking about the autohell era)
> was worth the trouble of avoiding that, but for the only comparable
> competitor Boost.Python, you had to define wrapper classes, and references
> to the classes wrapped and their members. Pyrex/Cython now is a complete
> different language and would have made GNU Radio something much more
> multi-paradigmatic, whilst adding even more to the "active" codebase that
> had to be maintained by hand.
> - It was expected that if SWIG wasdone right, GNU Radio could end up with
> multiple scripting language interfaces [2]. Nowadays, people are content to
> use python, especially since we now (feels like yesterday) have support to
> write gr::block classes in python, which of course needed a lot of gateway
> work, so (to my knowledge) there haven't been efforts to make use of more
> than the C++ and Python SWIG capabilities[3].
>
> Greetings,
> Marcus
>
> [1]
> http://lists.gnu.org/archive/cgi-bin/namazu.cgi?query=SWIG&submit=Search!&idxname=discuss-gnuradio&max=20&result=normal&sort=date%3Aearly
> [2]
> http://lists.gnu.org/archive/html/discuss-gnuradio/2003-03/msg00135.html
> [3] After all, for scripting python works really nice and is easy to
> learn. If you wanted to use a fast Matrix operation in Fortran, there is no
> stopping you from doing that from C++, which is the programming language of
> choice for performance-critical blocks, anyway, as long as your Fortran and
> C++ compilers are ABI-compliant. If you wanted
> On 20.06.2014 10:34, Joe D wrote:
>
> Hi All
>
> This is a question intended  for the Software designers and maintainers of
> the GNURadio
>
> Is there a specific reason / advantage of using SWIG as a C++ wrapper over
> using other avaialble  wrappers  for C++ as Boost.Python , Cython etc 
> in the context of GNURadio ?
>
> Thanks!
> Joe
>
>
Martin and Marcus nicely answered the question for you.

Just wanted to say that while we're not entirely impressed with some
features of SWIG, the fact that it's working well for us and the disruption
we would cause switching it out is not worth it. We'd have to make sure
that the changes would result in a perfect 1-to-1 match with what we're
exporting using swig.

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

Re: [Discuss-gnuradio] Why SWIG has been selected as C++ wrapper for Python for GNURadio ?

[Marcus Leech]

I find that it's relatively-common for people to criticize existing codebases because they don't use library , or aren't written in , or don't use .  The nice thing about computer-sciencey things is that there's *always* a multitude of pathways to achieve any given goal.  The fact that some group of people would
choose a pathway different than the pathway *you* would choose doesn't make those choices *wrong*, just *different*.
 
That's not to say that certain pathways aren't *inherently* wrong.  For example, if Gnu Radio had chosen to code the signal-processing blocks in Python, rather than just the "control plane"
  layer, it would have caused most people, I think, to question the sanity of such a choice.
 
Just my two cents from 35 years in this racket
 
 

on Jun 20, 2014, Tom Rondeau  wrote:



On Fri, Jun 20, 2014 at 5:42 AM, Marcus Müller  wrote:

Hi Joe,  Disclaimer: I haven't been around when SWIG was introduced into GNU Radio. These are somewhat educated guesses, but since I've had *some* fun with SWIG, I wondered myself and this is what I rationalized.  - SWIG was around at the time GNU Radio was rewritten, which must have been around 2004. I think the choice to use SWIG was made before that [1]. SWIG has been around since '96, so I guess it was expected to be somewhat stable/reliable. Boost.Python was started in '03, and if the guys behind it decided that they had to conceptually rework something, the second year it exists sounds like a dangerous time to use it. ctypes is (I think) python-2.5esque, so this couldn't have been around back in the day, and only does basic C wrapping. - It does what GNU Radio needed: Generate python wrapper classes without the developers needing to actually write code; defining the interface was enough for a "normal" block to be SWIG'ed, and specialized wrapper classes only had to be written for some of the core things so that things like connect()ing blocks would work. It is arguable if writing and maintaining the SWIG .i files (especially since we're talking about the autohell era) was worth the trouble of avoiding that, but for the only comparable competitor Boost.Python, you had to define wrapper classes, and references to the classes wrapped and their members. Pyrex/Cython now is a complete different language and would have made GNU Radio something much more multi-paradigmatic, whilst adding even more to the "active" codebase that had to be maintained by hand.  - It was expected that if SWIG wasdone right, GNU Radio could end up with multiple scripting language interfaces [2]. Nowadays, people are content to use python, especially since we now (feels like yesterday) have support to write gr::block classes in python, which of course needed a lot of gateway work, so (to my knowledge) there haven't been efforts to make use of more than the C++ and Python SWIG capabilities[3].  Greetings, Marcus  [1] http://lists.gnu.org/archive/cgi-bin/namazu.cgi?query=SWIG&submit=Search!&idxname=discuss-gnuradio&max=20&result=normal&sort=date%3Aearly [2] http://lists.gnu.org/archive/html/discuss-gnuradio/2003-03/msg00135.html [3] After all, for scripting python works really nice and is easy to learn. If you wanted to use a fast Matrix operation in Fortran, there is no stopping you from doing that from C++, which is the programming language of choice for performance-critical blocks, anyway, as long as your Fortran and C++ compilers are ABI-compliant. If you wanted 


On 20.06.2014 10:34, Joe D wrote:





Hi All

This is a question intended  for the Software designers and maintainers of
the GNURadio

Is there a specific reason / advantage of using SWIG as a C++ wrapper over
using other avaialble  wrappers  for C++ as Boost.Python , Cython etc 
in the context of GNURadio ?

Thanks!
Joe





 
Martin and Marcus nicely answered the question for you.
 
Just wanted to say that while we're not entirely impressed with some features of SWIG, the fact that it's working well for us and the disruption we would cause switching it out is not worth it. We'd have to make sure that the changes would result in a perfect 1-to-1 match with what we're exporting using swig.
 
Tom
 



___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] gnuradio + itpp error

[Alex Weihkopf]

Hello,

 

I am trying to use the ieee802.11 module by ccs labs (https://github.com/bastibl/gr-ieee802-11). I followed the installation instructions for itpp, but my flowgraph still fails.

 

The error message: 

 

Traceback (most recent call last):
  File "/home/***/Desktop/top_block.py", line 15, in 
    import ieee802_11
  File "/usr/local/lib/python2.7/dist-packages/ieee802_11/__init__.py", line 37, in 
    from ieee802_11_swig import *
  File "/usr/local/lib/python2.7/dist-packages/ieee802_11/ieee802_11_swig.py", line 26, in 
    _ieee802_11_swig = swig_import_helper()
  File "/usr/local/lib/python2.7/dist-packages/ieee802_11/ieee802_11_swig.py", line 22, in swig_import_helper
    _mod = imp.load_module('_ieee802_11_swig', fp, pathname, description)
ImportError: /usr/local/lib/libgnuradio-ieee802_11.so: undefined symbol: _ZN4itpp9ModulatorISt7complexIdEEC1Ev

 

In the last line Ican see that the problem is itpp, but I'm sure it's installed correctly (my flowgraph works on another computer where I followed the exact same instructions).

 

I am using Ubuntu 12.04 and Gnuradio 3.7.4.

 

Can anybody help me with an idea what to do?

 

Regards,

Alex

 


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

Re: [Discuss-gnuradio] Why SWIG has been selected as C++ wrapper for Python for GNURadio ?

[Johnathan Corgan]

On 06/20/2014 02:42 AM, Marcus Müller wrote:

> - It was expected that if SWIG wasdone right, GNU Radio could end up
> with multiple scripting language interfaces [2]. Nowadays, people are
> content to use python, especially since we now (feels like yesterday)
> have support to write gr::block classes in python, which of course
> needed a lot of gateway work, so (to my knowledge) there haven't been
> efforts to make use of more than the C++ and Python SWIG capabilities[3].

There was work done at one point that actually made it into the tree to
output Scheme wrappers for GNU Radio.  This was good, in that it forced
us to distinguish Python specific SWIG constructs vs. the generic SWIG code.

Ultimately, the original author of the Scheme wrappers was not around to
maintain it, and the feature was removed after some time.

I've heard anecdotally that someone got C# wrappers working, but I've
never seen it.

I personally have some interest in wrapping GNU Radio for golang, and
have been looking at what size effort that is, but it has been a pretty
low priority.

(agree with Tom's, Marcus', and Martin's replies on everything else.)

-- 
Johnathan Corgan, Corgan Labs
SDR Training and Development Services
http://corganlabs.com
<>

signature.asc
Description: OpenPGP digital signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] GPN '14 Karlsruhe

[Martin Braun]

Are there any SDR hackers at GPN '14 in Karlsruhe, Germany?

I'll be hanging around with a USRP hacking some GNU Radio; I'd be
interested to meet fellow SDR hackers.

Also, we'll be talking aobut the results of the IEEE Signal Intelligence
Challenge tomorrow afternoon (16:00 in ZKM Vortragssaal), if anyone
wants to come around and see what was going on.

Cheers,
Martin

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

[Discuss-gnuradio] QT Sink center frequency not working

[Nowlan, Sean]

Setting the center frequency in the QT Sink doesn't seem to work. It stays 
centered at 0 Hz. Center frequency seems to work fine with regular QT Frequency 
Sink. GNU Radio version is v3.7.4git-332-g34ee3b7d. I attached a GRC file.

Sean
?


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

Re: [Discuss-gnuradio] gnuradio + itpp error

[Bastian Bloessl]

Hello Alex,

On 20 Jun 2014, at 16:59, Alex Weihkopf  wrote:

> The error message: 
>  
> Traceback (most recent call last):
>   File "/home/***/Desktop/top_block.py", line 15, in 
> import ieee802_11
>   File "/usr/local/lib/python2.7/dist-packages/ieee802_11/__init__.py", line 
> 37, in 
> from ieee802_11_swig import *
>   File 
> "/usr/local/lib/python2.7/dist-packages/ieee802_11/ieee802_11_swig.py", line 
> 26, in 
> _ieee802_11_swig = swig_import_helper()
>   File 
> "/usr/local/lib/python2.7/dist-packages/ieee802_11/ieee802_11_swig.py", line 
> 22, in swig_import_helper
> _mod = imp.load_module('_ieee802_11_swig', fp, pathname, description)
> ImportError: /usr/local/lib/libgnuradio-ieee802_11.so: undefined symbol: 
> _ZN4itpp9ModulatorISt7complexIdEEC1Ev
>  


maybe check the output of

ldd  /usr/local/lib/libgnuradio-ieee802_11.so

and assert that libtipp.so is in LD_LIBRARY_PATH.

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