TMDSRSLVR: TMDSRSLVR Exitation generation sw enquiry

Hi Ramesh,

thank you for your answer: I see now how the SINE_CARRIER period is obtained.

I didn't find before any reference to the 240kHz for the sine_carrier (maybe I skipped some documentation, not sure); I will check with this value and have a look at the signals. 

I'll be in touch soon with some results

Thanks,

Marco

The carrier modulator was chosen to be higher frequency than the update rate to get a cleaner looking sinewave carrier. With Piccolo @60MHz clock, 240 KHz carrier's carrier seemed to be the limit. For Delfino, it could be higher, agreed. In hindsight, all this could be simplified to update at the sampling rate. Try it out and see if you see any advantage, one over the other.
Btw, I did not expect to see the kinks in the plots.

Hi,
I have a wrong setting for the period in the sine, I'll try again tomorrow... ( left the 625 I think, I have to recalculate it for the 100MHz clock I have on the 28379D).

You were too fast in answering, I realised later my mistake and changed my comment. I will soon post a video with the proper frequency.

Thanks again.

Hello again,

I am getting very nice sinewaves from the resolver, as you can see in the picture.

However I have a furhter question: how the code knows where to calculate the angle?

Reading the AN it says that it does a decimation of 16, to read just the peaks ("controlSUITE\development_kits\TMDSRSLVR_v1.0\~Docs\resolver_to_digital_conv.pdf", Chap. 2.3.2

I found the

#define   ADC_SAMP_INST           875    /* adc sampling instant set up  */

to specify where the sampling should happen, within the 160kHz period (the default value 875 is too high I think, it should be below 625)

But then, what specifyes wich one of the 16 sampling instants the angle needs to be calculated? The isr routine seems to take longer on the 4th sampling, which is quite far from the actual peak (I have not connected yet the A2D at the momen), will it self adjust with the measure?

Regards

You mention that the 4th ISR routine takes longer, so that is where the decimation is happening right now. You may have to position the decimation instant to match with the peak of the sine / cos feedbacks to get a higher SNR. Vary ADC_SAMP_INSTANT to fit your needs.

Hi Ramesh,

I tried to change that parameter but it only shifts the sampling within the one cycle,

in fact it is used here:

	EPwm7Regs.CMPA.bit.CMPA = ADC_SAMP_INST;   // for ADC SOC generation

But, from my last picture, you can see that the sampling needs to happen 2.5 cycles before. The 0.5 factor is easy, but where do I specify to read 2 whole cycles before?

From my understanding, what triggers the decimation is this part of code, in the resolver.c:

if (resolver_algo_Float())
{
      EPwm7Regs.ETCLR.bit.INT = 1;                // clear EPwm1 INT flag
}

So the routine "resolver_algo_Float" should return 1 when it's the peak of the sinewave.

There is no documentation about it because is part of TI libraries; will it detect the peak automatically? As I said, I am being cautious and I haven't plugged the sin/cos signals to the ADCs yet.

Thanks

OK, ADC_SAMP_INST sets the sampling instant within the 12.5us (or 6.25us) window. This is supposed to be adjusted to sync with the sine peak when the sampling window is close to the peak of the sine wave.

There is another variable called 'rslvrIn.firLag', this sets the count of the window where the peak is supposed to occur. Depending on the amount of phase shift in the sine wave feedback wrt the sine table, you can pick this number. If the sine table has 8 entries, the 90deg mark should occur corresponding to after the 3rd entry of table is put out, which will have an index of 2. You can experiment adjusting these two values and evaluate.

Hope it helps.