Electronics notes/Knobs and dials
Potmeters
Variable resistors (see potmeters), many of the ones with a knob are single-turn, meaning they go though their resistance range in usually at most 300 degrees of rotation.
This makes them useful as absolute-position rotation sensors.
Not overly accurate ones, but cheap and fairly durable.
Rotary/linear encoders
Incremental encoders, a.k.a. Relative encoders (only) report/detect change in position, from which you can calculate direction and speed. ...assuming you're sampling fast enough to not miss transitions.
The idea behind incremental encoders is roughly that they're seeing two things 90 degrees out of phase
One way is to use a a quadrature encoding disc.
You read these out with two sensors at the same angle (e.g. the red bar in the image on the right is two sensors).
You can detect speed based on how the rate of state changes.
You can detect direction based on the sequence (which one leads the other).
There is a variant of this idea in which the wheel has a series of single slits, and sensors offset less than(verify) half the slit distance, which effectively has a response very similar to a quadrature disc.
This is effectively the same in terms of what you do with the output. This is seen in mouse scrollwheels (and opto-mechanical ball mice before that) work.
As-is, relative encoders are useful for things like menu navigation, where only direction and speed (but not absolute position) matters.
It is also one way to sense speeds.
Absolute encoders report their actual position, from which you can then infer direction and speed.
You could intuit these as encoding their position as an integer, but they're actually Gray code, more useful in this context because it lets you detect and potentially correct successive values that don't make sense after the last - making any correction circuitry simpler (consider e.g. what is read during a transition).
Virtual absolute encoder (TODO)
Optical encoders
Magnetic encoders
Readout
In terms of electronics or code
Resolver
https://en.wikipedia.org/wiki/Resolver_(electrical)
Considerations when using switches as input
Button input isn't logic input (by itself)
Logic output to something else's logic input is potentially just wired output-to-input
- ...with some footnotes like
- the voltage level should be the same
- sharing ground must not cause issues).
- with some though to impedance and the currents that might set up
Switches themselves either short a circuit (low-impedance), or an open circuit (high impedance, if you prefer).
Shorting it to some voltage within that same circuit would be a well defined voltage, but the open case still essentially a floating input (meaning that in that state there is nothing to pull whatever is sensiting it to a stable state, so probably the tiniest electrostatic effect or EMI/RFI around might influence it (more so if the traces are longer because what we have made is a crude antenna)).
This is why e.g. Arduino button example requires a resistor:
it means to pull the open state to another well-defined voltage.
There are some details to that - for more context and footnotes, see e.g.
- pullup/pulldown resistor.
- floating inputs for more context and footnotes.
Bouncing
The mechanics in most switch designs means when you change them to their other state, their contacts will have some time of moving, and some time of uncertain contact.
In clickier switches, that bounce is more literal: you throw a spring-loaded thing around, which tend to arrive with some energy, bounce, then settle once that energy is lost in the physics.
That intermittent mechanical contact is mirrored in the electrical contact, so amounts to (sometimes very) fast electrical switching (capacitance and input impedance, and more things to say about the details).
A different but related effect, seen e.g. in the cheapest doorbells where you're grinding two metal plates together,
is that they will continue to make intermittent contact as you move your fingers.
Also because they're more likely to be a little corroded.
...and once you include such not-quite-bounce effects, also consider dirt, smoke, corrosion from moisture, and other things like it will also affect contact behaviour over time.
We might call all of that electrical bounce, in part because we can resolve potential issues in a similar way (often called debounce).
It turns out something as simple as buttons can be an engineering design question, for mostly stupidly practical reasons.
You can easily see dozens of bounces in a millisecond - which is moderately high frequency switching - can be kHz range.
Results we're avoiding
We want to avoid responding to every bounce
- From a user perspective, we want to avoid multiple registration of what we think of as one event
- this might be more about counting correctly
- and not wanting it to re-trigger when a dirty contact moves a little
- From an electronic perspective of feeding this signal to something else - often turning else on or off (be it a signal line or device), we want that other piece of electronics to switch once, not for each of these bounces (because individual contact bounces can in some cases happen at nanosecond scale)
- when that something else is capable of responding to each of these things (e.g. interrupts) or is not well defined what it would do (an uC's power line) this can cause some behaviour you are really not expecting - even if it is technically correct response to the input (e.g. many logic ICs are perfectly happy switching at dozens-of-nanoseconds scale)
Note that rate limiting, in the general sense of "once I decide to trigger, I will not decide trigger again again within the next X time", addresses most of that -- but there are other requirements, so let's get to details later.
Less receiving of transient noise
- in EM-noisy environments, you can assume you will sometimes receive some induced noise even when nothing happened on the contact itself
- it's not the main issue we're solving, but it can make sense to solve this in the same way
- sometimes also for practical and/or safety reasons - you don't want an emergency off button to trigger accidentally when someone uses a funny device nearby (and if 100ms of checking (and time delay) solves that, great)
Less emitting of transient noise
- whenever switching current on a wire, you have also made an antenna, and you will be the cause of EM noise nearby
- also to other parts of the same device, because those parts are close
- it could become a certification issue.
- generally not so pronounced until you're switching more than a little current
Problems we might introduce
delayed reponse
- most debounce methods come down to "hang on, I'm checking whether that change looks consistent enough",
- which will almost necessarily introduce a delay.
- when spurious triggers are a larger problem than a small delay, that is perfectly solid idea.
- Such a delay also usually rate-limits how fast that output can switch, which is often part of the idea (it solves the 'many-registration')
- sometimes this is more of a side effect, sometimes the delay and rate were more specifically considered in design.
delay or noise causing you to ignoring real triggers
This one depends a lot on how you implement it.
- Say you implement "when I see an edge, I sample 50ms, and decide it's real if more than 75% of that is pressed sate; once that is done I start again".
- Say you see 40ms of pressing with a little bounce. It gets seen as a real press, just once. Great!
- Next case. Say you se a quick transient, and 30ms after that you measure 40ms of pressing (even just pure non-bouncing).
- That transient starts our sampling, so the first 20ms of that 40ms press fall into that sampling period, but is not enough.
- we start again and immediately see it pressed and start a sampling window, but only the last 20ms of that 40ms press falls into this, and is also not enough.
- Congrats, we just completely ignored 40ms of perfectly good press
- That particular problem is solved easily enough (e.g. continuous sampling in a ringbuffer of sorts, which you probably zero out on a press decision), but you do have to think about it.
- More simply, if your method needs some time to react and/or reset, then there is a time in which a next real press is not measured just yet, and might get ignored
And there are further edge cases we could think of.
If I want to debounce, what can we assume?
Well, bounce images like the above look clean for lab-condition and cherry-picking reasons, but in the real world
- there are different kinds of buttons,
- there are different sizes of buttons,
- there are capacitive effects,
- there are sampling impedance details,
- temperature and humidity may change these properties a little
- the contacts will oxidize over time,
- the contacts will pit if arcs happen (when they control power),
- there are details to how e.g. logic-level interpretation sees this signal
Point being made:
Not all environments are created equal,
you rarely control all the details
and quantifying this is hard.
So even if you fix it very precisely for a specific switch, wire, and circuit today, exactly the same may fail to work in another device, relocated, or a year from now.
Different combinations of input impedances, and what you connect,
also work out as different amount of sensitivity to EM.
- microcontroller pins tend to have impedance somewhere between 100k and 1MΩ (verify)
- the pullup/pulldown impedance may be specced differently. E.g. AVRs seem to be between 20k and 50k, RPi between 50k and 60k (which can be more sensitive to EMI).
- so you might wish to use / add your own pullup/pulldown of 10k or less.
Not all switches's bounce is created equal
Mechanical differences
See also the debouncing-method plot below - already shows some different delays and contact patterns from different buttons under test
The mechanics of specific switch/button design ends up mattering.
Some types of switches bounce more than others.
For example, a classical doorbell maybe bounces less, but may also have imperfect contact while you hold it (looks like fast switching), which you would also call bounce. It may be faster than some alternative, but also less predictable - and this will change over time as the contacts corrode.
For the same design, smaller switches may bounce less.
On the other hand, something with a click, like a microswitch, will probably bounce a little longer but is effectively more stable in each state even though it is functionally as momentary as the doorbell-style pushbutton.
Bounce timespan
For context, the mechanics of most switches depend on their size, and type.
Individual bounces may take e.g. 100 nsec.
Small latching switches tend to settle within 10 or 20ms, and most of the mess may happen within the first few one or two milliseconds.
Larger switches may be messy for longer, and take longer to settle.
You may like to see what that looks like when sampled, like the image on the right, though again, the details will vary with mechanics and size.
Also keep in mind that capacitive effects will change the shape of that - traces like this are often lab-conditions with reasonable pullups/pulldowns, and high input impedance (because oscilloscope).
Disconnecting contacts tend to be less messy than newly made contacts
I had both cleaner and dirtier variants of that yellow-leaving part (and this is a fresh switch, it might be a little worse if corroded/arced with use).
The vertical offset between the traces is artificial, for visibility.
The horizontal distance is real, a ~1.5ms difference between the two contacts's actions.
In various switch designs, breaking a contact tends to be cleaner than making the same contact.
Intuitively, consider momentum-like reasons: if a contact gets flung by a spring-like thing, there's more energy in movement to waste at the end of that movement than at the start. It may still have a scratchy start, though, so it's not perfect.
The oscilloscope traces on the right are from
a non-latching pushbutton (which is still fairly clicky, and stable on both sides),
that has both normally-open and normally-closed contacts (alternatively, seen as SPDT).
The first image is from when it is pushed in, the second when it is released. You can see that in both cases, the action of leaving is cleaner.
So if you can have a contact-breaking solution, it helps. ...but only so much.
For one, the actual physical contact of a switch still depends with the physical design of that switch. This happens to be a fairly clean case, others are not.
Also, these two images are absolutely cherry-picked. Even this fresh, never-saw-an-arc button also had dirtier traces for releasing contacts (though still not nearly as messy as arriving contacts).
So sure, debouncing a contact break may be simper and faster - but if you think you have to do little or no debouncing,
then you or your clients will be rather unhappy some time later.
(...and yes, there is delay between the two, which is mostly just physical travel between the contacts - think of it as a SPDT switch. It was roughly ~1.5ms for this switch and how I pressed it. )
Doing debouncing
Debouncing in hardware - SR latch
Debouncing in hardware - RC circuits
Upside:
- cleans up the electronic signal before you feed it into something that cares
Limitations:
- takes some components, which might not be your only or easiest option
Debouncing in circuits usually comes in one of two flavours.
One is down to a filter (usually RC filter) and a threshold.
You can think of it as a capacitor charging slowly towards the new levels. If there are a lot of transients in the bouncing, this charge may be a little slower, but it will reflect what is mostly happening.
Design-wise, you would find the button's bounce time, then figuring out a filter where that time is roughly 3RC is probably pretty solid
(in the image on the right, the circuit is slower than that, and might benefit from a smaller capacitor).
You can do faster, yes, but you may want to be a smallish factor more pessimistic - if you don't know what will get connected to your input, or what temperature or humidity might do, then pessimistic means slower but stabler).
If you have a comparator without hysteresis, then there is a relatively specific voltage at which it switches, and voltage noise right around that time might still cause some fast switching around then. This is a smaller, but real problem.
Also, consider that if you feed such a slowly changing voltage to a logic input that specifically wants a sharp edge to react to,
it will not get one.
This too isn't common, but can be real.
Both of these are things that a Schmitt trigger as the next component can help.
In the image above that mostly happened when it was still relatively high voltage, but if you tweaked it to be faster, that would be a larger risk - even with a Schmitt trigger.
Debouncing in software
Software debouncing is also variations the idea that a button would be in actuated state most of some recent time before the debouncer actually considers it changed.
For example, the most basic arduino debounce code essentially just samples twice, typically 25ms or 50ms apart, and effectively says "if the last two samples are high, output is high" (assuming non-pressed is low, pressed is high).
This feels like cheating, but consider:
- two random samples in mostly-non-actuated are unlikely to both be high (even with moderate EMI)
- two samples during a actually-pressed bouncy transition are still only moderately like to agree
- if pressed, you often get either one sample within transition and one settled, or two settled, and both work decently (with some difference in delay between those cases)
Upsides
- the likeliness that both sample high when the button is pressed is nonzero, but usually are or can be made be made very low (and there are ways to lessen the EM noise issue)
- so works quite well for something so simple and CPU-cheap to implement (does not need to wait, sampling a GPIO takes order of microseconds(verify))
- the larger the time, the more that you limit fast oscillation (because you only change your decision slowly), and the less likely it is to oscillate overall (most switches will be stable after a while)
Limitations:
- the more stable you want it, the slower it needs to be, and the converse:
- becomes somewhat more fragile if you lower the interval too far (limitation determined by the mechanics of the switch)
- we don't know about the first edge, we just sample at a random time - so it's not the fastest or most consistent method anyway
- fragile around significant EM noise (mostly because high impedence sensing is sensitive)
- regularly a somewhat lower-valued pullup/pulldown is a decent workaround, though this takes some consideration of the circuit
Another method is to sample more frequently, count up when pressed, count down when not, and use a threshold
- can be made to react a little faster than the previous method, because you might notice a consistent on a little sooner
- has its own tradeoff between speed and robustness - but this is more gradual (how fast to sample, how high to count) and tweakable (e.g. counting up faster than down biases it a little faster).
- can still oscillate if the whole manages to float around that threshold. This is fixable with some intentional hysteresis
Notes:
- each method can be tuned somewhat for speed
- The more often you can sample, the surer you can be within a shorter timespan - e.g. if you sample every 100us then you can probably be certain in 1ms, if you can sample every 4us then you might be certain enough in 50us
- some implementations can be bias to one way (e.g. a pushbutton is considered non-pressed until it's fairly consistently on)
- but beware of variants of that code that will effectively debounce in one direction but not debounce in the other, because that may have different implications
TODO: write up a fuller explanation, including common avoidable mistakes
Example of software-debounced results
A few different switches and buttons, sampled fairly quickly, and debounced.
The following also tries to illustrate that different kinds and sizes of switches may have different bouncing behaviour (though fails to show the effect of things like corrosion - the pushbuttons seem good now but are more likely to become worse over time):
The colors:
- Blue lines and blue fill indicate the raw button state, which is boolean, because it's read with digitalRead (itself effectively a thresholded version of varied voltages but on a very short timespan)
- The yellow fill is debounced with the simple interval method, "it's high now and it was high X amount of milliseconds ago" (evaluated with that same amount of millisecond interval, which is part of why this is also fairly stable output-wise - but also comes at a random time after initial event at least in this implementation)
- The purple line is debounced with the counter method, showing the increasing counter with a purple line, and a purple fill once it's above the (somewhat low) threshold.
Note that both methods would absolutely still flip-flop fairly quickly (or, on the other hand, act relatively slowly) if tuned wrong.
In this example they are bouth tuned to the smallest value they won't flip-flop at. Which is cheating for faster reaction time given this particular data - in general you usually want to trade away speed, for more more robustness. And, not unimportantly, methods become more comparable speed when you do that.
Don't put too much stock into the types of switches - these are specific (cheap) models within each typ.e
Asymmetric debounce
Asymmetric debounce refers to handling the press and release in different ways.
And yes, most debounce as described is asymmetric,
in that most of the above has described us carefully delaying the press, while not really thinking about the release much (and rate limiting is implied from that press-delay). (we barely even mentioned rate limiting further via a "don't release or re-arm until X time after the last debounced trigger")
The term 'asymmetric debounce' seems to come up when you are thinking about both press and release behaviour in more detail.
...or perhaps more commonly, when you bias in the other way.
Consider the plot above again. Even the worst case, the footpedal, already had chunks where there were multiple consecutive samples of 'pressed'.
Couldn't you respond to the very first change-of-enough-consistency (for some definition of enough), so that we can react as soon as possible.
- ...and then probably delay the release, so that we can have the rate limiting as well?
You can.
But things get specific.
You probably need to sample fast enough that you will get multiple such consecutive samples, ideally a handful, so that EMI is seen as transient.
Such tradeoffs might be somewhat specific to a button, and done poorly it might even blind us to presses in the next "no presses here" window, though such details can be overcome by thinking about it enough.
Perhaps the prohibitive part is that you need to spend a lot more time paying attention to the input than before. I have seen solutions with a microcontroller sample very quickly', e.g. at tens of thousands times per second each (which can push the reaction time to well under a millisecond).
At the cost of that uC not being able to do much else.
Can you figure that could you react to the first change in under 1ms? Absolutely.
Will that work on you desk in your lab, or in DIY? Sure. (I have seen this implementation in some hardware made for measuring reaction time in experiments)
Would it practically hold up as a solid product and get no negative reviews ever, or pass certification? Maybe not.
Will that work shoved into, say, industry or a nightclub (lots of devices leaking EM everywhere)? Probably not.
Would it practically hold up as a solid product used in a safety context? Probably not.
Also, note that scanning very quickly only means we can react earlier to something that seems to be real, but the mechanical bounce is still there, and while it's happening that input is worthless to act on.
You cannot detect repeating events faster than the speed at which the mechanical bounce actually stops. That's not usually a problem, except when the rate can be high.
Also note that the faster you scan, the more that tiny capacitances will change at least the timing. That's not usually important, though.
More notes
Debouncing is also sometimes used to refer to rate limiting of software events.
For example, browsers may sometimes need to do moderately expensive things, like doing a relayout due to some change.
If keystrokes or mouse scroll might cause those, then you might wish to rate-limit the rate of relayouts in general, because otherwise you might get a short burst of hundreds, where reacting to just one would have the same result and be much faster.
Switches, buttons, toggles, and such
Encompasses combinations of:
- Multiple positions,
- a mechanical tendency to go to one position
- toggle/flip, or momentary
- multiple electronic states,
- and other electronic properties
Bistability refers to switches that will rest in both states.
It could be both a mechanical and electronic descriptor, though on the mechanical side it's often called latching, or some such term, whereas a monostable would refer to what most relays do (the term "monostable switch" would be rare because we have words like "momentary" and "pushbutton").
...so the terms monostable and bistability are usually about electronic switching, e.g. to pointing out e.g. that
- digital circuits can be made to sustain their current state.
- thyristors will stay in their current state, while transistors are not
- ...often then mentioning a simple bistable multivibrator circuit, a.k.a. flipflop), or contrasted with a monostable multivibrator
See also
Types
pushbutton tends to refer to any momentary thing, a switch frequently to something that stays in whatever state..
When shopping, it helps to know some names more specific than "small switch". A few more specific buttons/switches:
Toggle switch
- states: often two, sometimes three. Often toggled, rarely momentary
- toggle switch
Rocker switch
- states: often two, sometimes three. Often toggled, sometimes momentary
- rocker switch
Microswitch
- mainly a small momentary push-button
- states: Two. Momentary.
- with or without a metal leaf as a lever
- microswitch
Tactile switches, probably referring to their clicky nature
- momentary
DIP switches
- usually internal, for changeable device configuration that can't be acidentally changed
Reed switch
- states: Two.
- Mechanical, closed by nearby magnet
- reed switch
Mercury switch
- states: Two. Depends on orientation (because gravity).
- no contact bounce
- mercury switch
Knife switch
- The circuit breaker of old
- states: Two. toggled
- knife+switch
Footpedal switches (mostly seen around guitar pedals)
- the 9-pin are typically three separate latching switches (3PDT)
- these also exist in other variants, like single SPDT, momentary (SPST, for taps), and a few others
Uses:
- end switch
- a switch positioned at the end of a mechanical range, often to detect when actuation should go no further
- often a microswitch with some sort of lever, wheel, etc. for durability.\
- end+switch
Contact bounce (behaviour)
Contact bounce indicates the time in which an arriving contact mechanically settles and in which the connection is not yet stable. See some images. This bounce is often tiny, both in movement and time.
This bounce is rarely important when driving resistive loads, but in anything more complex there the reaction to the bounce itself can matter.
For example, a digital system observing/sampling it may see very fast switching back and forth.
Some components, such as ICs, also don't deal too well with bounce on their Vcc. A bypass capacitor helps here, and is nice for its power stability anyway.
Arcs (behaviour)
Default switch state (design)
Switches that are typically in one state are often can be referred to as Normally Open (NO) and Normally Closed (NC), roughly meaning they will return there unless actuated otherwise.
If it has contacts for more than one state (which, when one state is most natural, can be termed NO and NC contacts), the switch is termed Changeover (CO) (also Double-Throw, implying a typical two-state switch, Triple-Throw, etc.).
Changeover switches can be:
- break before make, meaning there is some time in which neither side makes contact. This may cause temporary high impedance long enough to cause some unpredictable behaviour
- make before break, meaning there is some time in which both sides make contact. This may easily cause temporary shorts.
Poles and throwing (design)
Depending on what exactly you want to do, poles and throws can matter when buying a switch.
Amount of poles matters to whether you want to do something with one state (e.g. powered or not) or with both.
Amount of throws matters when you want to control things independently from the same mechanical switch (without digital logic doing it for you). Consider that a car's emergency light switch turns on both turn signals without tying them together electrically.
In some constructions, both matter. Consider multiway switching.
- SPST (Single Pole, Single Throw), 1P1T
- open or closed
- SPDT (Single Pole, Double Throw), 1P2T
- a common lead switched between two other leads, resting either one one or the other.
- Used e.g. in multiway switching
- DPST (Double Pole, Single Throw), 2P1T
- two separate SPST-style switches controlled by the same mechanics
- DPDT (Double Pole, Double Throw), 2P2T
- two separate SPDT-style switches controlled by the same mechanics
Triple pole and similar also exist, for example
- three-phase mains knife switches are essentially 3PST (some are 3PDT)
- 9-pin guitar pedal switches are typically 3PDT
Relays
A relay is an electronically controlled switch - a switch you can flip remotely.
Relays switching an electronically separated circuit can be useful when they deal with different voltages and/or different orders of current.
Say, microcontrollers switching mains equipment.
Relays are also make sense around more modular systems, like process control,
because it's easier to separate control signals from drive currents,
e.g. via connectors following some convention.
Also to have them be plug-and-play replacable.
Electromechanical relays are the classical variant, specifically a solenoid that pushes/pulls a contact closed.
Being the main/only type for a while, just 'relay' often refers to electromechanical relays.
In contexts where you see both, people start using abbreviations like EMR and SSRs, where....
Solid state relays (SSR) are a relatively new development, and are becoming more common.
SSRs seem to often be either
- for switching AC or DC loads: a SCR or TRIAC with the appropiate control circuitry to make them work basically like relays (and may be isolated too)
- for switching only DC loads: a MOSFET
...plus heatsinking, optical coupling for isolation, and some other considerations.
There are also Reed relays, which can switch faster than EMRs, but can rarely switch more than half an amp of current. They are mostly associated with some oldschool analog electronics.
In general, your choice is between EMR and SSR. There is more comparison below, but in general, EMRs ar chunkier but wear over time, while SSRs take a bunch more design care but can then be more flexible.
Circuit considerations - control side
EMRs may need need on the order of 20mA-50mA to be held consistently. More when switched from lower voltages, less from higher voltages.
Because EMRs are coils, they are inductive elements that present flyback to the circuit that drives them, so you may want to sink that flyback spike elsewhere, particularly if controlled from ICs.
Circuits with ICs driving them
- typically something (probably a diode) for flyback protection of that transistor/optocoupler.
- regularly use a transistor (sometimes an optocoupler) to drive ~50mA even when the control
SSRs use less control current(verify), but run hotter overall due to their semiconductor nature, so
- you may need a heatsink or risk thermal runaway (read: smoky melty problems), particularly in already-warm conditions
- for safety's sake assume approx 1W of heat per 1A drawn, though usually it's noticably less
Circuit considerations - load side
Relay ratings
Not all relays are created equal.
The physical design will vary with the voltages they are intended to switch.
- Most are designed for at most mains voltage, because arcing is harder to design away at kilovolts.
- Relays designed for at most dozens of volts can switch faster because they barely have to think about arcing as an .
Relatedly, when switching significantly capacitive/inductive effects, you will briefly see larger currents and voltages (the inrush current of the load).
- This is one reason a relay's maximum rated inductive load is much lower, often well under half the rated maximum resistive load.
- For example, the one I'm holding right now is rated for 10A (at 125VAC and 240VAC) for resistive loads, and for 3A for inductive loads.
- This too depends somewhat on the voltage.
- Specifying these differences is called 'derating
There is also a difference between whether it's switching AC or DC.
- Because DC can sustain an arc longer, DC is derated more(verify).
- Check the datasheet, the ratings printed on the relay may be correct but less complete.
Hot switching refers to switching a relay while voltage is applied, which matters mostly to mechanical relays in that it produces arcing and wear.
Cold switching refers to applying voltage only after a relay switch.
Cold switching is possible to design into some test equipment, and sometimes useful to concentrate the wear in a predictable place, but in general many uses of relays will be hot switching.
Note that while it may seem that using a relay for much less current than it is designed for should avoid all wear issues (no arcing), it seems this actually can make them get dirty instead (?oxidation?(verify)), meaning they will fail to work reliably.
Comparison between SSRs and EMRs
- switching speed
- SSRs can switch at perhaps 20usec..10msec. That said, ones that have zero cross switching are by definition slower.
- EMRs at order of 50ms and wear faster in the process
- SSRs can switch much larger currents without much higher drive currents
- SSRs that do zero point switching means no sudden current change
- so they don't pollute the waveform as much(verify)
- EMRs have contact bounce
- and, when hot-switching, arcing, welding, and shortened contact lifespan
- this is worse on inductive loads
- EMRs are more susceptible to shock, and orientation matters
- SSRs are preferable around strong vibration (to avoid intermittent contacts, amplifying bounce)
- SSRs are preferable when they have to be close to magnetic sensors, temperature sensors
- SSRs can be preferable in humid and dusty environments (but you may want to protect the entire PCB with an enclosure, so this often matters less)
- current draw
- larger EMRs have to push larger contacts
- SSRs are higher resistance by nature, so use a few times more hold current
Safety-wise
- EMRs arc internally so unless they are entirely sealed (various are not), SSRs will be less risky around combustibles/explosives
- SSRs have different failure modes than EMRs, which can matter
- in particular, SSRs are more likely than EMRs to fail closed, which can matter
Protecting relays from capacitive/inductive effects
- if it's DC, you could use a chunky diode on the output end
- if it's AC,
Failure/Reliability-wise,
- Failure state
- EMRs can weld shut so fail in conductive state, but more usually have their coil fail so fail open
- SSRs usually fail in conductive state
- In some situations the latter is a much worse idea, both because they may melt or blow, and because the machine is probably not in a safe state before they break (and leaving e.g. a motor actuated might break it).
- In situations that require fast switching as well (e.g. industrial control), you can opt for SSR for everyday operation and an EMR as a safety interlock controlled from some sensing.
- EMRs can have intermittent connections due to poor contact surface (and spot welds over time)
- EMRs should probably not be switched overly quickly, and because they are physically slowish they often won't even manage
- SSRs have no clear primary wear-out mechanism so should last quite long in gentle conditions,
- yet there are conditions that kill SSRs faster than EMRs.
- SSRs are less resistant to heat (see thermal runaway), and at the same time are warmer than EMRs for the same current.
- so cooling them can matter
Voltage surges, momentary shorts, inrush, and (for some) the polarity of what it's switching matters.
Which means that EMRs can be preferable for components (motors, transformers) with high inrush current(verify).
Inductive can still create high enough voltage spikes to damage SSR's output transistors
You can generally assume EMRs have on the order of 100K switches in them, varying with quality, how near their current rating they are being used (you might get a spec that says 1M at negligible current, and 10K under significant load).
So assuming a few to a few dozen switches or so per day, they should last years to decades, though in some certain fast-switching uses (e.g. industrial machine control) that might reduce to months so you might want SSRs (with the exception that SSRs may fail on, so which you may want to back up with an EMR for safety and other such interesting implications)
Unsorted: