sorry for a late reply

i asked wether you were working in matlab /simulink software

anyways  the thing is that you need only the MSB or say 31 30 bits ,,,there
can be different approaches like

1  you data is serial ,, convert it to parallel data take your required 32
31 st  bit,,,, convert it back to serial data (the two bits only) and thats
it !!!!!!! 

or if you have a slicing function available in your software you can use it
,,actually its the same thing ..

by the ways you can use SHARC dsp with matlab 

if this thing helps or not ,,, tell me

Thank you Jerry.

What I meant was the constellation value as the integer part. The rest is
the noise. So in the fixed-point converted result, a certain number of
MSB's contain the constellation value, like 1,3,5 and the rest of the bits
are the noise part.

Somehow a scaling is done so that the constellation value ends up at the
MSB's when fixed-point converted.

Cheers.

On 6/10/2010 9:25 PM, m26k9 wrote:
> Thank you very much John, Jerry and Avier.
>
> The floating to fixed point conversion in the SHARC dsp I am using converts
> the floating point to an "two's complement fixed-point integer".
>
> Somehow a scaling is performed such the the integer part of the
> constellation ends up at the MSB's of the fixed-point converted result.
> Which is what I am quite confused about.
>
> Thank you again.

The integer part? What other part is there?

Jerry
-- 
Engineering is the art of making what you want from things you can get.
�����������������������������������������������������������������������

Thank you very much John, Jerry and Avier.

The floating to fixed point conversion in the SHARC dsp I am using converts
the floating point to an "two's complement fixed-point integer".

Somehow a scaling is performed such the the integer part of the
constellation ends up at the MSB's of the fixed-point converted result.
Which is what I am quite confused about.

Thank you again.

i f you are working in matlab envornment,,,,,,,then i can help

On 6/8/2010 5:59 AM, John wrote:


> First of all, a fixed point number is not necessarily an integer. It
> is, as the name implies, a number with a fixed decimal point and
> constant resolution, as opposed to floating point. Fixed point numbers
> are often specified using "Q" notation as discussed here:
>
> http://en.wikipedia.org/wiki/Q_%28number_format%29
>
> Conversion from float to fixed does not result in an integer. You
> might consider whether a Q3.12 format is useful in your situation.

Also see http://en.wikipedia.org/wiki/Fixed-point_arithmetic and Randy 
Yates' excellent treatment www.digitalsignallabs.com/fp.pdf

Jerry
-- 
Engineering is the art of making what you want from things you can get.
�����������������������������������������������������������������������

On Jun 8, 1:50&#4294967295;am, "m26k9" <maduranga.liyanage@n_o_s_p_a_m.gmail.com>
wrote:
> Hello,
>
> I had a thread earlier about floating-point to fixed-point conversion for a
> confusion I had with the QAM demodulator code I have (SHARC dsp). This is
> my first time working with an demodulator assembly and it has really thrown
> me off. I am trying to figure out how the slicing is performed. If anybody
> could give any hint that would be great.
>
> 1) What I am confused is, how floating-point to fixed-point conversion can
> perform the slicing, because, for example, in QAM, the point 3, can be
> received 2.4. Conversion to fixed-point puts it at 2, which is not a valid
> QAM point?
>
> 2) And it is mentioned that this floating-point to fixed-point conversion
> will put the MSB of the constellation at bit 31 to due proper scaling.
>
> The constellation gains are applied to the fft output before the slicing.
> So my guess is that the floating point value will be something +/- 1.xxx,
> 3.xxx, 5xxx, etc. Where the .xxx are fractional points coming from noise.
> The noise will very well take them over the boundaries to 2.xxx, 4.xxx
> too.
>
> My understanding is that the conversion to fixed-point will give an integer
> result, +/- 1,2,3,4,etc. Accounting for errors that puts the point over the
> QAM boundary.
>
> Could anybody give any advice as to where I am getting this wrong. Because
> clearly, this is not how it is implemented.
>
> Thank you.

First of all, a fixed point number is not necessarily an integer. It
is, as the name implies, a number with a fixed decimal point and
constant resolution, as opposed to floating point. Fixed point numbers
are often specified using "Q" notation as discussed here:

http://en.wikipedia.org/wiki/Q_%28number_format%29

Conversion from float to fixed does not result in an integer. You
might consider whether a Q3.12 format is useful in your situation.

John

Hello,

I had a thread earlier about floating-point to fixed-point conversion for a
confusion I had with the QAM demodulator code I have (SHARC dsp). This is
my first time working with an demodulator assembly and it has really thrown
me off. I am trying to figure out how the slicing is performed. If anybody
could give any hint that would be great.

1) What I am confused is, how floating-point to fixed-point conversion can
perform the slicing, because, for example, in QAM, the point 3, can be
received 2.4. Conversion to fixed-point puts it at 2, which is not a valid
QAM point?
  
2) And it is mentioned that this floating-point to fixed-point conversion
will put the MSB of the constellation at bit 31 to due proper scaling.

The constellation gains are applied to the fft output before the slicing.
So my guess is that the floating point value will be something +/- 1.xxx,
3.xxx, 5xxx, etc. Where the .xxx are fractional points coming from noise.
The noise will very well take them over the boundaries to 2.xxx, 4.xxx
too.

My understanding is that the conversion to fixed-point will give an integer
result, +/- 1,2,3,4,etc. Accounting for errors that puts the point over the
QAM boundary.

Could anybody give any advice as to where I am getting this wrong. Because
clearly, this is not how it is implemented. 

Thank you.