Please suggest an algorithm to compare Gray code numbers

Question

I have an absolute encoder which is outputting a 10 bit value (0 to 1023) in Gray code. The problem I am trying to solve is how to figure out if the encoder is moving forwards or backwards.

I decided that the “best” algorithm is as follows: first I convert the Gray code to regular binary (full credit to the last answer in: https://www.daniweb.com/programming/software-development/code/216355/gray-code-conversion):

int grayCodeToBinaryConversion(int bits)
{
  bits ^= bits >> 16; // remove if word is 16 bits or less
  bits ^= bits >>  8; // remove if word is 8 bits or less
  bits ^= bits >>  4;
  bits ^= bits >>  2;
  bits ^= bits >>  1;
  return bits;
}

Second I compare two values that were sampled apart by 250 milliseconds. I thought that comparing two values will let me know if I am moving forwards or backwards. For example:

if((SampleTwo – SampleOne) > 1)
{
  //forward motion actions
}

if((SampleTwo – SampleOne) < 1)
{
  //reverse motion actions
}

if(SampleTwo == SampleOne)
{
  //no motion action
}

Right as I started to feel smart, to my disappointment I realized this algorithm has a fatal flaw. This solution works great when I am comparing a binary value of say 824 to 1015. At this point I know which way the encoder is moving. However at some point the encoder will roll over from 1023 to 0 and climb, and when I then go to compare the first sampled value of say 1015 to the second sampled value of say 44, even though I am physically moving in the same direction, the logic I have written does not correctly capture this. Another no go is Taking the Gray code value as an int, and comparing the two ints.

How do I compare two Gray code values that were taken 250 milliseconds apart and determine the direction of rotation while taking into account the rolling over aspect of the encoder? If you are so kind to help, could you please provide a simple code example?

How much do you expect your encoder to move in a 250ms interval? — xrisk, Sep 16 '18 at 18:46
not more than 400 pulses (ball park). But when it goes from 950 to 250, my algorithm doesn't work. — Mike, Sep 16 '18 at 18:48
One way to do it, is to compute the difference between the readings assuming you're going "forwards" and then going "backwards". You then _assume_ that the encoder is travelling in the direction of the smaller value. Of course, this would fail if your encoder is going to travel more than half the interval in 250ms; in which case you would increase the sampling frequency. — xrisk, Sep 16 '18 at 18:48
The result of S2-S1 is in the range -1023 to +1023; of that range, -1023 ~ -512 and +1 ~ +511 are forward and -511 ~ -1 and 512 ~ 1023 are backward. — m69's been on strike for years, Sep 16 '18 at 19:00
@m69, there is no negative range. The values are limited to a range between 0 to 1023. Based on the difference in the values I am trying to figure out the direction of rotation. — Mike, Sep 16 '18 at 19:07
I'm talking about the range of `SampleTwo - SampleOne`. If S1=990 and S2=12 then S2-S1=-978, which is in the range -1023~-512, which means forward. — m69's been on strike for years, Sep 16 '18 at 19:10

score 4 · Accepted Answer · edited Sep 16 '18 at 19:57

Suppose A is your initial reading, and B is the reading after 250ms.
Let's take your example of A = 950 and B = 250 here.

Let's assume the encoder is moving forwards (its value is increasing with time).

Then, the distance covered is (B - A + 1024) % 1024. Let's call this d_forward.

For this example, d_forward comes out to be (250 - 950 + 1024) % 1024 = 324.

The distance covered going backwards (d_backward) would be 1024 - d_forward; which is 700.

The minimum of d_forward and d_backward would give the direction the encoder is travelling.

This will not work if the encoder is going to travel more than 1023/2 units in 250ms. In such a case, you should decrease the intervals between taking readings.

I'm very surprised that this is the right answer. I would have thought that Mr Frank Gray would have also created some mathematical operators to go along with his system. I tip my hat to you Rishav.... Thanks! — Mike, Sep 16 '18 at 22:38

Matt Timmermans · Answer 2 · 2018-09-16T20:20:27.193

Rishav's answer is correct, but it can be more easily calculated.

Let A and B be two readings made 250ms apart and converted from gray code to binary.

The difference in encoder position is just diff = ((1536 + B - A) & 1023) - 512. If you'd prefer not to use bitwise math, then diff = ((1536 + B - A) % 1024) - 512.

Note that 1536 is 1024+512, and the answer diff is determined by two constraints:

diff = B-A mod 1024
diff is in the range [-512, 511], which would be the normal range for a 10-bit signed number.

If your encoder is allowed/expected to go faster in one direction than the other, then you can adjust the range in (2).

To allow answers in the range [MIN,MIN+1023], use diff = ((1024 - MIN + B - A) % 1024) + MIN

If MIN is positive, add a large enough multiple of 1024 to make sure that it's positive before you do the modulus operation, since the modulus operator in most languages behaves oddly with negative numbers.

Please suggest an algorithm to compare Gray code numbers

2 Answers2