Is this a proper use of a PNP transistor?

I'm attempting to use a transistor to switch on and off an SSR, which in turns switches on and off a solenoid. I originally used an NPN transistor (2N222), but this caused problems when the MCU reboots, because all the IO pins are pulled high. While trying to theorize (using my very limited knowledge in the area) on how I might use a PNP transistor to switch on/off the +5V going to the NPN transistors, it struck me that I might simply use a PNP to drive the SSR directly. This would avoid the reboot issue, because the transistor would be "switched off" while the IO was driven high (right...?):

Is this an appropriate use of a PNP transistor? Is this a (probably-obvious-to-most-but-clever-to-me) valid solution?

Based on Russell's answer, I think it's not (at least, not how it's drawn here), because the MCU output is only 3.3V, not 5V.

• If your uC GPIO pins can be programmed to be open drain outputs, you could drive the optocoupler using the open-drain output and a pull-up resistor to your 5v rail. – B Pete Jul 26 '11 at 22:50
• @B Pete: the problem is that the firmware explicitly sets them to inputs and enables the internal pullup resistors upon reset. I can't change anything about that for several seconds, by which time I would have serious problems. – Mark Jul 26 '11 at 23:07
• Yes, but as with the PNP solution, the optocoupler and the SSR will be activated when the open drain output is pulling the pin LOW. The momentary high level will leave the SSRs off. But, this only works if your uP has open drain outputs. – B Pete Jul 27 '11 at 1:29
• Oh god, horrible schematic. WHY? Put the +5V port facing up, and the emitter of the PNP transmitter on top. Otherwise, it's much harder to understand. – Connor Wolf Jul 27 '11 at 7:44
• @Fake Name: I couldn't figure out in TinyCAD how to flip the transistor without moving the base to the right. Either way, something was going to look bad. – Mark Jul 27 '11 at 15:05

The solution you propose is good enough as a basic solution as long as you can guarantee that the FEZ output stays high at all times until you set it low. That's your job to determine.

Add a highish [tm] value resistor from +5V to PNP-base to hold it turned off when "FEZ" is open circuit. Failure to do this will probably lead to "surprises". 10k to 100k will suffice.

Note that as shown FEZ must rise to close to +5V to turn off the transistor. As little as 0.5V below rail ( 4.5V) may lead to turn on. This may or may not be a problem depending on the processor / drive circuit implementation. What works here may fail somewhere esle if this is not taken account of. Changing the 10k to 100k above to a eg 2k2 base to emitter will divide the drive voltage so that you need more negative gping voltage before the transistor turns on. Design to suit.

The solenoid MUST have a reverse diode across it if DC operated to minimise the reactive spike on turn off.

As shown your SSR has a TRIAC output stage. This may imply AC drive or may just be the symbol that you had available. If it is in fact an AC driven solenoid then you may or may not need to "snub" it to prevent reactive energy problems, as for DC.

• If the optocoupler is "zero crossing" switched at turn on and turn off you may not need a "snubber" although, with a highly reactive load current and voltage are nearly 90 degrees out of phase and turning off at a voltage zero crossing will still result in an inductive "kick".

• If the optocoupler is not zero crossing switched then you need a snubber to dissipate the reactive energy. You can't just use a reversed diode as it will conduct on every second half cycle (and there would be "trouble!" :-) ). . One method is to use opposing polarity zener diodes in series, with zener voltages at least slightly above the peak AC half wave voltage. eg for 110 VAC mains coil drive Vzener >= 110 x 1.414 >= 160- V. Say 18- V zeners. ( solenoid terminal 1 - zener 1 cathode, zener1 anode - zener2 anode, zener 2 cathode - solenoid terminal 2.

Powerup handling

While the above solves the problem as presented it MAY not solve the problem as it happens in generic real world cases, and just possibly not in this case either. Here we have allowed ourselves to be "taken captive" by what the processor does at startup, rather than designing what we want to happen. If the processor does not do quite what we want we are then forced to find some other workaround.

An alternative is to design a circuit that is guaranteed to start up properly. This may well not be quite the cheapest and simplest solution and whether it is worthwhile depends on application. I'll not go into any great detail as there are many ways this can be done.

One example only. An NPN driver is used. Transistor base is connected to an electrolytic cap via a diode (possibly a Schottky diode). The capacitor is also charged via a resistor from Vcc. At turn on the capacitor is at 0 V so the transistor base is clamped low by the capacitor and the transistor cannot turn on. The capacitor is charged high by the resistor from Vcc and after a period of probably < 1 time constant Vcapacitor > 0.6V (ignoring the diode effect) and the capacitor has no more effect on operation. What happens at power down needs to be determined.

Various options can be imagined. eg the capacitor could instead be controlled by a "spare" pin and a number of drivers controlled together in this manner. This could be used as a mass "driver disable" at any time at an incremental cost of one Schottky diode per driver.

Whether this or some other scheme is worthwhile is TBD in each case.

An alternative is to switch the supply which is used to control peripherals (such as the SSR in this case). This too could be done with pin control or by an RC delay. Lots of opportunities for thought and playing.

3.3V drive & other real world issues

The MOC3010 optocoupler LED requires 1.5V max forward voltage so 3.3V drive is OK.

Connect PNP emitter to 3V3 (if available) and drive as per above comments.

If there are miscellaneous blips on the input line before things settle down then one of my powerup ideas or something similar is required if false operations are to be avoided.

If response time is not an issue, or if a delay of say 0.5s is acceptable, then adding a "suitably sized" capacitor to the transistor base (whether PNP or NPN) will slow operation. This also slows release time so you need to be aware of overall effects.

Even if operation with no snubber seems to work Ok I would VERY STRONGLY recommend that a snubber be used, as "stuff happens" and sooner or later you are liable to hit peak mains voltage 'just so" and experience an inductive spike of considerable magnitude. In the absence of a snubber the TRIAC itself may decide to step up and dissipate the energy. Whether it does so destructively or effectively just turns on for another half cycle is TBD. This is not the sort of thing that you want your components determining on your behalf. A reliable design is one that is (at least) designed. If things may happen that you have not designed for then you can expect that the unexpected may happen.

• Indeed my solenoids are AC driven, with 24V. Thanks for the great info! The datasheet advises testing the SSR and "if unintented switching occurs" to start with a snubber using the values Cs=0.022μF and Rs=47Ω. In my (snubberless) testing it never exhibited this problem. – Mark Jul 27 '11 at 1:18
• I failed to take into account the fact that my MCU only outputs 3.3V. Also, upon reboot the pins aren't necessarily "driven" high, they're set to input and pulled up to 3.3V with internal ~50k pullup resistors. The PNP idea is looking less and less good. – Mark Jul 27 '11 at 1:24
• Your description of a diode/capacitor/resistor setup is interesting to me, but I can't visualize it (this is way out of my league, where we're proud to have blinked a couple LEDs driven by simple NPN BJTs). Would it be possible to describe it in a bit more detail? – Mark Jul 27 '11 at 1:57
• See edited answer above re 3.3V drive and snubbing. – Russell McMahon Jul 27 '11 at 1:59
• Build as follows: For NPN ground referenced driver: Cap-ve to gnd. Schottky diode from base to Cap+ (Diode Anode to base). Resistor Rsu from V+ to Cap+. Cap at ground at su (startup) clamps base to low. Drive signals do not operate transistor as base clamped to cap at ~+ 0V. Cap charges via Rsu. When Vcap > (Vbase_on-Vschottky) clamping stops. Needs largish cap. Adding another diode across cap (usually reverse biased ) allows cap to dischg when power is removed. Helps reset the reset cct faster. If this is a common problem better to depower peripherals or use shared reset line for drivers. – Russell McMahon Jul 27 '11 at 2:08

