2
\$\begingroup\$

I have two separate LEDs. Both LEDs have 500 ohm resistor and are powered with 5V. These LEDs are controlled by an MCU. LED anode is connected to VCC and the diode is connected through the resistor directly to a MCU GPIO port capable to drive the LED.

So I have two separate signals that controls LEDs and the VCC. Those are the only things that I can access. I have no access to GND. What I would like to do is a kind of logic that will ensure that only one of those two LEDs can glow. If MCU tries to turn on both LEDs none should glow.

In fact, this is not just a LED but a SSR module (G3MB-202P) with internal photodiode. the SSR controls a 230V AC motor. One SSR spins motor in one direction and second in the other. I just want to protect in case when the MCU will try to spin the motor in both directions as it would damage the motor.

My current approach is depicted below, but it does not seem to work. Could anyone please guide me how to do the logic properly?

enter image description here

\$\endgroup\$
8
  • \$\begingroup\$ If you want to add more images you need to edit your question. You can't add images here in the comments. \$\endgroup\$
    – brhans
    Commented Aug 5 at 12:22
  • \$\begingroup\$ Really rough calculations. But looks like HFE is about 100 for a MMBT3904LT1. So IBE is (you didn't say at what voltage the MCU works at so lets assume worse case 3V) (3-.7)/4700 which is about 0.0005A. Multiply by HFE gets you up to 5mA. And the suggested forward current of the G3MB 202P is 10mA (5mA is the lower limit ... but these calculations are very rough and the actual current may well be below 5mA). \$\endgroup\$
    – st2000
    Commented Aug 5 at 12:39
  • \$\begingroup\$ ...nuts, did not fix the above in time before the stackexchange comment editing timeout. Anyways it's wrong.... fixing it: (3-.7)/4700 which is about 0.0005A. Multiply by HFE gets you up to 50mA. And the suggested forward current of the G3MB 202P is 10mA (max 20mA). But that's the current capacity of the transistor. There's also the limiting current of the MCU's output and a few other things to consider. So maybe the diode is burnt out or maybe not. Like I said ... rough calculations. \$\endgroup\$
    – st2000
    Commented Aug 5 at 12:48
  • \$\begingroup\$ Question: Why can't you re-write the software for the logical behavior desired at GPIO0 and GPIO1 and connect each to a solid state relay? In the real world, this would be the accepted solution as it cuts the MMBT3904LT1 from the BOM reducing part count, reducing cost and lowering the MTB failure. I'll put this in an answer if you'll accept it. Otherwise, while addressing the problem, it does not directly answer the stated question. \$\endgroup\$
    – st2000
    Commented Aug 5 at 12:57
  • 1
    \$\begingroup\$ @st2000 just delete the bad comment and write again \$\endgroup\$
    – jsotola
    Commented Aug 5 at 14:53

4 Answers 4

3
\$\begingroup\$

Your problem was that the transistor was inverting from the Base and non-inverting from the Emitter, so your XOR logic failed.

Using any CMOS logic level input, a simpler XOR solution works.

Your R values will yield an 8 mA LED current with 5V logic <~50 ohms.

A phototransistor was used to simulate the phototriac logic, so also disregard the 3.3V.

I changed the interface from high Enable input to low (!) Enable input which is safer during a power On Reset with all I/O's floating as inputs.

my sim H/L inputs in box are interactive.

\$\endgroup\$
8
  • 1
    \$\begingroup\$ I like the solution. Very simple in implementation and will probably work. I'll test it today. \$\endgroup\$ Commented Aug 5 at 14:10
  • \$\begingroup\$ If I understood correctly, you made an anti-parallel LED connection. Just would like to point out that the LED's reverse breakdown voltage is 5V. \$\endgroup\$ Commented Aug 5 at 17:19
  • \$\begingroup\$ ohh, so it will not work! \$\endgroup\$ Commented Aug 5 at 18:26
  • \$\begingroup\$ @noonespecial well, let's say "not guaranteed" because some operating conditions will be either quite close to or beyond the maximum ratings. When you apply 5V to one input and 0V to the other, one of the LEDs will be exposed to a reverse voltage of 5V which is the abs max. So it's not guaranteed whether the LED will survive. \$\endgroup\$ Commented Aug 5 at 20:31
  • 1
    \$\begingroup\$ Wow, so many good ideas. Thank you so much! \$\endgroup\$ Commented Aug 6 at 16:03
2
\$\begingroup\$

What I would like to do is a kind of logic that will ensure that only one of those two LEDs can glow. If MCU tries to turn on both LEDs none should glow.

This sounds like an XOR behaviour:

schematic

simulate this circuit – Schematic created using CircuitLab

The above is a crude, two-transistor XNOR gate (NOT of XOR) and, of course, is for two inputs and one output yet you have two inputs and outputs. But I think you can make use of it somehow.

\$\endgroup\$
2
  • \$\begingroup\$ Yes, kind like a XOR but not exactly. This is what I tried to achieve in the circuit I shared above. \$\endgroup\$ Commented Aug 5 at 14:03
  • \$\begingroup\$ Agreed. @noonespecial Q2-e must be grounded to be a valid XNOR in RTL. \$\endgroup\$
    – D.A.S.
    Commented Aug 7 at 5:24
1
\$\begingroup\$

Your circuit really should work, but only if the Input0 and Input1 pins can source current. I suspect that they can only sink current — i.e., they are open-collector or open-drain outputs — therefore neither transistor can turn on.

If this is the case, just modify your resistor position slightly to use them as pull-ups:

schematic

simulate this circuit – Schematic created using CircuitLab

\$\endgroup\$
0
\$\begingroup\$

You could just connect both SSR inputs to both GPIO0 and GPIO1 if those and VCC are only available signals.

Then you can't light up both LEDs simultaneously.

However, this offers no safety. You can blink both LEDs on and off so fast that the motor or SSRs still burn, if something goes wrong.

Of course you can make software whigh delays the correct amount with both off for some time before activating one SSR.

\$\endgroup\$
1
  • 1
    \$\begingroup\$ Good point indicating the issue with fast toggling. And no, I cannot modify the software. \$\endgroup\$ Commented Aug 5 at 14:06

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.