Converting complex-short to complex-float with UHD

GNU Radio
1

I can’t seem to find a direct way of typcasting COMPLEX_INT16 using
gr-uhd as complex_float. It seems that gnuradio assumes that a complex
type is composed of floats by default which causes issues when I’m using
gr-uhd, is there a direct way to do complex_short to complex_float
conversion or should I just make a custom block for that? thanks.

al fayez

2

On 09/12/2011 10:00 AM, Almohanad F. wrote:

I can’t seem to find a direct way of typcasting COMPLEX_INT16 using
gr-uhd as complex_float. It seems that gnuradio assumes that a
complex type is composed of floats by default which causes issues
when I’m using gr-uhd, is there a direct way to do complex_short to
complex_float conversion or should I just make a custom block for
that? thanks.

The output signature for COMPLEX_INT16 is a vector of shorts length 2.
You can covert this to complex float with a vector_to_stream block, and
then a ishort_to_complex block.

BTW, if you want complex floats, it makes way more sense to just use
COMPLEX_FLOAT32. The real use of COMPLEX_INT16 is if you have a block
that produces or consumes complex shorts. Otherwise its just extra
overhead.

-josh

3

I want to use COMPLEX_INT16 in hopes of generating non-normalized fixed
point data using UHD. I ultimately want to send this data over to the
DSP on the E100, if I receive the data as COMPLEX_FLOAT32 then UHD is
performing

fixed-point -> floating point and I will be performing floating-point
-> fixed-point -> floating-point feeding into the FPGA. Ultimately I
want

FPGA ->fixed-point -> DSP -> fixed-point -> FPGA

instead of

FPGA ->fixed-point -> floating-point -> fixed_point -> DSP ->
fixed-point -> floating-point -> fixed-point -> FPGA

however in my flowgraph I want to be able to use gr.probe_avg_mag_sqrd()
and a scalar multiples before feeding into the DSP and it fails when I
use COMPLEX_INT16 because of data type confusion

al fayez

4

On 09/12/2011 10:28 AM, Almohanad F. wrote:

FPGA ->fixed-point -> DSP -> fixed-point -> FPGA

instead of

FPGA ->fixed-point -> floating-point -> fixed_point -> DSP ->
fixed-point -> floating-point -> fixed-point -> FPGA

Ah, makes sense.

however in my flowgraph I want to be able to use
gr.probe_avg_mag_sqrd() and a scalar multiples before feeding into
the DSP and it fails when I use COMPLEX_INT16 because of data type
confusion

It may be better to combine this scalar multiply/conversion with the
copy into DSP memory. You can save a step writing the output of the
conversion directly to DSP memory.

-Josh

5

Thanks Josh, I’ll probably end up doing that, but I’m assuming that
there is no way to do a quick dirty test from COMPLEX_INT16 to
complex-float type and I will need to make a new block that does that
right?

and obviously combine those functions to make things faster and prettier

al fayez