Author Topic: 74HC595 noise(?) problems  (Read 4147 times)

0 Members and 1 Guest are viewing this topic.

Offline rhdfTopic starter

  • Contributor
  • Posts: 44
  • Country: se
74HC595 noise(?) problems
« on: April 20, 2016, 10:15:29 pm »
I have a prototype consisting of several sub-circuits
One dual state variable filter where I use a CD4053 and 2 CD4052 for selecting mode and do some routing. These are controlled by a 74HC595
The control voltages comes from a 12 bit dac
and finally a control panel with 2 74HC165 and a HC595

To test them I use a old netduino I had laying in a drawer... Quick end easy way to write some code and see that things do what they are supposed to do.
Testing the parts one by one works fine, but when I connect more than one things gets interesting.

They all share the same SPI-pins but have separate latchpins.

As an example.
The control panel have 7 buttons with a corresponding LED and 2 encoders. Buttons and encoders hooked up to HC165:s and the leds to the HC595. Having only this connected everything works fine. The right LED lights up on buttonpress and i get data from the buttons and encoders. This one is built on protoboard with a 10-pin IDC connector (a gnd-wire between the datawires)

When I hook up the DAC or the HC595 on the filterboard all the leds goes "full disco" and even reacts when I turn the encoders. Obviously something makes the 595 clock/latch  garbage. I still get correct input.

Actually I don't even have to hook up anything else  on the SPI. If I take the 5V and GNG from the netduino and plug it in to a breadboard and then back to the controll-board I get the same result more or less..

I can live with the blinky lights (well for a while) on the controllboard, but the big problem is that the 595 controlling the filters doing the same thing witch means that the filter jumps between modes and routing randomly.

TL;DR
How do I get rid of the noise on a shared SPI-bus

 

Online tggzzz

  • Super Contributor
  • ***
  • Posts: 19510
  • Country: gb
  • Numbers, not adjectives
    • Having fun doing more, with less
Re: 74HC595 noise(?) problems
« Reply #1 on: April 20, 2016, 11:09:42 pm »
How do I get rid of the noise on a shared SPI-bus

Noise is heavily dependent on the details of the construction techniques used, and you haven't provided any information about that.

I doubt your problem is "noise". I suspect it is "signal integrity", which is a standard problem with solderless breadboards.

At the very least ensure you have good decoupling capacitors, and that you minimise the inductors in your circuit. (A piece of wire is 1nH/mm, then do back of the envelope calculations induced voltage V=Ldi/dt and resonant frequency f=1/(2*pi*sqrt(LC)) )
There are lies, damned lies, statistics - and ADC/DAC specs.
Glider pilot's aphorism: "there is no substitute for span". Retort: "There is a substitute: skill+imagination. But you can buy span".
Having fun doing more, with less
 

Offline rhdfTopic starter

  • Contributor
  • Posts: 44
  • Country: se
Re: 74HC595 noise(?) problems
« Reply #2 on: April 21, 2016, 12:16:57 am »
All my sub-circuits are on protoboards and all IC:s have decoupling caps.

yes breadboards are bad. (sort of). At the moment I use them as "switchboards" while tinkering and thinking about how to connect stuff together.

The final design of the control-panel will probably be a couple of separate PCB:s  connected with flat-flex
Mainly because
1) a single PCB would be ridiculously expensive
2) I still want to have the  possibility to change parts of the button/encoder placement without having to re spin the whole thing
3) A big portion of that PCB would be empty space

In the meantime what I'm probably looking for is what is recommended for having decent signal integrity both now and later on the real setup

I've seen recommendations to have pull-downs on the clock/latch pins, termination on the last component in a chain etc. But when i look at schematics for a lot of stuff I do not see anything of this

 

Offline T3sl4co1l

  • Super Contributor
  • ***
  • Posts: 21687
  • Country: us
  • Expert, Analog Electronics, PCB Layout, EMC
    • Seven Transistor Labs
Re: 74HC595 noise(?) problems
« Reply #3 on: April 21, 2016, 02:51:39 am »
Well, you don't see it on schematics because either "it just worked", or they didn't need it anyway, or they didn't bother to write it down or put a hack around it or so on.

Logic pin drivers for 3.3 and 5V chips are on the order of a few nanoseconds risetime, so you can easily trash signals on wires more than a few 10s of cm.  Especially so if the wires are flying willy-nilly through space, without any ground pairing, or termination or damping.

The most fundamental principle is this:

1. Whenever you have a signal, have a ground close by.  Preferably, have that ground closer than the next signal, and so on.

For signal quality and RF purposes, "ground" is any signal or supply that is bypassed to common.  Thus, VCC is usually included, but other signals might also happen to be handy, if they are slow and bypassed (an ADC thermistor input, with capacitors on either end, might be such a beast).

Perhaps the most common misunderstanding in applying this is:

2. Signal bandwidth is NOT clock frequency or pulse/data rate.  Signal bandwidth is risetime.

It doesn't matter if you're toggling a pin at 1kHz or 1MHz; in both cases, you can get ~ns range bounce on the edge.  And if you do, every time the bounce crosses the input pin's logic threshold, you get extra transitions.  Put that on a clock pin and your data goes byebye.

Which leads into two other important observations:
- Circuits don't know your intent.  No one has invented an intention detector circuit.  The circuit simply is what it is. If you've set it up in a way which you did not intend... that's your misunderstanding. ;)
- Circuits's gonna do what a circuit's gonna do.  Whether you can measure it or not.  A 20MHz oscilloscope won't detect any problems -- basically by definition!  But the input pins reading that level can respond to signals in the 100MHz range.  So you either need the equipment to verify that the signals are going through correctly, or limit the bandwidth (by filtering) to the point where you can verify it.