One nit though: for clarity it's usually a good idea to draw schematics with power voltages positive to negative top to bottom. In other words, your circuit is right, but I'd like to see the transistor transposed vertically. Emitter on top connected to +5V supply, collector down driving the SSR, and base to the left as you have it. My first reaction was that your circuit was broken until I noticed the 5V at bottom.

• I agree, that's the way I wanted it, but I couldn't figure out how to arrange the transistor that way in TinyCAD :( – Mark Jul 27 '11 at 0:08
• Needs Rbe for o/c input safety. – Russell McMahon Jul 27 '11 at 0:13

If I understand you correctly the transistor's emitter is connected to +5V, but the microcontroller is 3.3V.

In general you can't do that. Making the output high will still draw current through the base: (5V - 0.7V - 3.3V)/2200$\Omega$ = 450$\mu$A, which would be enough to switch on the SSR. A solution would be to switch the I/O pin to input instead of making it a high output, but most 3.3V controllers are not 5V tolerant.

You could drop a few volt from the base by placing a couple of diodes in series, but those need current to create the voltage drop, which would mean that you need a resistance to ground, and then you have your original problem again: at startup the path transistor-diodes-pulldown will conduct, switching on the SSR.

My suggestion would be to switch back to the NPN solution, and make sure any internal pull-up is disabled.

If my memory serves me, the only gotcha is that what you've done inverts the 'sense' of the FEZ input. That is to say, in order to turn the transistor "ON" you have to drive the base of the PNP transistor to GND. Other than that, it seems like a perfectly valid solution to me.

• Right. The drive logic in the software will need to be inverted, i.e. drive the output LOW to turn it on, and HIGH to turn it off... is that what you mean? – Mark Jul 26 '11 at 22:02
• yes that is what i mean. – vicatcu Jul 27 '11 at 3:49