Part Number:PGA411-Q1
Hi Team,
My customer is doing some failure-mode tests with their main board that uses the PGA411-Q1 resolver, and they have found some behavior that I'd like to confirm with you. First of all, they have the SPI interface to the resolver (which is used for configuration at start-up), but they mostly rely on the encoder A/B output signals to consume data from the resolver; they only use SPI for checking faults.
Case 1: Initialize the resolver via SPI when the input sin/cos signals are not valid (both are at ground).
- The resolver reads that as garbage values (very high, unstable RPM values). We’ve verified DEV_STAT5 and DEV_STAT6, and we see the corresponding garbage values.
- Turning on the motor controller after we start reading garbage values does NOT make the RPM values reasonable. We've looked at the signals at the scope, and the sin/cos input signals look fine; however, my guess is that because we initialized the resolver with invalid inputs, somehow it is not able to parse valid inputs later.
Case 2: Initialize the resolver via SPI when the input sin/cos signals are valid.
- In this case we read correct encoder deltas and RPM values.
- Turning off the motor controller (and thus when sin/cos are valid), the resolver starts reading garbage values (very high, unstable RPM). Similarly, the DEV_STAT5 and DEV_STAT6 register show the garbage values.
- Turning the motor controller back on sometimes makes the readings stable again, sometimes it doesn’t. We could not find a correlation between when the readings stabilize and anything else.
With this, we have a few questions:
1. Is there anything we can do about the initialization concern? They can guarantee that the resolver is initialized when the input signals are valid, but it'd be nice if we could avoid this behavior.
2. Can we avoid garbage outputs in the failure mode of sin/cos going to ground? This is the most likely failure of the signal.
3. After a motor controller power loss, how can I re-stabilize the output? Do I have to re-initialize the resolver? Any idea why it restores values sometimes, but sometimes it doesn’t?
Thanks,
Mitchell