oQPSK mod path

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"?> gr_802_15_4 oQPSK ucla_qpsk_modulator_cc 802_15_4-COSA from gnuradio import ucla ucla.qpsk_modulator_cc() in float out complex 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.

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

Not looking too deeply at the code, i would assume the problem is a
mismatch between the 2 blocks. sig_source_f outputs single floating
point values (4 bytes), while blocks defined with _cc usually output
complex float (8 bytes). Maybe try using sig_source_c instead

On Sun, Jul 24, 2011 at 4:28 PM, Marius [email protected] wrote:

So my XML definition is:
float

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