John,
Did you ever figure out your problem with this? It looks like what you are
doing is ok. The gr_firdes.i file uses the %rename function, so is it
possible you aren't seeing your raised cosine code because you are expecting
it under a different name?
If you do dir(dsss), what do you get?
Tom
On Sun, Jul 3, 2011 at 10:43 PM, John Andrews wrote:
> Here are all the related files.
>
> C++ header
> ***
> * dsss_firdes.h *
> ***
> #ifndef _DSSS_FIRDES_H_
> #define _DSSS_FIRDES_H_
>
> #include
> #include
>
> class dsss_firdes {
> public:
> dsss_firdes();
>
> static std::vector raised_cosine (double gain, double sampling_freq,
> double symbol_rate, double alpha, int ntaps);
> };
>
> #endif
>
>
>
> C++ Source file -
> *
> * dsss_firdes.cc *
> *
>
> #include "dsss_firdes.h"
> #include
>
> using std::vector;
>
> // Raised Cosine Filter
>
> vector
> dsss_firdes::raised_cosine (double gain, double sampling_freq, double
> symbol_rate, double alpha, int ntaps)
> {
>ntaps |= 1; // ensure that ntaps is odd
>
>double spb = sampling_freq/symbol_rate; // samples per bit/symbol
>vector taps(ntaps);
>double scale = 0;
>for(int i=0;i{
>double x1,x2,rc1;
>double xindx = i - ntaps/2;
>x1 = M_PI * xindx/spb;
>x2 = 1-(4*alpha*alpha*(xindx/spb)*(xindx/spb));
>
> if(i == ntaps/2){
> taps[i] = 1;
> continue;
>}
> if(fabs(x2) < 0.01){ // manage rounding errors. treat 0.01 as
> zero
>x2 = 8*alpha*(xindx/spb)*(xindx/spb);
>rc1 = sin(x1)*sin(alpha*x1)/x2;
>}
>else{
>rc1 = (sin(x1)*cos(alpha*x1))/(x1*x2);
>}
> taps[i] = rc1;
> scale += taps[i];
> }
>
> for(int i=0;itaps[i] = taps[i] * gain / scale;
> }
> return taps;
> }
>
>
> SWIG interface
> ** dsss.i **
>
> %include "gnuradio.i"
>
>
> %{
> #include "dsss_firdes.h"
> %}
>
>
> //GR_SWIG_BLOCK_MAGIC(dsss,firdes);
> class dsss_firdes
> {
> public:
> static std::vector raised_cosine(double gain, double sampling_freq,
> double symbol_rate, double alpha, int ntaps);
> };
>
> ***
> * Makefile.am *
> ***
>
> include $(top_srcdir)/Makefile.common
>
> # C/C++ headers get installed in ${prefix}/include/gnuradio
> grinclude_HEADERS = dsss_firdes.h
>
> ###
> # SWIG Python interface and library
>
> TOP_SWIG_IFILES = dsss.i
>
> # Install so that they end up available as:
> # import gnuradio.dsss
> # This ends up at:
> # ${prefix}/lib/python${python_version}/site-packages/gnuradio
> dsss_pythondir_category = gnuradio
>
>
> # additional sources for the SWIG-generated library
> dsss_la_swig_sources = dsss_firdes.cc
>
> include $(top_srcdir)/Makefile.swig
>
> # add some of the variables generated inside the Makefile.swig.gen
> BUILT_SOURCES = $(swig_built_sources)
>
> # Do not distribute the output of SWIG
> no_dist_files = $(swig_built_sources)
>
>
>
>
>
>
>
>
> On Sun, Jul 3, 2011 at 10:33 AM, Tom Rondeau wrote:
>
>> On Sun, Jul 3, 2011 at 3:25 AM, John Andrews wrote:
>>
>>> Hi Tom,
>>>
>>>
>>>
Are you doing this in your own top-level block (dsss from the looks of
it) or under a current GNU Radio directory like gnuradio-core where the
gr_firdes currently is?
>>> Yes, I am doing this in my own top-level directory named 'dsss'
>>> (abbreviation for direct sequence spread spectrum)
>>>
You haven't mentioned adding anything to the Makefile so that it is
built properly. If you are working under gnuradio-core/src/lib/general,
you'll also want to add your .h and .i files to general.i so that it get's
compiled.
>>>
>>> I added the names to Makefile.am like I added the remaining names of
>>> files. The Makefile.am has been adapted from howto-write-a-block. The C++
>>> part gets compiled without any problem but when importing in python it
>>> throws an undefined_variable_dsss_firdes_Z*** type of error, which according
>>> to my previous experience occurs with wrong SWIG interface problem. I am
>>> pretty sure I am having a SWIG related issue here.
>>>
>>
>> Ok, it _sounds_ like you are doing everything correctly. In my experience
>> with this stuff, it usually comes down to a small typo somewhere. You can
>> post your files here (.i, .h, and Makefile) so others to maybe have a look
>> to see if there's anything incorrect in them.
>>
>>
>>> Also, just curious, what application are you interested in that requires
a raised cosine filter? And couldn't you just create a root raised cosine
filter and convolve the the taps against themselves to make the raised
cosine taps?
>>>
>>> I am developing a BPSK based Direct sequence spread spectrum Tx/Rx and
>>> at the transmitter i wanted to use a raised cosine filter when interpolating
>>> from symbol to N samples before sending it to the USRP. I am not sure if
>
