Author Topic: 74HC390: Ripple Counter is Counting Rubbish  (Read 7052 times)

0 Members and 1 Guest are viewing this topic.

Offline DarkwingTopic starter

  • Contributor
  • Posts: 42
  • Country: de
  • Let’s get dangerous!
74HC390: Ripple Counter is Counting Rubbish
« on: May 01, 2019, 08:53:57 pm »
Hi folks!

I'm currently experimenting with a CD74HC390 Ripple Counter. I want to use it to simply divide a pulse signal. Here's the breadboard:



It seemed an easy task at first, but I found out that it is not so ...   |O

Why do I get this from the outputs:



When the datasheet says, that I should get this:





It's messed up completly.  :(
The QA stage does invert (?!) my signal, instead of dividing it by 2!  :-BROKE
The following stages QB and QC are not even close to a recognizable pattern.

What could be wrong?  :-//

Is it somehow necessary to "stabilize" the IC, that it can work correctly? I already found out, that a 0.1µF cap across VCC and GND does a little good to the signal quality.

Can someone give a hint?


Thanks in advance!   :) :)




EDIT: You can jump right to this message, to see more pictures and a solution.
« Last Edit: May 09, 2019, 04:57:26 am by Darkwing »
 

Offline sarahMCML

  • Regular Contributor
  • *
  • Posts: 81
  • Country: gb
Re: 74HC390: Ripple Counter is Counting Rubbish
« Reply #1 on: May 01, 2019, 11:32:43 pm »
Hi,

Your layout looks fine, but you may have a bad connection somewhere. The most likely reason though is because the other section of the counter has its inputs left in an undefined state. Try tying the two A side clocks and its reset to 0V, and it should eliminate any spurious interference from that side.

Regards,

Sarah.
 

Offline schmitt trigger

  • Super Contributor
  • ***
  • Posts: 2431
  • Country: mx
Re: 74HC390: Ripple Counter is Counting Rubbish
« Reply #2 on: May 02, 2019, 03:23:04 am »
HC logic is very fast. Sub microsecond noise pulses, completely invisible at your ultra-slow timebase, can cause spurious clocking.

It has happened to me.
« Last Edit: May 02, 2019, 03:29:37 am by schmitt trigger »
 

Offline EEVblog

  • Administrator
  • *****
  • Posts: 39026
  • Country: au
    • EEVblog
Re: 74HC390: Ripple Counter is Counting Rubbish
« Reply #3 on: May 02, 2019, 04:20:08 am »
HC has a maximum input slew rate, so make sure your inputs are nice and fast edges.

EDIT: Yep, your clock pulse is coming from an opto-coupler, that will be a creating a slow positive edge. Try reducing your pullup resistor value for starters.
« Last Edit: May 02, 2019, 04:25:52 am by EEVblog »
 

Offline floobydust

  • Super Contributor
  • ***
  • Posts: 7678
  • Country: ca
Re: 74HC390: Ripple Counter is Counting Rubbish
« Reply #4 on: May 02, 2019, 04:59:49 am »
I never leave unused 'HC logic inputs floating, like pin 1,2,4.
 

Offline EEVblog

  • Administrator
  • *****
  • Posts: 39026
  • Country: au
    • EEVblog
Re: 74HC390: Ripple Counter is Counting Rubbish
« Reply #5 on: May 02, 2019, 06:52:13 am »
I just shot a video on this question, editing now...
 
The following users thanked this post: LateLesley

Offline EEVblog

  • Administrator
  • *****
  • Posts: 39026
  • Country: au
    • EEVblog
Re: 74HC390: Ripple Counter is Counting Rubbish
« Reply #6 on: May 02, 2019, 09:40:51 am »
 
The following users thanked this post: brabus, Darkwing

Offline vk6zgo

  • Super Contributor
  • ***
  • Posts: 7855
  • Country: au
Re: 74HC390: Ripple Counter is Counting Rubbish
« Reply #7 on: May 02, 2019, 12:02:08 pm »
You could use a 4017 "Johnson Counter" instead, if you just want to divide by 10.
Looking at the spec sheet it says for rise & fall times: "unlimited".

I used one 30+ years ago in a project with an opto coupler, but on reflection, the opto was not clocking the 4017 direct.
That function was performed by a 555 in astable mode, which was, in turn, triggered on by the output of the opto coupler which was used to isolate the local power supply from the telephone line power.

When the device received a call, it would turn on the opto, starting the 555.
Ultimately, the whole shebang controlled an audio generator, which would perform a frequency response test of Broadcast programme lines on demand for staff at a remote site.
 

Offline DarkwingTopic starter

  • Contributor
  • Posts: 42
  • Country: de
  • Let’s get dangerous!
