I'm working on a software quadrature decoder and testing with a Lego EV3 medium motor (which has an integrated quadrature encoder).

The thing is, while the large motor produces perfectly normal-looking quadrature output, my medium motor produces this:

Forward Reverse Close forward rise Close reverse rise

Channel 2 transitions always lead Channel 1 by 130-200µs. It is, technically, the right transition sequence for quadrature, but the two signals are almost in phase or antiphase depending on direction.

It's notable that these waveforms are consistent with the ev3dev implementation of the decoder (which I assume is consistent with the Lego implementation) which runs at half resolution by treating edges on one input as clocks and the difference between the two signals as direction. These waveforms act like they're preparing specifically for that kind of detection (keeping the two edges close maximises the time available to software to sample them correctly).

I had hoped to avoid doing it that way because of the reduced precision. I want the code to be a generic, full-precision quadrature decoder but also to work with these motors.

The schematics that Lego provide shows what looks to me like a perfectly normal encoder: EV3 medium motor schematic

Even if the sensors aren't well aligned or if they're slow to transition because the LED is too weak, they still shouldn't produce this output should they? My reasoning is that if it's an alignment problem then they should show the same phase overlap in both directions -- not a negative one.

I'm wondering if both lines are ramping slowly, internally, but the transition of the schmitt trigger output on one line causes some kind of noise that provokes earlier detection on the other line.

That doesn't sound right. Does anybody have any better ideas what's going on here?

  • \$\begingroup\$ Here is someone else with similar experience of poor quadrature signal phasing, looks like it is a side effect of consumer encoders. - vexforum.com/index.php/… \$\endgroup\$
    – KalleMP
    Dec 5, 2016 at 0:30
  • \$\begingroup\$ Well, the good news is that this isn't why my code didn't work. That turned out to be I/O configuration problems. But now I see that I have to be especially careful to choose the right line for clock. \$\endgroup\$
    – sh1
    Dec 5, 2016 at 6:05

2 Answers 2


It may just be cheap. Rather than setting the phase accurately as WhatRoughBeast says, the engineers who designed this one may have just said "Well, you can find speed and direction from this, good enough!"

The schematic shows that both phototransistors are part of the same package, so they may just be oriented in a way that they pick up the transitions in the expected order, not worrying about phase.

the phototransistors are in a single package

  • \$\begingroup\$ But if it's just non-ideal alignment, then shouldn't the forward and reverse directions show the same degree of overlap? I'm finding that when I reverse the overlap inverts. It's like the phase switches from 10° to 170° rather than to -10°. \$\endgroup\$
    – sh1
    Dec 6, 2016 at 2:27
  • \$\begingroup\$ Yeah, with what I'm suggesting the signals should be in-phase most of the time. I can't think of a physical mechanism that would do this, except for something sliding around on the inside when you change direction. \$\endgroup\$
    – Daniel
    Dec 6, 2016 at 4:46
  • \$\begingroup\$ If the input with the lagging phases does not change when the direction is reversed then it suggests that there is a weakness in the electronics and that phase is not as responsive when the other phase is in a particular state, this may be due to PSU current limits or other interaction we can only guess at. \$\endgroup\$
    – KalleMP
    Dec 20, 2016 at 17:42
  • \$\begingroup\$ If the signals are otherwise valid, it is a VERY CONVENIENT way to determine which direction the encoder is going without tracking it directly... \$\endgroup\$
    – Daniel
    Dec 20, 2016 at 18:28

I'd guess that you have a bad encoder. Well, not bad (quite) since it does work to determine speed and direction, but not operating at full resolution, either.

I'd guess that it uses a single code wheel with the phototransistors offset at an angle to the radius in order to get the proper spacing. I suggest that the PTs are set at the wrong angle.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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