Counting issue w/ cascaded 74x191s and quadrature encoder - Page 1
Forum section: electronics / projects

author: iroc86
author_rank: Regular Contributor
timestamp: September 26, 2019, 01:06:09 am
content: I'm trying to implement a counter circuit and the up/down counting logic isn't working properly. I was hoping to get some advice on a solution based on my analysis below. My objective is simple: turn the knob one way and the digits count upward, turn it the other way and they count downward. For some reason, I'm seeing double counts when the most significant digit changes.This is a fairly straightforward two-digit decimal counter using a pair of cascaded 74HC191s and a rotary encoder. The binary counter output goes to some 74HC4511 BCD driver chips and 7-segment displays.I'm using aninterface circuitfrom Bourns to decode the quadrature output from the encoder to produce clock and direction signals that the '191 can understand:When I rotate the encoder to increase the count, the digits behave like this: 21, 22, ..., 29, 30, 40, 41, 42, ...and so on. There's an extra count on the ripple carry output from the least significant digit when the counter rolls over.I was able to capture this behavior on my logic analyzer. For the sake of testing, I'm outputting a square wave (Ch0) from my function generator and doing a 90-degree phase shift with some flip-flops to produce a quadrature signal (Ch1/Ch2) akin to the rotary encoder. This eliminates the mechanical hardware and makes it easier to consistently capture the data. Ch3 and Ch4 are the outputs from the Bourns interface circuit. As you can see on Ch5, the RCO output has an extra transition that is causing the erroneous counting.Now, if I hardwire the U/D signal either high or low, the counting behaves as expected. In the capture below, U/D is held low and RCO only sees one transition. The CLK signal is still coming from the Bourns circuit.If we zoom in on the "bad" behavior, it's evident that the RCO is triggering on the falling edge of the U/D signal produced by the Bourns circuit. The extra count "inside" is a result of the CLK transition (or possibly the U/D rising edge). Compared to the "good" behavior, the RCO triggers between CLK pulses as expected.Keep in mind that none of the above examples are actually changing the direction of the count. Due to the nature of the Bourns circuit, the U/D signal will always transition in accordance with the quadrature signal, so it'll never be pulled high or low for more than one clock cycle. I'mthinkingthat the issue here might have something to do with the 74HC191 itself. Thedatasheetexplicitly states that U/D should only be changed when the clock signal is high. Unfortunately, the Bourns circuit doesn't do this, even though it sufficiently pulls U/D one way or another before the clock transitions.That all being said, I'm left with the following questions:Am I sufficiently understanding the problem here, or am I missing something?What quadrature decoder circuitsdowork with the '191?Is the Bourns circuit intended for some other application or chip? (The 4029 counter, for instance, makes no mention of restrictions on U/D transitions. I don't have one of those chips on hand to test, unfortunately.)Any other options or advice? I'm looking for a discrete (non-MCU) counting solution.Thanks for reading this far. I've searched high and low for answers, but I haven't had any luck. I'm looking forward to hearing some ideas.

author: sarahMCML
author_rank: Regular Contributor
timestamp: September 26, 2019, 03:03:55 am
content: Hi iroc86,Wouldn't be something to do with a time delay problem within the counter itself, would it?Seems to me you're running the 191 as a ripple counter, with the associated delays that brings, rather than the synchronous clocking method shown in the data sheet. Could be that the direction change gets through before the clock pulse? Or vice versa!I'm trying to work this out in my head, but it's 4 in the morning and I may be barking up the wrong tree, so take it with a pinch of salt, as we say here!Just a thought.Sarah.

author: duak
author_rank: Super Contributor
timestamp: September 26, 2019, 03:32:12 am
content: It's been years since I worked with these so I hope I get this right1.) CLOCK has to be connected in parallel to all CP inputs; similar to the way DIRECTION CONTROL connects to the U/D inputs. These are synchronous counters where all the flip-flops are clocked at the same time.2.) The CE inputs of the 2nd & 3rd counters are connected to the RC output of the chip to their left, not to GND.

author: iroc86
author_rank: Regular Contributor
timestamp: September 26, 2019, 11:54:04 pm
content: Thanks for the ideas! I think both of you may be onto something with the ripple vs. synchronous configuration. Interestingly, the TI datasheet does not show the '191 in a ripple configuration, but the Nexperia (Philips) sheet does. I set this up as a ripple counter because I had used other counters that way, but I can give the synchronous method a try and report back.The datasheets also describe another configuration with "parallel gated carry/borrow" that involves some additional logic. What advantage does this version offer? The schematic shows a Terminal Count (TC) output, but that isn't identified on any of the pinouts. How does it work?

author: sarahMCML
author_rank: Regular Contributor
timestamp: September 27, 2019, 12:50:02 am
content: Hi again,The last few sentences on the Nexperia sheet explains the advantages of the figure 7 setup quite well. That being that as ALL data inputs are fed to ALL stages at the same time, propagation delay are minimised, the stages can be clocked at their maximum speeds, and equally importantly, race conditions are avoided.The down side being that as more stages are added, more inputs are required to each successive nand gate driving the /CE inputs.I doubt that this will be a speed problem for you manually turning a rotary encoder, though!Regards,Sarah

author: iroc86
author_rank: Regular Contributor
timestamp: September 27, 2019, 02:49:31 am
content: Great, I think I understand now. I must have missed that section in the Nexperia datasheet explaining the functionality. Also, it looks like the TC output that I couldn't find is actually Pin 12, which TI apparently calls MIN/MAX (though their examples still call it TC, at least on the CD7474HC19x sheets). I agree that the parallel gated version is definitely overkill for a simple rotary encoder application, but it's good to see some other implementations!I did manage to swap around my circuit to try the synchronous configuration and it works as expected now!The RCO output is still showing the double bump, but I'd imagine that it's not an issue because all of the chips are clocked simultaneously. Thanks for the help, duak and Sarah!