discuss-gnuradio
[Top][All Lists]
Advanced

[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.

-Josh

reply via email to

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