56303 | 563xx | 5680 | 56805 | 5680x | 56F80 | 56F800DEMO | 56F805 | 56f807 | 56F830 | ADC | Bootloader | Codec | CodeWarrior | CW5 | CW6 | Debugger | DSP56303 | DSP56303EVM | DSP563xx | DSP5680 | DSP56800 | DSP56807 | DSP56858 | DSP56858EVM | DSP56F803 | DSP56F805 | DSP56F807 | DSP56F80x | DSP56F826 | DSP56F827 | DSP56F8xx | EVM | FFT | Flash_over_jtag | GPIO | Interrupt | Interrupts | JTAG | LCD | Linker | MCF5307 | Metrowerks | Modulus | MSCAN | PCMaster | PWM | Quad | Rif | RTOS | SDK | SPI

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 :)

______________________________
New Year Gift for Members of DSPRelated.com.  Details here.

(You need to be a member of motoroladsp -- send a blank email to motoroladsp-subscribe@yahoogroups.com )

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

______________________________
New Year Gift for Members of DSPRelated.com.  Details here.

(You need to be a member of motoroladsp -- send a blank email to motoroladsp-subscribe@yahoogroups.com )

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.

______________________________
New Year Gift for Members of DSPRelated.com.  Details here.

(You need to be a member of motoroladsp -- send a blank email to motoroladsp-subscribe@yahoogroups.com )

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.

______________________________
New Year Gift for Members of DSPRelated.com.  Details here.

(You need to be a member of motoroladsp -- send a blank email to motoroladsp-subscribe@yahoogroups.com )

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.

______________________________
New Year Gift for Members of DSPRelated.com.  Details here.

(You need to be a member of motoroladsp -- send a blank email to motoroladsp-subscribe@yahoogroups.com )