In making a breakout board for an SMD Bluetooth module, I realized that simply wiring LEDs to your signal lines is insufficient for a decent visual indication, as signal duration is too short to be visible to the eye unaided by electronics. So what is needed then is a simple circuit to extend the time the indicator LED stays on. Here's what I cam up with, with the upper circuit being for normally low situation and the lower circuit for the normally high:

enter image description here

Figuring about 200ms as the minimum time the LED needs to be on, a 5V circuit, 0.6V for the diode drop, 1.6 for the LED V forward, and 330 Ohms for the current-limiting resistor, I came up with around 1uF for the cap value. The Schmitt trigger/buffer is there in order not to load the signal line. I'd like to keep this as simple as possible (just a diagnostic tool to embed in the circuit), but I probably made it too simple and missed something obvious?

  • \$\begingroup\$ I just need to ask, doesn't your bluetooth module already have link/activity led outputs? \$\endgroup\$ – Passerby Feb 4 '14 at 2:31
  • \$\begingroup\$ I recently did something using a LED on during a 10ms sample period every second and it's very visible. It might be worth trying it without any pulse extender. \$\endgroup\$ – PeterJ Feb 4 '14 at 2:34
  • \$\begingroup\$ @Passerby No, I got the cheap one :( And the I2C lines I plan to use it for don't come with the LEDs either \$\endgroup\$ – angelatlarge Feb 4 '14 at 3:13
  • \$\begingroup\$ @PeterJ Intereting. Persistence of vision, I guess. The Bluetooth module I have provides TTL out, which involves "normally high" logic, and there I really can't see the blinky-blink. Had I wired the LEDs correctly perhaps it wouldn't have been a problem. \$\endgroup\$ – angelatlarge Feb 4 '14 at 3:15
  • \$\begingroup\$ Do check if you are using modern high efficiency / high brightness (or whatever they're called) LED's. Some light up very bright at very low currents. \$\endgroup\$ – jippie Feb 4 '14 at 7:23

The main problem with your circuit is that the time constant of 330 ohms and 1\$\mu\$F is only \$330\mu sec\$, which is not all that long, and the LED will not be especially bright for that brief time. You have to consider the physiological response of the human eye.

Your eye acts as a kind of integrator over a period in the 100msec range, so a very bright pulse of light for a short time (such as \$330\mu sec\$) would actually be visible, but it would have to be about 300 times brighter than a continuously-on light to achieve the same apparent brightness. So, an LED that is acceptably bright at 2mA would need 600mA pulse for ~300\$\mu sec\$, or to have a similar chunk of \$ current \cdot time \$ metered out to it. Since that has to come from the inverter output, it's a bit much to ask.

You could use much higher value resistors (such as 300K) and feed that to another gate, using the output of that gate to drive the LED.

enter image description here

As an alternative, this would be a great application for a dual monostable multivibrator such as a 74HC123. The complexity is not very different (4 resistors, 2 capacitors, 1 chip and no diodes). It's a bit different because this circuit does not stretch the existing pulse, rather it produces a visible chunk of light on every valid edge (either positive or negative, depending how you wire it) of the input signal.

enter image description here

Drive the /A or B input of each multivibrator with the BT signal and tie the other one inactive. (For example, if you want it to trigger on the falling edge, use the /A input and tie the B input high). The reset input /R is active low so it should be be tied high.

enter image description here

You can drive the LEDs by connecting them to Vcc through a suitable current-limiting resistor (such as 330 \$ \Omega\$ ) from the /Q outputs.

The time constant from Rx and Cx should result in a pulse that is easily visible, so somewhere in the 200msec range would be good. For the TI part, the time is \$ t_W = R_X \cdot C_X \$, so 470K and 1uF would be reasonable.

The 1uF capacitor has to supply only microamperes to keep the monostable in action, and the monstable output does the heavy lifting- providing ~10mA for ~200msec to the LED.

  • \$\begingroup\$ Would you mind expanding on the the claim that the LED will not be bright? I am not sure I understand the engineering/mathematical considerations behind this assertion \$\endgroup\$ – angelatlarge Feb 4 '14 at 19:30
  • \$\begingroup\$ The LED will not appear to be bright, because the pulse length is (much) less than the human eye's "flicker fusion" time, so the apparent brightness is the actual brightness multiplied by something like \$t_{ON}/100msec\$. That ratio is about 0.003 (0.3%), so the apparent brightness will be miserably low. \$\endgroup\$ – Spehro Pefhany Feb 4 '14 at 19:47
  • \$\begingroup\$ Oh, so you are not saying that while on the LED will be relatively dim? "and the LED will not be especially bright for that brief time" let me to believe otherwise. \$\endgroup\$ – angelatlarge Feb 4 '14 at 21:39
  • \$\begingroup\$ @angelatlarge It will not be especially bright (or especially dim) because it's getting current through the 330\$ \Omega \$ resistor. The apparent brightness of a single short pulse of "normal" brightness when perceived by a human eye will be very low. An oscilloscope and fast PIN photodiode/transimpedance amplifier would pick up a strong signal, but human eyes don't work like that. \$\endgroup\$ – Spehro Pefhany Feb 4 '14 at 21:42

One gotcha is that you're asking the buffer chip to supply, within the duration of the pulse, all of the current that is going to eventually go into the LED. This is going to put a lot of strain on that buffer.

It would be better to buffer the stretched pulse again, with a second buffer that drives the LED. This will also allow the use of a smaller capacitor, since it only needs to store enough charge to activate the input of the second buffer, not enough to illuminate the LED directly.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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