Dear all,
I am trying to implement a QAM in 56303EVM. I have a weird problem that confuses
me.
For creating the necessary sine and cosine signals I am using a 16 valued lookup
table. When I sent lookup values to the codec (without modulation)
I get a nice, smooth sinus/cosinus signals. So my codec is working okey.
However when I start modulating the input signal according to constellation
diagram,
my cosinus signal loses its smoothness, nearly doesn`t look like a sinusoid
anymore
Interestingly the sinus portion has no problem,
I would most appreciate if you advice on the subject,
I attach important parts of the code below
org x:$10 ; sinus lookup table
dc 0.000000
dc 0.382700/2
dc 0.707000/2
dc 0.923900/2
dc 0.999999/2
dc 0.923900/2
dc 0.707000/2
dc 0.382700/2
dc 0.000000
dc -0.38270/2
dc -0.70700/2
dc -0.92390/2
dc -0.99999/2
dc -0.92390/2
dc -0.70700/2
dc -0.38270/2
org x:$30 ; //Imaginary part - Constellation diagram
dc -0.5
dc 0.5
dc -0.5
dc 0.5
org x:$60 ; // Real Part - Constellation diagram
dc -0.5
dc -0.5
dc 0.5
dc 0.5
org x:$80 ; cosinus lookup table
dc 0.999999/2
dc 0.923900/2
dc 0.707000/2
dc 0.382700/2
dc 0.000000
dc -0.38270/2
dc -0.70700/2
dc -0.92390/2
dc -0.99999/2
dc -0.92390/2
dc -0.70700/2
dc -0.38270/2
dc 0.000000
dc 0.382700/2
dc 0.707000/2
dc 0.923900/2
;setting up modular buffers
move #$0030,r2 ; pointer to modular buffer
move #$003,m2 ;...and is 4 deep
move #$0060,r3 ; pointer to modular buffer
move #$0003,m3 ;...and is 4 deep
move #$0010,r4 ; pointer to modular buffer
move #$000F,m4 ;...and is 16 deep
move #$0080,r5 ; pointer to modular buffer
move #$000F,m5 ;...and is 16 deep
; // each symbol is multiplied by 1 period of sine and then next
; // symbol is taken
loop_1 nop
nop
do #16,end ;// 16 times since lookup table has 16 values
nop
jset #2,x:M_SSISR0,* ; Wait for frame sync to pass.
jclr #2,x:M_SSISR0,* ; Wait for frame sync.
move x:RX_BUFF_BASE,a ; not used actually
move x:RX_BUFF_BASE+1,b
nop
clr a
clr b
move x:(r2),x0 ; get the symbol
move x:(r3),x1
nop
move x:(r4)+,y0 ;start getting lookup table values
move x:(r5)+,y1
nop
mpy x0,y0,a
mpy x1,y1,b
end
nop
move x:(r2)+,x0 ; start for the next symbol
move x:(r3)+,x1
jmp loop_1 ; Loop back
; I am sorry it has been a long post, hope you can help
; rifo :)
56303EVM cosine lookup table output problem
Started by ●April 27, 2007
Reply by ●May 16, 20072007-05-16
Okey I figured out the problem,
Since the cosine starts with a 0.9999 in its lookup table, there happens a sudden jump from 0.999 to -0.999 if the bit stream is such that the first constellation point is a 1 and the second one is -1
Since this sudden jump includes very high freqs, the scope can`t seem to get a hold on it and distorts the waveform :/
My question then would be, is there a way to overcome this problem?
I thought about starting the look up table with a smaller value than 0.999
this way, the jump wouldnt be so great (but still there would be)
however if I do this then I have to change the sequence of the sinus lookup table to since otherwise their orthoganility would be lost.
any help would be appreciated.
thanks alot
rifat
Since the cosine starts with a 0.9999 in its lookup table, there happens a sudden jump from 0.999 to -0.999 if the bit stream is such that the first constellation point is a 1 and the second one is -1
Since this sudden jump includes very high freqs, the scope can`t seem to get a hold on it and distorts the waveform :/
My question then would be, is there a way to overcome this problem?
I thought about starting the look up table with a smaller value than 0.999
this way, the jump wouldnt be so great (but still there would be)
however if I do this then I have to change the sequence of the sinus lookup table to since otherwise their orthoganility would be lost.
any help would be appreciated.
thanks alot
rifat
Reply by ●May 17, 20072007-05-17
r...@yahoo.de wrote:
> Okey I figured out the problem,
>
> Since the cosine starts with a 0.9999 in its lookup table, there happens
> a sudden jump from 0.999 to -0.999 if the bit stream is such that the
> first constellation point is a 1 and the second one is -1
Maybe I'm out of scope here 'cause I seem to have missed some previous
discussion... but sin/cos lookup tables should have no discontinuities
for their nature. I.e., if you table a complete 360 degrees span, the
first and last values of the table should be almost equal.
Furthermore, it is a waste of memory to use both a sine and cosine
lookup table! It is best (for example) to use only a sine LUT and add 90
degrees to the angle (with the proper rollover) if you need a cosine value.
Hope this helps,
-- Carlo Concari.
> Okey I figured out the problem,
>
> Since the cosine starts with a 0.9999 in its lookup table, there happens
> a sudden jump from 0.999 to -0.999 if the bit stream is such that the
> first constellation point is a 1 and the second one is -1
Maybe I'm out of scope here 'cause I seem to have missed some previous
discussion... but sin/cos lookup tables should have no discontinuities
for their nature. I.e., if you table a complete 360 degrees span, the
first and last values of the table should be almost equal.
Furthermore, it is a waste of memory to use both a sine and cosine
lookup table! It is best (for example) to use only a sine LUT and add 90
degrees to the angle (with the proper rollover) if you need a cosine value.
Hope this helps,
-- Carlo Concari.
Reply by ●May 18, 20072007-05-18
Hello Carlo
Thank you for your response,
In my case, I am trying to implement a quadrature modulator on a 56303EVM
basically according to the incoming input stream to be tranmitted, I multiply a sine or a cosine with a certain constant. (e.g 1 or -1) and transmit for 1 period.
so if such is the case that a 1 followed by a -1 is to be transmitted then a discontinuity arises for the cosine. In my lookup table cosine starts with 0.999 and as you have also said finishes with some value very close to 0.999 so when I multiply my cosine with -1 (for the second symbol to be transmitted) then there happens a jump from 0.999 to -0.999 (-1 x 0.99)
there should be a way to overcome this issue but I simply cant find one yet :/
looking forward to hearing from you
rifat
r...@yahoo.de wrote:
>
>> Okey I figured out the problem,
>>
>> Since the cosine starts with a 0.9999 in its lookup table, there happens
>> a sudden jump from 0.999 to -0.999 if the bit stream is such that the
>> first constellation point is a 1 and the second one is -1
>
>Maybe I'm out of scope here 'cause I seem to have missed some previous
>discussion... but sin/cos lookup tables should have no discontinuities
>for their nature. I.e., if you table a complete 360 degrees span, the
>first and last values of the table should be almost equal.
>
>Furthermore, it is a waste of memory to use both a sine and cosine
>lookup table! It is best (for example) to use only a sine LUT and add 90
>degrees to the angle (with the proper rollover) if you need a cosine value.
>
>Hope this helps,
>-- Carlo Concari.
Thank you for your response,
In my case, I am trying to implement a quadrature modulator on a 56303EVM
basically according to the incoming input stream to be tranmitted, I multiply a sine or a cosine with a certain constant. (e.g 1 or -1) and transmit for 1 period.
so if such is the case that a 1 followed by a -1 is to be transmitted then a discontinuity arises for the cosine. In my lookup table cosine starts with 0.999 and as you have also said finishes with some value very close to 0.999 so when I multiply my cosine with -1 (for the second symbol to be transmitted) then there happens a jump from 0.999 to -0.999 (-1 x 0.99)
there should be a way to overcome this issue but I simply cant find one yet :/
looking forward to hearing from you
rifat
r...@yahoo.de wrote:
>
>> Okey I figured out the problem,
>>
>> Since the cosine starts with a 0.9999 in its lookup table, there happens
>> a sudden jump from 0.999 to -0.999 if the bit stream is such that the
>> first constellation point is a 1 and the second one is -1
>
>Maybe I'm out of scope here 'cause I seem to have missed some previous
>discussion... but sin/cos lookup tables should have no discontinuities
>for their nature. I.e., if you table a complete 360 degrees span, the
>first and last values of the table should be almost equal.
>
>Furthermore, it is a waste of memory to use both a sine and cosine
>lookup table! It is best (for example) to use only a sine LUT and add 90
>degrees to the angle (with the proper rollover) if you need a cosine value.
>
>Hope this helps,
>-- Carlo Concari.
Reply by ●May 21, 20072007-05-21
r...@yahoo.de wrote:
> In my case, I am trying to implement a quadrature modulator on a 56303EVM
> basically according to the incoming input stream to be tranmitted, I
> multiply a sine or a cosine with a certain constant. (e.g 1 or -1) and
> transmit for 1 period.
Discontinuities are intrinsic in quadrature modulation: everytime a bit
changes while the carrier value peaks you have a strong discontinuity.
If I understand right: the incoming bit stream rate is the same as the
period of the carrier sinusoid. In this case you can mitigate the
magnitude of the discontinuity by starting the sin/cos table at 45; by
doing so, everytime a bit changes both carriers will always have a
discontinuity of sqrt(2). (cos 45 = sin 45 = sqrt(2)/2).
I can see no better way because as I said discontinuities are intrinsic
in QAM.
Best regards,
Carlo Concari.
> In my case, I am trying to implement a quadrature modulator on a 56303EVM
> basically according to the incoming input stream to be tranmitted, I
> multiply a sine or a cosine with a certain constant. (e.g 1 or -1) and
> transmit for 1 period.
Discontinuities are intrinsic in quadrature modulation: everytime a bit
changes while the carrier value peaks you have a strong discontinuity.
If I understand right: the incoming bit stream rate is the same as the
period of the carrier sinusoid. In this case you can mitigate the
magnitude of the discontinuity by starting the sin/cos table at 45; by
doing so, everytime a bit changes both carriers will always have a
discontinuity of sqrt(2). (cos 45 = sin 45 = sqrt(2)/2).
I can see no better way because as I said discontinuities are intrinsic
in QAM.
Best regards,
Carlo Concari.