Resolver sensor calculations

Martin Võip

Posted on 18.09.2025 12:49

Hello,

I am using a PSCI inductive rotor position sensor to measure rotor speed and position with DEWESoft. The sensor output is essentially the same as a resolver output (sine and cosine signals).

The signals themselves look clear, but I observe noticeable shifts in the calculated angular position and corresponding spikes in the RPM signal (please see the attached picture). While the position shifts are not critical, the angular speed output is heavily affected, and simple low-pass filtering does not resolve the issue.

In addition, I noticed that even when the rotor is at standstill, the position reading remains stable, but the speed output shows periodic surges (up to ~2000%) about once per second. The same occurs when the rotor is moved very slowly by hand: the position appears correct, but the speed still shows brief, periodic spikes.

Could you please advise whether this behavior is related to software or hardware? Also, what would be the recommended way to filter or handle this type of signal in DEWESoft?

Thank you in advance for your support.

Rok Kmetič
Customer Support Engineer
Posted on 22.09.2025 11:46

Dear Martin,


I have asked the developer for some help, and below is the answer:


#1

[noisy data in => noisy data out]

This is not how the signal is supposed to look like. The amplitudes should be the same, but they are fluctuating like crazy (the bottom of the sine goes anywhere between 1.67 and 1.86 V).

No matter what we change inside the software, it won't be able to give the user reasonable results (except for very rough approximations).


image.png



#2

The gain and offset were set wrong and produced "useless results".

Here's a very, very rough setting that works much better for me (not ideal, slightly more tweaking might probably work, but there are no sharp frequency spikes at least):


image.png


image.png



#3

[This is a software bug]

The calibration fails. This is something that should probably be checked (It was reported to the developers).


#4

[This is a software bug]

There seems to be a bug in proper handling of angle wrapping. See the example below. When the angle wraps from 0 to 360 degrees, the frequency calculation goes wild ("delta function").


image.png


It could be that pole pairs (6) don't help either (it looks as if the calculated angle jumps by a full turn back and forth):


image.png



This last issue (#4) does not affect the calculation when the basic settings are right.

Fixing #3 might help in automatically calculating better parameters/settings (though there is a workaround: manual tweaking until one gets the best results).



Best Regards.

Martin Võip

Posted on 22.09.2025 13:14

@Rok Kmetič


Thank you!

Rok Kmetič
Customer Support Engineer
Posted on 09.01.2026 13:18

Dear Martin,


regarding the third point:

#3

[This is a software bug]

The calibration fails. This is something that should probably be checked (It was reported to the developers).



I was notified by the developer that this is the expected behaviour. The calibration is impossible, because the signal is too short.

We have spend some time to tweak the calibration procedure, such that it checks for stable frequency, and so on.


A workaround is to obtain the offset and gain by other means, e.g. statistics.

We could reduce the number of checks, but then it would be very easy to produce a bad calibration.


We suggest to calibrate online at steady speed and use the calculated gain and offset in analysis. You can type it in the setup in another datafile or another instance of resolver sensor.


Best Regards.

Login to reply to this topic. If you don't have account yet, you can signup for free account .