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?
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.
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.
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.
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.