Re: 74HC390: Ripple Counter is Counting Rubbish
« Reply #8 on: May 02, 2019, 12:24:33 pm »
Wow, Dave, that's so amazing! I'm glad that I finally was able to contribute to the EEVBlog with my stupid questions. :D

I will follow up on this, presumably next week and I'll post results and my findings.

For now, quick info: the Fall Time of my signal is 396ns in average [274ns - 524ns]. So that alone seems problematic, very very slow.


Will keep you updated!  :)
Thanks so far!
 
The following users thanked this post: LateLesley

Offline EEVblog

  • Administrator
  • *****
  • Posts: 39026
  • Country: au
    • EEVblog
Re: 74HC390: Ripple Counter is Counting Rubbish
« Reply #9 on: May 02, 2019, 10:53:57 pm »
Wow, Dave, that's so amazing! I'm glad that I finally was able to contribute to the EEVBlog with my stupid questions. :D

Questions like these certainly are not stupid, they are the opposite, as you can see they actually lead to a lot of real engineering questions and things to consider and look at. There are even more than I put in this video.
This is why I hope people's projects fail, because you learn so much when you have to debug it.
 

Offline trophosphere

  • Frequent Contributor
  • **
  • Posts: 280
  • Country: us
Re: 74HC390: Ripple Counter is Counting Rubbish
« Reply #10 on: May 03, 2019, 04:36:57 am »
Quote from: Henry Petroski
Failure is central to engineering. Every single calculation that an engineer makes is a failure calculation. Successful engineering is all about understanding how things break or fail.
 

Offline wilfred

  • Super Contributor
  • ***
  • Posts: 1388
  • Country: au
Re: 74HC390: Ripple Counter is Counting Rubbish
« Reply #11 on: May 03, 2019, 05:44:36 am »
Wow, Dave, that's so amazing! I'm glad that I finally was able to contribute to the EEVBlog with my stupid questions. :D

Not only was the question not stupid you asked it very well. If more people took a leaf from your book forum questions would get better answers.  :-+

Putting in a bit of effort to describe the problem really makes people feel their effort helping will be worth it.
 
The following users thanked this post: EEVblog

Offline Brumby

  • Supporter
  • ****
  • Posts: 12413
  • Country: au
Re: 74HC390: Ripple Counter is Counting Rubbish
« Reply #12 on: May 03, 2019, 09:21:21 am »
I'll add my voice to the "not a stupid question" chorus!

In fact, some of the most stupid questions are the ones that didn't get asked.


Putting in a bit of effort to describe the problem really makes people feel their effort helping will be worth it.

Very true.  It demonstrates the question (and the person putting it) are fair dinkum.
 

Offline LateLesley

  • Frequent Contributor
  • **
  • Posts: 322
  • Country: scotland
Re: 74HC390: Ripple Counter is Counting Rubbish
« Reply #13 on: May 03, 2019, 10:21:06 am »
i'll add to the "not a stupid question" crowd. I was once told, "The only stupid question, is one you already know the answer to."

As for the problem, I wonder if we are actually seeing intended behaviour?

If we follow the sequence :-
    Q3 Q2 Q1 Q0
0 - 0  0  0  0
1 - 0  0  0  1
2 - 0  0  1  0
3 - 0  0  1  1
4 - 0  1  0  0
5 - 0  1  0  1
6 - 0  1  1  0
7 - 0  1  1  1
8 - 1  0  0  0
9 - 1  0  0  1
10 - this is where it resets to 0, as it''s a decade counter.

So as you can see Q1 Q2 and Q3 won't divide into perfect square waves, as there times when they are off for longer. like Q1 for 8,9,0,1 it will be off, giving a longer gap in the waveform. The same applies to Q2, it's off for 6 counts, but on for 4. So I would actually count out each step, and see if you are seeing intended behaviour for that chip.

 
 

Offline NivagSwerdna

  • Super Contributor
  • ***
  • Posts: 2507
  • Country: gb
Re: 74HC390: Ripple Counter is Counting Rubbish
« Reply #14 on: May 03, 2019, 10:35:10 am »
The rabbit hole goes deep... http://www.ti.com/lit/an/sdya009c/sdya009c.pdf  Section 5 has a nice table of the different families wrt rise times and how mixing them can ruin your day.

And there is always more than one way to skin a cat... Either a counter with a Schmitt input trigger input or.....

.. an opto with an inbuilt Schmitt trigger output e.g. H11L1M or NTE3090 ?

When is DaveCadCon?  I'll buy a ticket. Nice to see FUNdament Friday's are back.  Great video.
« Last Edit: May 03, 2019, 10:37:36 am by NivagSwerdna »
 

Offline EEVblog

  • Administrator
  • *****
  • Posts: 39026
  • Country: au
    • EEVblog
