13
\$\begingroup\$

I have read about the Gray code, but in practice I don't get what is the advantage of it over the binary code.

Some absolute encoder manufacturers offer both types so one has to decide before buying one. I for example need to measure the rotation angle for a very slowly rotating rod and many tomes fixed. In what circumstances or applications gray code output has advantage?

\$\endgroup\$
  • \$\begingroup\$ Try manufacturing a sensor and get back to us. \$\endgroup\$ – Harper - Reinstate Monica Oct 27 '19 at 14:02
42
\$\begingroup\$

Imagine the encoder is a 12-bit encoder sitting right at the mid-scale transition between 0x7FF and 0x800. If the inner workings of the encoder consist of something like a code wheel with 12 independent photodiodes, all 12 bits would have to change at once, for a negligible movement. Since there are mechanical tolerances, some of the bits would change before others and there would be a lot of confusion at that particular angle. The same problem exists at every other position where more than one bit changes at a time.

Using a Gray code for the code wheel completely eliminates that problem provided that the tolerances don't exceed a fraction of an LSB since only one bit changes at a time, and worst case your negligible motion results in a change equal to the resolution of the encoder.

Modern high resolution encoders can use other methods (such as a very fast camera reading a coded strip) and take care of sampling properly so you always get a result that makes sense.

| improve this answer | |
\$\endgroup\$
  • \$\begingroup\$ I have a cheap binary encoder and when it stands super still there is always one or two bits fluctuation. Can this be an example for downside of binary? \$\endgroup\$ – user1245 Oct 25 '19 at 12:22
  • 5
    \$\begingroup\$ Sounds more like a downside of a cheap encoder. \$\endgroup\$ – Spehro Pefhany Oct 25 '19 at 12:23
  • \$\begingroup\$ Just to be sure sorry if Im repeating myself, can we then say the gray code only has advantage over binary if the encoder shaft is moving? \$\endgroup\$ – user1245 Oct 25 '19 at 12:24
  • 5
    \$\begingroup\$ no, if it stands still at an in between position, you will have the same issue. \$\endgroup\$ – Sclrx Oct 25 '19 at 12:43
  • 7
    \$\begingroup\$ Binary at 0x7FF-0x800 = up to 12 bit fluctuation; Gray at mid-scale = up to 1 bit fluctuation. \$\endgroup\$ – rdtsc Oct 25 '19 at 12:56
20
\$\begingroup\$

In Gray code, the transition between two adjacent values only changes a single bit. This is a huge advantage in any sort of mechanical or optical encoder, because it's virtually impossible that you can make two or more bits change state at exactly the same time under all circumstances.

This becomes even more important if you're going to sample the data by, say, capturing it in a register. There's some chance that the data will be changing at the same time that you clock the register, leading to metastability in the bit(s) that are changing. In Gray code, since only one bit is changing at a time, the ambiguity is between two adjacent values and the absolute error is limited to ±1 count.

It's easy to translate from Gray to binary, and if an encoder offers a binary output, most likely they're simply doing the translation for you.

| improve this answer | |
\$\endgroup\$
  • \$\begingroup\$ I dont understand why error is less in gray code. Lets assume the encoder is not moving just staying still and sending the angle info bit by bit, can you tell me how in that case gray code transmits more stable signal? \$\endgroup\$ – user1245 Oct 25 '19 at 12:04
  • \$\begingroup\$ The difference between the codes is not important in serial transmission. The issues that I'm talking about in my answer have already been taken care of. At that point, it's simply a matter of preference. If the rest of the system is already configured to deal with Gray code, then it makes sense to select that type of sensor. Otherwise, binary might be more directly useful. \$\endgroup\$ – Dave Tweed Oct 25 '19 at 12:13
  • 7
    \$\begingroup\$ Obviously the data doesn't change if there's no movement at all. But even if stopped, the shaft could have stopped directly on the transition between two values, and mechanical vibration and/or electrical noise could cause data transitions. But the issues are important whenever your shaft does move. After all, if it NEVER moves, then you don't need an encoder at all! \$\endgroup\$ – Dave Tweed Oct 25 '19 at 12:18
  • 3
    \$\begingroup\$ @atmnt The usual logic circuitry has a logic margin, a region of voltages that are NOT defined as '1' or '0'; every transition of an encoder goes through such an undefined region, where some values are indeterminate. THAT is where the Gray code gives accurate results, and the binary code does not. Noise that does not disturb a full-logic-swing signal DOES disturb an indeterminate signal. \$\endgroup\$ – Whit3rd Oct 25 '19 at 17:18
  • 1
    \$\begingroup\$ @atmnt let's assume that your sensor reads one bit wrong because of some issue with movement, noise, or anthing else. In gray code, this means that the reading will be +/- 1 from the intended value. In traditional encoding, this may be a very large difference if the most significant bit is read wrong. \$\endgroup\$ – Peteris Oct 25 '19 at 21:00
10
\$\begingroup\$

You've mentioned that you see the value fluctuating by 1. Let's assume for now that this is due to physical limitations in the measurement.

For a binary code, you could get unlucky in some situations. Say you are stopped almost exactly on the transition between values 15 and 16 (in binary, 01111 and 10000). So it is switching between the two values. However, the bits cannot all switch at exactly the same time, for a number of reasons (mechanical/optical/electrical). The time that they switch can be made to be very close, but sometimes the next circuit will get a value with only some of the bits from each value. This is like randomly choosing a bit value for each bit. For example, it could read 01001, or a value of 9. This is not even close to the desired values of 15 or 16.

On the other hand, using a Gray code, only a single bit will change between 15 and 16. I don't know offhand what they would be, but for the sake of example take the two Gray coded values to be 01011 (15) and 11011 (16). Now, for each bit, randomly choose between the two options, and you will see that the only possibilities are the two desired values.

| improve this answer | |
\$\endgroup\$
  • \$\begingroup\$ This answer nicely describes the specific advantage of Gray over binary (not "blipping" through 9 when you go from 15 to 16). I'd add that it's not just "stopping" at an intermediate point, but that the electronics reading your encoder could measure and record it at any time, so that your data stream ends up having spikes in it if you use a binary encoding pattern. \$\endgroup\$ – RLH Oct 28 '19 at 1:07
4
\$\begingroup\$

As mentioned here above, gray codes only allow for a single bit (which may or not be the LSb) to change at a time. This prevents value glitches with multiple bits changing at the same time; especially with combinatorial logic. This was really important many years ago when I started designing motion control and sensing systems that were faster than the CPUs we had available. Much of the algorithms were implement in hardware with discrete logic and, if we were lucky, PLAs (PALs, GALs, primitive FPGAs or FPLAs). Another advantage is that crosstalk and line noise are greatly reduced.

There will always be the potential for jitter to occur. If an encoder is stopped right on the edge of a transition between two stable points, a single bit may well bounce between a 0 and a 1. The cause can be something as simple as vibration from a running motor performing a function that has nothing to do with the encoder. The higher the resolution of the encoder, the more this is likely to happen. It's just the nature of the beast. A good example would be a stepper motor with 200 steps per revolution using a 10-bit encoder. Motor steps and encoder steps will never, ever line up exactly.

| improve this answer | |
\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.