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 <j...@ettus.com>
To: Almohanad Fayez <alfa...@aol.com>
Cc: discuss-gnuradio <discuss-gnuradio@gnu.org>
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


 
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Reply via email to