Re: [Discuss-gnuradio] oQPSK mod path

[Tom Rondeau]

On Sun, Jul 24, 2011 at 4:28 PM, Marius <address@hidden> wrote:
> Hi!
>
> I'm creating a flow-graph that leverages the Wiesel 802.15.4 stack:
> http://wiesel.ece.utah.edu/redmine/projects/gr-ieee802-15-4/wiki.
> Mainly I want a complete GRC flowgraph for TX and RX on 802.15.4.
>
> The C++ is:
> http://wiesel.ece.utah.edu/redmine/projects/gr-ieee802-15-4/repository/revisions/master/entry/src/lib/ucla_qpsk_modulator_cc.cc
> - 4 samples per symbol
>
> So my XML definition is:
> <?xml version="1.0"?>
> <block>
>  <name>gr_802_15_4 oQPSK</name>
>  <key>ucla_qpsk_modulator_cc</key>
>  <category>802_15_4-COSA</category>
>  <import>from gnuradio import ucla</import>
>  <make>ucla.qpsk_modulator_cc()</make>
>
>  <sink>
>    <name>in</name>
>    <type>float</type>
>  </sink>
>  <source>
>    <name>out</name>
>    <type>complex</type>
>  </source>
>  <doc>
> Generate a QPSK signal from a +/- 1 float stream.
> For each two input symbols we output 4 complex symbols with a half-sine
> pulse shape.
>  </doc>
> </block>
>
> The Error each time I use the demod Block in a Flow-Graph is:
>  File 
> "/usr/local/lib/python2.6/dist-packages/gnuradio/gr/gnuradio_core_runtime.py",
> line 1504, in primitive_connect
>    return _gnuradio_core_runtime.gr_top_block_sptr_primitive_connect(self,
> *args)
> ValueError: itemsize mismatch: sig_source_f(3):0 using 4,
> qpsk_modulator_cc(2):0 using 8
>
> While my Flow-Graph is simply Signal-Source -> oQPSK mod -> USRP2.
>
> Could anyone give me some ideas how to solve this issue? I know that I
> need to delay the Q channel and add more Blocks. But this won't help
> on the vector consumption issue afaik.
>
> Best,
> Marius


Hi Marius,
The problem is that the modulator is expecting complex floats (8-bytes
per sample), but you are only connecting a floating point source
(4-bytes per sample). You would want to use sig_source_c, instead, to
produce complex values.

On the other hand, I'm not sure I understand why you are using a
sig_source at all. This will generate a period waveform, mostly a sine
wave. You can have it produce a square wave, which is more appropriate
for digital modulation, but there are still better ways to do this
since you will really want random data going into the modulator. To
debug modulators/demodulators, I tend to generate random bits using
the Python random.randint function (actually, I like scipy's version
better) to create some N number of samples and put that into a vector
source where you can either repeat the data or not.

Tom