CCS/SM320F28335-EP: TMDSRSLVR: What is LOS and why it set

The code is available in Resolver-Main.c, and it compares the magnitude of resolver feedback signals to a predefined limiting value. The magnitude is computed in library but the value is visible in debug window. 

The section of code that deals with LOS is a provisional code for the user to enhance. Based on the value of 'resmag' obtained during test conditions, the user can intuitively set some limits for protection. The associated comment in the code could help a bit.

Dear Ramesh: Nice to hear from you again, how are you?. I do remember you since 2017/18.

In regard to associated comment, where to find it?, thx.

#BTN-26:RES_ANGLE(0)
----------------------------------------
rslvIn.offsetSin       : 1.038672 | dc offset of sin fbk analog channel
rslvIn.offsetCos       : 1.045667 | dc offset of cos fbk analog channel
rslvrOut.angleRaw      : 0.232585 | raw angle estimate from arctan.
rslvrOut.angleObs      : 0.232729 | observer angle estimate w/o FIR delay comp.
rslvrIn.resMag         : 0.311693 | resolver fbk mag.
rslvrOut.errorNew      : 0.000041 | new angle error estimated by the observer.
rslvrOut.angleOut (Rad): 0.232590 | final angle estimate after FIR delay comp.
----------------------------------------
rslvrOut.resMagQ20     : 0.305854 | resolver magnitude in Q20.
resMaxQ20              : 0.317402 | resolver magnitude in Q20.
resMinQ20              : 0.299156 | resolver magnitude in Q20.
----------------------------------------
rslvrOut.angleOut (Deg): 41.918094
Angle Out      (deg/10): 416
rslvrIn.rpsObs(Speed)  : 1.119828 | shaft speed estimate by the observer
----------------------------------------
DOS_ERROR Error Flag   :0x0000
LOS_ERROR Error Flag   :0x0001
PLL_ERROR Error Flag   :0x0000
----------------------------------------

2nd capture 

----------------------------------------
rslvIn.offsetSin       : 1.038672 | dc offset of sin fbk analog channel
rslvIn.offsetCos       : 1.045667 | dc offset of cos fbk analog channel
rslvrOut.angleRaw      : 0.232461 | raw angle estimate from arctan.
rslvrOut.angleObs      : 0.232715 | observer angle estimate w/o FIR delay comp.
rslvrIn.resMag         : 0.312960 | resolver fbk mag.
rslvrOut.errorNew      :-0.000144 | new angle error estimated by the observer.
rslvrOut.angleOut (Rad): 0.232313 | final angle estimate after FIR delay comp.
----------------------------------------
rslvrOut.resMagQ20     : 0.312426 | resolver magnitude in Q20.
resMaxQ20              : 0.321434 | resolver magnitude in Q20.
resMinQ20              : 0.297489 | resolver magnitude in Q20.
----------------------------------------
rslvrOut.angleOut (Deg): 41.867153
Angle Out      (deg/10): 418
rslvrIn.rpsObs(Speed)  :-1.437343 | shaft speed estimate by the observer
----------------------------------------
DOS_ERROR Error Flag   :0x0000
LOS_ERROR Error Flag   :0x0001
PLL_ERROR Error Flag   :0x0000
----------------------------------------

Hi Ramesh

The above is a snapshot while the motor is stationary, I was wondering if you may explain the above number meaning related to LOS. What you think of a number, are they good?. The Vpp of TX signals is 6.3V in good sinewave (10KHz)

I note the rpsObs, shaft speed is jumpy in readout when the shaft is in a static position, is there a reason for this?.  Is there a way to improve that?

BTW: I have read more about the control observer concept along with TI documents related to the resolver. 

When the readout is done, it reset the number as shown below. 

void mResolver_ClearFlag(void)
{
	zRes_Angle10   = 0;
	zResolver_Flags.zResWord & 0x000F;
	//	zResolver_Flags.DOS_ERROR  = 0;
	//	zResolver_Flags.LOS_ERROR  = 0;
	//	zResolver_Flags.PLL_ERROR  = 0;
	resetAll   = 0;
	skipLosCnt = 0;
	resMagMax  = _IQ(-2.0);
	resMagMin  = _IQ(2.0);
}

Hi Richard,

Due to quantization error, for the same sampling instance, there could be variations in the LSBs of the end result. This can lead to minor jumpiness that you observed. This is where the observer helps to smooth it out.  To reduce jumpiness in the observer output, you may need to tweak the values of the PI coefficients in the loop. I would consider reducing Kp and/ or reduce Ki.

The reset is meant to be user initiated from the expressions window (in debug perspective) by setting resetAll = 1, during eval time. 

Is there another C2000 MCU that supports the resolver driver from TMDSRSLVR_v1.0 kit?

For example, will the Resolver_f28035_CLA work on F2804x, F2807x MCU or TI need to recompile "hidden source code" to a library from your end. Is there a plan to update?

R. 

It should work as such, let us know if you see any issues.

Did you run into any issues?

I have been side tracked at the moment.