Attached is the schematic of part of a circuit which shows a ripple counter with a reset circuit. The counter should count up to 59 and then reset. However it only counts to 39 before resetting. If I attach a X10 scope probe to pin 10 of the AND gate it works correctly.

What is going on here, please?

 

If you show us a lot more of the circuit perhaps some of us can see the problem. With what we are shown there is no chance of seeing the cause of the problem.
BUT Here is a hint: "Ripple counter problems are often created by accumulated propagation delays."
If tht hint does not solve your problem, you need to show us the whole circuit.

 

Attached is the full schematic.
Clock Circuit

 

Ripple counter glitch.
Put an RC low-pass filter on the output of the AND gate.

 

Ripple counter glitch.
Put an RC low-pass filter on the output of the AND gate.

In the process of changing the output from 39 to 40, the change sequence low byte changes before the high byte changes. This produces the glitch that causes the problem. And the tiny snip of the circuit does not allow me to see enough to suggest a fix in any detail. But it is caused by partial decoding, only using two bits to trigger the reset.

And if attaching the scope probe to the and gate output makes it work. the small amount of added capacitance delays just enough. So hang a 47PF capacitor from pin ten to the common. on that IC.

 

In the process of changing the output from 39 to 40, the change sequence low byte changes before the high byte changes. This produces the glitch that causes the problem. And the tiny snip of the circuit does not allow me to see enough to suggest a fix in any detail. But it is caused by partial decoding, only using two bits to trigger the reset.

The full circuit is attached to post #3

 

Hello,

The full circuit does not work. I get a blocked page.
Please upload the schematic to the forum.

Bertus

 

Hello,

The full circuit does not work. I get a blocked page.
Please upload the schematic to the forum.

Bertus

It does not even do that for me. Nothing at all!! I tried it several times before I asked.

 

Try this one.

 

Attached is the schematic of part of a circuit which shows a ripple counter with a reset circuit. The counter should count up to 59 and then reset. However it only counts to 39 before resetting. If I attach a X10 scope probe to pin 10 of the AND gate it works correctly.

What is going on here, please?

Almost certainly it is a glitch on your reset signal that is being suppressed by the capacitance of your scope probe.

Internally, this is a synchronous counter, so in going from 3 (0011) to 4 (0100), the ouputs can change in any order. Which means that the possible paths are

0011 -> 0010 -> 0000 -> 0100 (this is what it would almost certainly do if it were a ripple counter)
0011 -> 0010 -> 0110 -> 0100 (your AND gate will glitch for a shorter time)
0011 -> 0001 -> 0000 -> 0100
0011 -> 0001 -> 0101 -> 0100
0011 -> 0111 -> 0110 -> 0100 (your AND gate will glitch for a longer time)
0011 -> 0111 -> 0101 -> 0100 (your AND gate will glitch for a shorter time)

Notice that fully decoding the 6, instead of just looking for the specific two bits to be HI, will not solve this problem as you will have to paths that can produce 0100 when transitioning from 3 to 4.

While you can probably fix this by putting a small capacitance (comparable to your probe capacitance) on the output of your AND gate, that is really nothing more than a slip-shod patch on a fundamentally poor logic design and you are opening yourself to problems down the road as the circuit doesn't work at a different temperature or a slightly different supply voltage or after you swap out an IC or build a copy of it or change the layout.

The better option is to properly design your logic.

Whenever you use asynchronous logic, you accept the responsibility for identifying and evaluating potential critical race conditions. This is not trivial, so unless you are willing to contend with the demons that lurk in those waters, it is best to avoid them by designing fully-synchronous circuits unless you have a damn-good reason not to (and damn-good reasons do exist).

 

The better option is to properly design your logic.

So what would be the proper way to implement this count 0-59?

 

It might be adequate to take the reset from the other side of D4.
But in addition, I do not call adding a small delay capacitor, even with a 1K ohm series resistor to add delay, as a poor design, if the intent is to stay with the non-synchronous counter.

 

You can get 0-5 with a 7492 or 74LS92 ripple counter without requiring extra gates.
If you want to use CMOS synchronous counters you can select 74HC192 or 74HC160-163 counters.

 

It might be adequate to take the reset from the other side of D4.

Which would also reset it every time S2 is pressed. I haven't backed out the purpose of S2, so maybe that's acceptable, but it still changes the behavior of the system.
It also doesn't guarantee that glitches won't get through the diode, particularly if the long-glitch path occurs.

But in addition, I do not call adding a small delay capacitor, even with a 1K ohm series resistor to add delay, as a poor design, if the intent is to stay with the non-synchronous counter.

I do. It's a patch being added because this particular set of components, in this particular layout, at this particular temperature, has a critical race at that particular point of the circuit. The approach being taken is playing whack-a-mole. Take this off a breadboard and put it on a PCB, and you might end up losing a critical race somewhere else in the circuit and discover some other place that you have to add a filter. Build ten of these, and you might end up losing some other critical race on some and yet a different critical race on others. Someone puts one of these into a refrigerated container or a hot attic space and it starts misbehaving. Replace a component on a board that has been working fine for years and now it misbehaves because a critical race that just happened to be won with the prior set of components is now being lost. The same might happen with a board that hasn't been touched just because of aging effects. This is design-by-happening -- you design an asynchronous circuit without doing the due diligence for the demons that lie in wait and then put out the fires that they happen to ignite today and hope that you happen to get them all so that no fires ever get lit again.

If it's a good design, then the need to add that filter, at that point (and every other point where there is the potential for a critical race, such as at the other two AND gates, if nothing else) would have been identified and incorporated BEFORE observing any critical races that happen to be lost and no issues should ever have been observed in the circuit from the get go because, by design, the critical race issues would have been addressed.

 

This is a kit, not my design.
https://leap.tardate.com/electronics101/digitallogic/digitalclockkit/

 

This is a kit, not my design.
https://leap.tardate.com/electronics101/digitallogic/digitalclockkit/

Which underscores that it was a bad design. The person that designed it clearly didn't do the kind of evaluation that is needed when designing asynchronous circuits. They probably got lucky and it happened to work in the one actual prototype they built and so they essentially sent it out into production and left you and other customers to deal with the deficiencies of their marginal design.

 

On the other hand it now costs £1.28 with free shipping - worth it just for the parts!!

 

On the other hand it now costs £1.28 with free shipping - worth it just for the parts!!

There is definitely something to be said for that.

 

Please consider that fixes applied to a one-off hobby project , which work in that particular implementation of some design, are certainly needing much careful evaluation before use in a production run of many units.
A ripple counter is not often the best choice, but sometimes they function adequately well.