Re: [Oap-discuss] Revised MCM schematic

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 454-5900

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Wow, that's news to me, but not surprising since I'm by no means an
expert in this field.&nbsp; I've always seen the decoding modes represented
as a state machine, where 4 states are always shown as being detected,
but an up pulse only fires on say, state 1, and a down pulse on say,
state 2.&nbsp; In this case, you will not miss any counts.&nbsp; It is implied
that some reliable method is used to see state transitions. <br>
<br>
For example, in this datasheet, on pages 13 and 14 the state diagram is
shown and the 1X output is described:<br>
<a
 href="http://www.ortodoxism.ro/datasheets2/9/0pwko2dju37tu51lp5cltg8eso3y.pdf">http://www.ortodoxism.ro/datasheets2/9/0pwko2dju37tu51lp5cltg8eso3y.pdf<br>
</a><a
 href="http://www.ortodoxism.ro/datasheets2/9/0pwko2dju37tu51lp5cltg8eso3y.pdf"></a><br>
I've never seen a datasheet show that it only looks at rising edges, or
that it could lose counts in the 1X mode.&nbsp; If you have any references
I'd be interested.<br>
<br>
In any case, I totally agree that it's not critical for this
application, and I doubt any users of the OAP platform will ever see a
problem in practice.&nbsp; Sorry for beating a dead horse ;)<br>
<br>
Randy<br>
<br>
<br>
Dafydd Walters wrote:
<blockquote cite="mid:47E...@us..."
 type="cite">
  <pre wrap="">Randy Gamage wrote:
  </pre>
  <blockquote type="cite">
    <pre wrap="">Standard 1X decoding doesn't have this flaw - it just gives
you lower resolution than 2X and 4X, but it will never
lose counts like this design does.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
I disagree. Everything I've read about 1x decoding (which is just
sampling the 'B' channel at every rising edge of the 'A' channel)
suggests that the flaw is INHERENT in the decoding method.

As you have correctly pointed out several times, the problem arises when
the axle oscillates at a point around the rising edge of the 'A' channel.

The problem you describe only goes away when you use at least 2x
decoding (i.e. looking at both rising AND falling edges of one of the
channels).

When someone gets around to redesigning the MCM, I suggest we use full
4x quadrature decoding to get the best possible results, and this won't
be an issue any more.

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
<a class="moz-txt-link-freetext" href="http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/">http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/</a>
_______________________________________________
Oap-discuss mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Oap...@li...">Oap...@li...</a>
<a class="moz-txt-link-freetext" href="https://lists.sourceforge.net/lists/listinfo/oap-discuss">https://lists.sourceforge.net/lists/listinfo/oap-discuss</a>
  </pre>
</blockquote>
</body>
</html>