[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] Converting complex-short to complex-float with UH

From: Almohanad Fayez
Subject: Re: [Discuss-gnuradio] Converting complex-short to complex-float with UHD
Date: Mon, 12 Sep 2011 13:52:54 -0400 (EDT)

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

-----Original Message-----
From: Josh Blum <address@hidden>
To: Almohanad Fayez <address@hidden>
Cc: discuss-gnuradio <address@hidden>
Sent: Mon, Sep 12, 2011 1:46 pm
Subject: Re: [Discuss-gnuradio] Converting complex-short to complex-float with UHD

On 09/12/2011 10:28 AM, Almohanad Fayez wrote:
> 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

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]