Re: 74HC390: Ripple Counter is Counting Rubbish
« Reply #15 on: May 03, 2019, 10:41:58 am »
i'll add to the "not a stupid question" crowd. I was once told, "The only stupid question, is one you already know the answer to."

As for the problem, I wonder if we are actually seeing intended behaviour?

If we follow the sequence :-
    Q3 Q2 Q1 Q0
0 - 0  0  0  0
1 - 0  0  0  1
2 - 0  0  1  0
3 - 0  0  1  1
4 - 0  1  0  0
5 - 0  1  0  1
6 - 0  1  1  0
7 - 0  1  1  1
8 - 1  0  0  0
9 - 1  0  0  1
10 - this is where it resets to 0, as it''s a decade counter.

So as you can see Q1 Q2 and Q3 won't divide into perfect square waves, as there times when they are off for longer. like Q1 for 8,9,0,1 it will be off, giving a longer gap in the waveform. The same applies to Q2, it's off for 6 counts, but on for 4. So I would actually count out each step, and see if you are seeing intended behaviour for that chip.

But we aren't seeing that on the scope. It is supposed to be exactly like the timing diagram.
 
The following users thanked this post: LateLesley

Offline MrAl

  • Super Contributor
  • ***
  • Posts: 1666
Re: 74HC390: Ripple Counter is Counting Rubbish
« Reply #16 on: May 03, 2019, 12:03:31 pm »
Hello there,

The output from an opto coupler has very slow rise and fall times unless it is made specifically for digital logic.
As the output ramps up during the rise time, it eventually gets close to the threshold voltage of the logic gate input and then the always present noise can go above and below the threshold voltage several times before the ramp finally gets high enough to overcome the noise completely and then provide a stable logic state.  Before it gets past the noise it can clock a counter several times or just a few times just on that one rising or falling edge alone, and that will mean we will see a varying response from the counter chip which means we get garbage out.

This is a very common problem even for circuits that dont use opto couplers.  Many types of signals are slow rising and falling and so they need to be cleaned up before presented to any type of logical counter.  Typically we see a Schmitt Trigger gate being used for this purpose.  These kinds of gates have a wider threshold region which means the noise gets lost in between the upper and lower threshold voltage levels.  This means we get a nice clean digital signal out of the gate which means the clock input to the counter gets a nice clean signal.  After that everything works as expected.

Alternately you could look for an opto coupler that has a digital output that is made for the digital logic family you are using.
 

Offline MikeMike

  • Newbie
  • Posts: 1
  • Country: us
Re: 74HC390: Ripple Counter is Counting Rubbish
« Reply #17 on: May 03, 2019, 05:39:33 pm »
Noticed that the optocoupler data sheet says "A 0.1μF bypass capacitor must be connected between pins 8 and 5" (aka Vcc and GND). Doesn't appear to be one on the breadboard. Adding one might help.
 

Offline donmr

  • Regular Contributor
  • *
  • Posts: 155
  • Country: us
  • W7DMR
Re: 74HC390: Ripple Counter is Counting Rubbish
« Reply #18 on: May 03, 2019, 06:00:50 pm »
Reducing the pullup will speed up the rising edge, but it will also slow down the falling edge!  A schmidt trigger is the right answer.

Dave also didn't address the series 270 ohm resistor.  You don't want that.
 

Offline Peabody

  • Super Contributor
  • ***
  • Posts: 2245
  • Country: us
Re: 74HC390: Ripple Counter is Counting Rubbish
« Reply #19 on: May 04, 2019, 01:22:29 am »
The thing to do is to leave the HC390 circuit exactly as it is, but drive the input from a good, fast signal, and see if it still misbehaves.  Well, that's what I would do.
 

Offline DarkwingTopic starter

  • Contributor
  • Posts: 42
  • Country: de
  • Let’s get dangerous!
Re: 74HC390: Ripple Counter is Counting Rubbish
« Reply #20 on: May 09, 2019, 04:55:23 am »
Alrighty then, I have news! :)
I read all of your comments, first of all: thanks!
I sat on the breadboard again and: I made it work.  :-+

But step by step.

Here is what the status quo was: I captured (with 500ms persistence time) the signal from the HCPL3700 optocoupler (1) and the first counting pulse (2) it triggered in the CD74HC390 counter … and as you can see: this is garbage. Wild jumps on the logic level, no wonder that the counter produced such a weird looking pattern. The rising edge is somehow ringing, maybe that's why sometimes it was interpreted as an additional falling edge by the counter IC.



Here is a capture of the rising edge – this was with 2,2kΩ as a pull-up on the optocoupler and 220Ω as a "pin protection" on the counter:



And here is the falling edge of that signal:





I then tried some other optocouplers: 6N138 and ILD620GB – with an even more terrible Fall Time.

6N138:


ILD620GB:




