I think you'll find the Agilent (HP) parts will sample the input signals albeit at a higher rate than the software example. So if the input is oscillating (which I have seen also - normally on servo motors as you get mechanical vibrations) at a rate higher than you are sampling (in the case of the Agilent parts ~1MHz) you will get count errors. I think the solution here is to always look for two gray-code transitions - both phases must change to register a count. The first step to avoid the oscillation problem is to have adequate hysteresis on the optical side and well as analog bandwidth limiting - this takes care of really high frequency oscillations, the other source of oscillation will most likely be mechanical and thus fairly low in frequency. If your sample rate is in excess (>2 times) your max frequency of interest then count problems shouldn't be an issue.

With Raghu saying that the only valid solution is to use the HCTL2xxx parts or a fpga is not telling the whole story - I'm sure given certain conditions that the above solutions would fail also. I wonder what Agilent would say about this issue regarding their encoders and ic's?

I think Michal needs to be aware of the potential problems as we all do as well as making sure that he knows the maximum freuqencies of interest in his application. For a hand operated control style encoder the frequencies are going to be quite low thus Peter's software example will most likely work fine. If we're talking about a 12000rpm motor with a 500cpr encoder the frequencies are much higher and thus Peter's software solution may not be viable - personally I'd be using an Agilent chip or maybe a fpga or something with the required hardware for the encoder. I'm about to pull out some servo motor stuff and will probably start with the venerable HCTL1000 device, I might then look at DSP chips with the built in hardware for reading the encoder or I might think about implementing the HCTL1000 in an fpga. Depends on my motivation.