3. Only use the minimum bandwidth you need for the application.  Filter the rest.

There are a great many applications out there, but some examples might include:
- Digital logic input, low bitrate (terminal block inputs, RS232, etc.?)
- Digital logic input, high bitrate (often differential too, e.g. RS422, USB, LVDS, etc.?)
- Analog input, slow (e.g., thermistor sense, audio amplifier?)
- Analog input, fast or high-impedance or high-precision (e.g. oscilloscope?)
- Radio signals (limited bandwidth)

For each of these, you're only concerned about some range of bandwidth.  Many of them include DC, so you don't want to filter that. (Digital pins that need to be static (stable at DC) can't be AC-coupled.  Some signaling methods get around this, like Manchester encoding on 10BASE-T Ethernet, which is transformer coupled and extremely robust!)

The upper frequency limit is defined by your filtering: almost always, never by your naked circuit.  The most offensive example of this: an audio amplifier, with skookum low noise bipolar op-amps, that beeps like an alarm clock every time your phone is about to go off!  Indeed, that's the cause and solution in one: GSM phones emit powerful radio pulses, and bipolar op-amps typically rectify and detect this.  Even though the 900MHz+ noise is well beyond their normal operating bandwidth (which is a minimum 20kHz for audio, up to a few 10s MHz for the GBW of typical op-amps).

So one lesson is, just because a part lists a few frequency cutoffs (like fT or GBW or -3dB point or...), doesn't mean it doesn't respond to anything above there!  A trivial example is a photodiode, which responds to 300-600THz radiation (visible light), yet has a useful bandwidth of neither 300 nor 600THz, but perhaps a few MHz.  Bipolar op-amps do the same thing, where they detect (in a square-law or diode-rectifying manner) ambient RF, most often these days from mobile phones and Wifi.



For your most common situations, you can filter away gross swaths of RF interference (whether it's from a nearby phone, or generated by output pins in your own circuit) by adding series ferrite beads or resistors, and parallel capacitors (to ground).  For digital (CMOS) circuits, it's often enough to simply add a series resistor, at each output pin, usually 100-1000 ohms.  This will likely solve your present SPI problem, but now you know a bit more about why.



For terminals exposed to the scary outside world, transient protection (ESD or surge) is also necessary.  These are applied in precisely the same way: series current limiting, and parallel voltage limiting, components.  Instead of reducing bandwidth, you're reducing the voltage and current levels to a kind range.

Tim
Seven Transistor Labs, LLC
Electronic design, from concept to prototype.
Bringing a project to life?  Send me a message!
 

Online tggzzz

  • Super Contributor
  • ***
  • Posts: 19510
  • Country: gb
  • Numbers, not adjectives
    • Having fun doing more, with less
Re: 74HC595 noise(?) problems
« Reply #4 on: April 21, 2016, 07:24:14 am »
In the meantime what I'm probably looking for is what is recommended for having decent signal integrity both now and later on the real setup

That information is widely available in manufacturer's application notes and across the web. Starting points are "Howard Johnson" and "Bogotin's Rules of Thumb", "ground bounce", "transmission line reflections", and T3sl4co1l has given a useful indication of the root cause of the problems.

Signal integrity is vital in analogue circuits - and make no mistake your circuits are analogue, even if the analogue signals are "interpreted" by the receiver as being digital.

The only really digital circuits I'm aware of are photon-counting applications and femtoamp circuits; what have I missed?
There are lies, damned lies, statistics - and ADC/DAC specs.
Glider pilot's aphorism: "there is no substitute for span". Retort: "There is a substitute: skill+imagination. But you can buy span".
Having fun doing more, with less
 

Offline T3sl4co1l

  • Super Contributor
  • ***
  • Posts: 21687
  • Country: us
  • Expert, Analog Electronics, PCB Layout, EMC
    • Seven Transistor Labs
Re: 74HC595 noise(?) problems
« Reply #5 on: April 21, 2016, 09:16:17 am »
That information is widely available in manufacturer's application notes and across the web.

Eh... as I've said before, appnotes rarely give any care about signal quality or EMC.  The ones that talk about it specifically are usually okay, but most devices that require good signal quality, don't tell you about it.  And when they do, they've got it completely upside down (e.g., USB connector with ferrite bead to shield!).


Quote
The only really digital circuits I'm aware of are photon-counting applications and femtoamp circuits; what have I missed?

Digital is a state of mind; an assumption only made possible by very specific conditions.  Digital is always a subset of analog.  Usually you don't have to worry about trace lengths within an IC, so you can design an IC using digital rules (gate propagation delays and such).  As soon as signals enter the PCB, they're back in the analog domain, in any number of formats: TTL, CMOS, ECL, LVDS, CML, etc.  Digital signals are assumed to have instantaneous transitions (and no consequences from that!), but all real signals have finite risetime (and have real consequences!).

Quantum physics is kind of digital, but that, too, is belied by subtlety: the wave function is a probability space, and a superposition or entanglement of states is an analog continuum between those digits.  The events may be discrete (like photon counting), but their probabilities aren't (consequently, a photon counter will inevitably be subject to occasional pairs (or more) of photons coming in too quickly to detect all of them).

Tim
Seven Transistor Labs, LLC
Electronic design, from concept to prototype.
Bringing a project to life?  Send me a message!
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf