# sine/cos encoder to digital

1. ## sine/cos encoder to digital

I have sine cos data from encoder and have to convert it to digital corresponding to angle and estimate the velocity as well. I need to do this using MCU. any proven methods?

2. ## Re: sine/cos encoder to digital

What format is the encoder data at the moment? Presumably analog if it needs converting first.

Brian.

3. ## Re: sine/cos encoder to digital

You'll use atan2() function to convert sin/cos values to angle after digitizing it.

•

4. ## Re: sine/cos encoder to digital

Hi,

Sin/cos = tan

Thus divide your "sin" value by your "cos" value. Mint the undefined situations where cos value ( 90° and 270°)
Then from the tan value you may directly calculate the angle.Maybe use a lookup table and interpolation.
But you need to involve the signs of sin and cos value to determine the quadrants, because tan repeats every 180°.

Klaus

5. ## Re: sine/cos encoder to digital

Hi KlausST

How do we deal with infinity (cos90 or cos270)? Secondly I have to also consider time resolution of the incoming data. Input shaft rotates art low rpm (0-60 rpm) for the highest rpm, time resolution 1/4095 or 244 us. Please guide me regarding the scan rate of this signal?

6. ## Re: sine/cos encoder to digital

Hi,

How do we deal with infinity (cos90 or cos270)?
Rather straight forward:
If cos = 0, then there are just two possible solutions:
Phi = 90° when sin = positive
Phi = 270° when sin = negative.

Klaus

•

7. ## Re: sine/cos encoder to digital

atan2() function has no "undefined situations". It's defined over full four quadrants. Review literature before guessing…

Secondly I have to also consider time resolution of the incoming data. Input shaft rotates art low rpm (0-60 rpm) for the highest rpm, time resolution 1/4095 or 244 us.
Simultaneous sampling of both inputs would be good. Otherwise you have to perform time point interpolation.

Required time resolution is a different thing. It depends on the speed change rate (=bandwidth of the speed information). See similar thread https://www.edaboard.com/showthread....control-system

Of course there's no problem to increase the sample rate above the required minimum.

8. ## Re: sine/cos encoder to digital

Hi FvM

Just tried atan including quadrant detection. I find the readings of angle non monotonic. excel file attached

9. ## Re: sine/cos encoder to digital

The angle values are monotonic, but not equidistant. Obviously the sin/cos readings are not corresponding to constant speed rotation, there seems to be a higher frequent ripple superimposed.

10. ## Re: sine/cos encoder to digital

Hi FVM

Sampled the same signals at 10kHz. Please see the results(attached) . What should we conclude?

•

11. ## Re: sine/cos encoder to digital

What did you conclude?

The higher sampling rate doesn't change the picture, you have superimposed ripple during the first 45 degree. To me, it looks like a start transient. It shouldn't happen if you start the recording with settled motor speed.

12. ## Re: sine/cos encoder to digital

Hi FvM

How did you conclude about the superimposed ripple and how do we remove it. I am unable to make it out. I tried FFT of the two waveforms and it did not show any other component except 1Hz

13. ## Re: sine/cos encoder to digital

Just look at the waveform...

15. ## Re: sine/cos encoder to digital

Workaround for what? We are apparently seeing a real start transient. Unfortunately you didn't mention the test conditions.

16. ## Re: sine/cos encoder to digital

Hi FvM

The data was captured during running conditions, and I analyzed the data. The distortion of signal vanished, however the angle data points are not equidistant as previously posted. This poses difficulty in comparing with commercial converters, which provides both monotonic and equidistant angular points. So what should be the technique chosen to meet the requirement

17. ## Re: sine/cos encoder to digital

Can't comment unknown measurements.

18. ## Re: sine/cos encoder to digital

Hello!

There are a few things to take care about.
I didn't look at the data, but if you get a (sin, cos) pair of analog signals
from some kind of sensor, you have to first make sure that they are calibrated
(same amplitude) and that their phase is exactly π/2. If not, then you have to
start by a calibration and phase removal, which is not a big deal but must be
done.

Then, you have to be careful with the atan because it's undefined at -π/2 and
π/2. Therefore you have to proceed with quarter of periods in the following intervals:
π/4 ~ 3π/4 -> Calculate cos / sin (-1 <=value <= 1)
3π/4 ~ -3π/4 -> Calculate sin / cos
-3π/4 ~ -π/4 -> Calculate cos / sin
-π/4 ~ π/4 -> Calculate sin / cos
If you don't take the sign into account, then you will get angles between -π/4
and π/4. Then using the signs and the symmetries, you can calculate other
values.
NB: as all the tan value are between -1 and 1, it's easy to use a LUT and fixed point.
Anyway, even if you have some CPU power, atan will get you the angle on the
interval -π/2 and π/2 only, there is not function that will get you the angle at
once.

Dora.

19. ## Re: sine/cos encoder to digital

you have to be careful with the atan because it's undefined at -π/2 and π/2.
That's why we have atan2() function. It's already handling the atan() discontinuities.

The reported problem of superimposed ripple can be found in encoder x and y output signals (see post #10) and is not related to angle conversion.

Not sure how the latest measurements mentioned in post #16 look like. There may be a problem in angle conversion, but we should look at the x/y signals first.
The distortion of signal vanished, however the angle data points are not equidistant as previously posted.

•

20. ## Re: sine/cos encoder to digital

The data was captured during running conditions,
Take a look at the original set of data.

Sometimes a plot says a lot. So I plotted the last column against column 1.

This is what I get:

The angle data points are not really equidistant.

You can also see a spike at 90 and 270 degree (0.25 and 0.75 time points).

There is a small ripple but that is not the culprit.

The difference is about 0.04 (degree; quite small in my opinion).

But why the difference?

It is not random (only +ve values are seen except the two points).

I suspect the error in the software.

By the way, what is the resolution of the ADC?

- - - Updated - - -

NB: as all the tan value are between -1 and 1, it's easy to use a LUT and fixed point.
That is incorrect.

Just see the plot of tan(x) vs x:

(we cannot plot ±∞ and the graph is cropped).

It is not easy to use a LUT for tan(x).

--[[ ]]--