I discarded that and switched back to the HCPL3700. And I was able to clean up my signal. I simply used 100k as a pull-up and connected the optocoupler's output directly to the clock input of the counter. So I use a much higher value now as a pull-up, not a lower one. I don't know why I used the 220Ω resistor as a pin protection in the first place. Guess I had this in my mind from some Arduino tutorials ("Protect your pins! Never connect something directly to the pins or the current will destroy it!" Stuff like that ...).

I also decoupled the optocoupler now on pins 5 and 8 with a 0.1µF capacitor like the datasheet suggested. It made a liiiiittle difference, but not much. I also grounded the unused pins of the CD74HC390 counter. It made no noticable difference.



And now the signal looks like this – the rising edge:



And the falling edge:



Much more clean! But it did not want to work. Still counting rubbish.

So I decided that it is now time for some zeriouzz Schmitt action! For this, I first moved the optocoupler on the breadboard a little bit away from the counter IC, to make some space for a Schmitt trigger IC. But before installing it, I measured my optocoupler's signal again: lo and behold!, it was even better and now the counter triggered correctly! My pulse signal is divided by 10:



(My scope is of course not a 5-channel one – I photoshopped that for you.  ;D)

This is what you would expect it would look like – but I couldn't believe this. So I switched back and forth and back and forth the position of the optocoupler on the breadboard. Sometimes it seemed to work, sometimes there were some small glitches on the scope, but after all the dividing was correct. So I can only assume, that a mixture of signal quality and bad connnections on the breadboard or the fact alone that I use a breadboard is all part of the problem. I have no clear explanation for this behavior, but I wouldn't trust this arrangement.

So back to the Schmitt! I tried two different Schmitt triggers: the SN74HC14N and the CD40106BE:

SN74HC14N – Fall Time ≈12ns:



CD40106BE – Fall Time ≈27ns, but cleaner signal:



Side quest: Why is it that with the SN74HC14N (a CMOS device) the signal is faster but more jittered? With the CD40106BE (also a CMOS device), for me it's fast enough, I have clean levels and edges and it works very reliable so far. This means: I'm happy and we solved the problem.  :clap:


So here it is: my little optocoupled, Schmitt-triggered, AC pulse divider:





With it I'm dividing the 50Hz mains frequency (Europe) to a 1Hz signal. The LED flashes every second. This was the goal for this project.  :phew:


I hope this was insightful for someone, especially for the beginners who don't own a scope yet, to better understand and see "the inner workings" of all this stuff in more detail. I remember, back in the days, when I was scopeless, I would have wished for some real world pictures and explanations like this.

You're welcome to add, comment, suggest and recommend to this learning project.  :)


Thanks y'all!  :) 8)
 
The following users thanked this post: LateLesley

Offline Brumby

  • Supporter
  • ****
  • Posts: 12413
  • Country: au
Re: 74HC390: Ripple Counter is Counting Rubbish
« Reply #21 on: May 09, 2019, 05:40:45 am »
Congratulations on success - and having learned some important lessons along the way (I picked up a couple of things.)


One point:
I also grounded the unused pins of the CD74HC390 counter.
Only ground the unused INPUT pins.  Grounding outputs could cause you other problems.  Input pins are looking for a signal, so grounding these makes that signal stable and known.  Output pins aren't looking for anything.  Their level is set by the function of the chip.  Best leave the chip to set these - leave them disconnected.

Quote
It made no noticable difference.
Quite often this is the case, but it is good practice.  One day you might have a circuit that is susceptible and if you don't ground unused inputs, you might be chasing your tail for a while until you remember this advice.
 

Offline schratterulrich

  • Regular Contributor
  • *
  • Posts: 50
  • Country: at
    • Elektronik & Layout
Re: 74HC390: Ripple Counter is Counting Rubbish
« Reply #22 on: May 09, 2019, 07:18:21 am »
To your side question:

The faster the signal, the more important the correct probing technique becomes.
If you use a ground lead with your probe you can try to roll it up. If the signal changes even a little, you have found the problem.
 

Offline mikerj

  • Super Contributor
  • ***
  • Posts: 3382
  • Country: gb
Re: 74HC390: Ripple Counter is Counting Rubbish
« Reply #23 on: May 09, 2019, 07:41:36 am »
To your side question:

The faster the signal, the more important the correct probing technique becomes.

And also the more important supply decoupling and a solid low impedance ground becomes.  This is why fast logic devices and breadboards are a bad mix.
 

Offline schmitt trigger

  • Super Contributor
  • ***
  • Posts: 2431
  • Country: mx
Re: 74HC390: Ripple Counter is Counting Rubbish
« Reply #24 on: May 09, 2019, 04:11:13 pm »
Good job!  :-+
A good reason for beginners to use CD40xx logic is because it is very forgiving. Specially if your clock frequencies are below 1 Mhz.
Now you know.

 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf