How the LED light of a USB card reader works?

[prabhatkarpe4]

I need to know how the LED light of a USB card reader that indicates the data transfer works?

Is it possible to create such a light using transistors and putting that circuit parallelly with a data cable connected to a USB storage drive?



In this diagram how that LED connected with the GPIO0 pin works?

I was talking about the light that blinks in this video.

https://drive.google.com/file/d/1odw-TqbCfqCP_JEQI6smA7dSSWmZ1QNp/view?usp=drive_link

electrical-engineeringpower-electronicscomputer-hardwaredatacomputer

[darkspr1te]

The led is triggered by the USB -> sdcard chip itself, you could not "tap into" the two USB data lines without adding interference to the signal and USB frames would mean the light would be on 99% of the time. it would be easier to find a USB storage drive with LED signal built in.


darkspr1te

[prabhatkarpe4]

That's okay, I can use a LED blinking circuit but how am I going to get the Rx/TX voltage to make the LED glow? The voltage is very less, about 1V. How to make a sensor for the data lines using a transistor or mosfet?

[Andy Chee]

My brute force idea would be to buffer the Tx/Rx lines and feed them into a clock divider chain.  The output of the dividers should be slow enough to make a blinking rate perceivable by the human eye.

[Nominal Animal]

Many USB hub and controller ICs support a suspend LED; see e.g. Microchip USB2422.

The suspend indicator is active/asserted when the hub receives or transmits data from/to the host, and inactive/deasserted when the hub is not yet configured or is suspended.  Whenever it is idle for 3 milliseconds or longer, the hub is suspended, and the LED turns off.

I do believe that USB mass storage devices use the same signal for their activity LEDs, perhaps extended via a simple capacitor-transistor circuit (delaying the turn-off by a constant time, so the LED does not have to be so bright).  That is, the activity LED is ON whenever the device is fully powered (active), and OFF when suspended.

[prabhatkarpe4]

So how do I build a simple circuit using a transistor or a MOSFET that can be connected in parallel with the Rx/Tx lines of the USB to make the LED turn on whenever there is a data transfer?

[darkspr1te]

As i mentioned prior, You CANNOT just tap into the usb lines and make a led flash, I would advise you start reading USB standards to understand why. It's to long to write here but the TL;DR is that usb data frames are almost constant so any led would be on all the time, devices that have leds use internal triggers to act on certain USB data frames they see and flash the light on those only reducing the PWM of the led to a point you can see easily.

[prabhatkarpe4]

I am able to check the voltage of the Rx/Tx lines of the USB during the data transfer using a multimeter. If the multimeter can read the voltage without interfering with the data transfer then why not using a circuit to detect the voltage during the data transfer?

If you can't help then I guess I have to build it all by myself.

[prabhatkarpe4]

could you please email me with your ides to prabhatkarpe4@gmail.com

[magic]

I'm not familiar with hi-speed (that's what you deal with, I presume?) USB physical layer and I'm too lazy today to look it up. I know that it uses low amplitude differential signaling, so tapping into it is not as straightforward as into full-speed. But if it's the case that the lines always idle in a particular state, say D- lower than D+, then it might be possible to detect presence of packets with relatively simple, low speed circuitry.

There will be short packets every millisecond, one could try to design something that ignores very short packets completely or at least looks at the "duty cycle" of the link and only light up the LED if a particular rate of transfer is detected.

So not entirely trivial, but maybe doable...

Of course it's best to figure out how to use the USB chip's built-in activity indicator, most of them have such things.

[prabhatkarpe4]

If the USB activity can show up on a multimeter as ~1V then it can be used to light up an LED too.

[Nominal Animal]

Why don't you try it in practice and see for yourself?

Start with an analog comparator, say AP331 or LMV331 in SOT25/SOT23-5, with its VCC (pin 5) connected to USB +5V, GND (pin 2) to USB GND, output (pin 4) connected to a suitable current-limiting resistor and a LED cathode, the LED anode connected to USB +5V.  For a typical red LED, 1kΩ should work well, limiting the current to about 3mA (which should still be quite visible) which both of these can sink on their output.

This configuration means that whenever the positive input (pin 1) has a lower potential than the negative input (pin 3), the LED will light up.  The current drawn from the inputs is extremely low, under half a microamp (150nA typical), so it shouldn't affect the USB data lines.

So, you connect the negative input (pin 3) to one of the data lines, and the positive input to a voltage divider formed from two large-valued resistors.
That is R1 is connected between USB +5V and positive input (pin 1), and R2 connected between positive input (pin 1) and GND.
This means that whenever the data line (connected to negative input, pin 3) exceeds about 5V*R2/(R1+R2), the LED will light up.
For 0.9V, you'll want R1 to be 4 to 5 times R2, and the values high enough to not waste too much current; say R1+R2 between 50kΩ and 1MΩ.
For simplicity, I'd pick R2=100kΩ and R1=470kΩ, setting the threshold voltage to 0.79V – 0.96V, depending on the USB +5V voltage (which may vary between 4.5V and 5.5V).

In all, you'd need the comparator, three resistors (1kΩ, 100kΩ, 470kΩ), and an ordinary LED.

I do believe it would work after a fashion, for low-speed and full-speed USB devices like mice and keyboards, but not for high-speed USB devices like memory sticks.  The signaling level at high-speed is only 0.4V.  You could compensate by changing R2=33kΩ, which would set the threshold to 0.29V – 0.36V depending on the USB +5V voltage.

Your insistence, however, tells my spidey-senses that this is an assignment you have: to find a way to use a simple transistor circuit to detect USB 1.1/2.0 data transfers.  If so, the assignment is in error, because it is the wrong way to do it.  It is like using two nails connected to mains voltage to cook a sausage.  It may technically work, but it isn't a sensible or safe way to cook a sausage at all.  Yes, you can find devices online that do exactly this, but that is not a proof that it is sensible to do, at all.  (If this is the case, whoever gave you the assignment has a specific circuit in mind, that they want you to discover.  I have an inkling of what that circuit would be, but I am utterly disgusted at the idea.)

Now, let's consider the proper solution.

Mine would be a Microchip USB2512B or USB2514B USB 2.0 hub chip, 24 MHz crystal, bunch of bypass capacitors, resistors (including strapping resistors making it bus-powered), only one downstream port, and the activity LED connected to SUSP_IND pin.  You can find a full schematic of a four-port hub (without an activity LED, just a 100kΩ resistor R3 to ground) at SparkFun's Github to use as a basis, but note that the 22Ω series resistors are not needed when using USB251xB.  You can easily design the board at EasyEDA, and have it manufactured and assembled at JLCPCB, for very little money.  I know, because I am only a hobbyist, and yet this would easily be within even my skills.  I know enough that the crystal PCB design would be the "tricky" part, but using the SparkFun KiCad files as a basis should make that easy and straightforward.

To save costs, I would leave out the connectors and the ESD protection, and instead use an USB A male - A female (USB 2.0 extension cable), cutting it in half, and solder the cables directly to the board.  By my count, I'd need the USB251xB, a 24 MHz crystal and its two load capacitors, five 0.1µF = 100nF bypass capacitors, two 1µF bypass capacitors, a 3.3V regulator (500mA or more), six 100kΩ resistors, three 10kΩ resistors (for disabling the unused ports), a P-channel MOSFET for power control of the downstream USB 5V, and a red LED with a 1kΩ current-limiting resistor.

This is the closest equivalent of what USB devices have, when they have an activity indicator.  Here, we use an USB hub with such an indicator; normally, the indicator LED output is provided by the USB interface chip on the device itself.  On microcontrollers with native USB interfaces (including old AVRs like ATmega32u4 and 90USB1280, cheap WCH CH55xG E8051-based MCUs, ARM Cortex-M ones, and so on), there is an interrupt related to USB suspend, so one can use whatever GPIO pin for such an activity LED.

Why is the "transistor only" activity circuit wrong?  Because the USB data pins' voltage levels do vary normally.  Proper activity cannot be reliably detected in all situations from their instant voltage potentials only.  Instead, the state of the USB bus itself should be considered –– and that is exactly what the "suspend" state does: whenever there is no activity for 1 millisecond or longer, the bus is suspended.  It does not affect the USB 5V supply, nor limit the current the device can draw from it, it is purely a logical state for the USB bus, with no active communications ongoing, and nothing to do with electrical power.

So, if you insist on exploring the "transistor only" route, do remember that doing that in a real life product would/should get you fired.  (And if it is an exercise your professor gave you, they should be fired too.)  It is the equivalent of cooking sausages with nails connected to mains, and selling the sausages for others to eat.  Doing it properly, with an electric grill or stovetop and pan, takes a small investment up front, but leads to a better overall result for everyone (and more profit if you do it longer than a single day).  Don't be the guy selling iffy sausages.

[tooki]

could you please email me with your ides to -removed-@gmail.com

It’s extremely rude to ask on a public forum for replies via a private channel. Fora work by letting others see the questions and answers.

[amyk]

Much like how the activity LEDs on NICs are driven by the software, those on USB devices will be driven by the firmware they contain. This of course means the indicator can lie, which is why I don't think it's right to be characterising the analog approach as "not a proper solution". It's easy to make software lie, but it's harder to make analog components behave differently only under very specific circumstances.

[magic]

This approach has its own pitfalls. If you observe a traffic on the bus, you don't know if it's data transfer to the card or data transfer from the card or simply somebody repeatedly querying the card reader for its USB descriptors. And if you aren't careful, you could perhaps make your indicator sensitive not to an idle line, but some other condition like USB suspend. Then the user disables power management for any reason and suddenly it looks like the device is 100% utilized all the time.

I'm not saying that this is the case here, but it might be. I'm too lazy to look up the low level details of USB 2.0 physical layer, and a big problem is that OP is too lazy as well.

[radiolistener]

usually it is connected to GPIO and controlled from driver code on PC.

[magic]

No, it's controlled by firmware on the card reader chip.

Virtually all of them implement standard USB Mass Storage class, so they look like pendrives basically and use no special drivers. Storage Class has no concept of blinking LEDs, this is done by the device itself on its own.

[Nominal Animal]

And if you aren't careful, you could perhaps make your indicator sensitive not to an idle line, but some other condition like USB suspend.

USB suspend is much more reliable indicator of "no action" than the USB data lines not having any activity.

All the card readers and USB storage sticks I have do use USB suspend for the activity indicator: whenever the USB device interface is suspended, the LED is OFF, and ON otherwise.  Remember, it has nothing to do with power and everything with active messaging between the device and the host.  You can easily check this for yourself in Linux if you suspect otherwise.

[magic]

All my card readers and pendrives which have LEDs (that's exactly one reader and one pendrive) behave differently: they light up when connected, don't go out on suspend, blink slowly on data transfer.

[Nominal Animal]

Interesting!

I do absolutely agree to the LED blinking being controlled by the firmware; that was never in question.

In the USB 2.0 era, USB224x was a pretty typical USB media controller (USB to SD/SDHC/Transflash, MMC, etc.).  It has internal flash memory for configuration – including the USB vendor and product identifiers and such –, and a dedicated LED pin capable of sourcing or sinking 12mA.  There are three configuration bytes related to LEDs: blink interval (LED_BLK_INT, high bit sets idle state, and the rest the blink interval in units of 50ms), blink after address (LED_BLK_DUR, number of seconds blinking after access), and one attribute byte (ATT_HLB) which selects the LED mode (polarity and whether the LED only indicates activity or combined media inserted + activity).

If we look at say Arduino AVR core USBCore.cpp:ISR(USB_GEN_vect) (i.e. the USB interrupt routine run on USB interrupt on AVRs with native USB interface, for example ATmega32u4), the above functionality would be very easy to replicate.  As it only supports full speed (12 Mbits/s), the SOF interrupt occurs once every millisecond (when not suspended), WAKEUPI whenever there is USB messages or data transferred, and SUSPI when the controller can be suspended.  (At 480 Mbit/s high-speed, SOF would occur at 125µs intervals.)  I would use one of the timers and a timer interrupt for the blink interval (at half the interval, toggling the LED at 50% duty cycle), simply because it would be the simplest and easiest way to do it.  Essentially, it is just a bit of logic on to of the suspend/wakeup state, plus the "blink afterwards for N seconds".

Thus, on some devices, like the card readers and memory sticks I have (but not the ones magic has), and on many USB hub chips like Microchip USB251xB, the firmware uses the suspend/wakeup state directly.  (Even the hub chips have some firmware, although it typically is in ROM and not changeable, with just some configuration data in Flash.)  On the others, and on microcontrollers with native USB interfaces, the firmware can implement more complex indicator patterns on top of the suspend/wakeup status, and of course actual data transfers (specifically on the bulk endpoints).

One important detail not yet discussed: The USB storage device or card reader does not know the state of the filesystem at all on any point, because it is all controlled by the host operating system.  To the device, it is all just unorganised data.  Thus, it is impossible to make a reliable indicator on the USB device that would say whether it is safe to detach the device, without interaction with the operating system!  On certain common filesystems like FAT and exFAT it might be doable in theory, but technically, it is not possible without help from the OS.  Fortunately, current operating systems try quite hard to flush modified data to any and all removable filesystems without leaving the removable device idle for more than a fraction of a second, so in practice, it tends to not be a problem: when the activity ceases for at least a second or two, all changes ought to have been written to the device.

[amyk]

One important detail not yet discussed: The USB storage device or card reader does not know the state of the filesystem at all on any point, because it is all controlled by the host operating system.  To the device, it is all just unorganised data.  Thus, it is impossible to make a reliable indicator on the USB device that would say whether it is safe to detach the device, without interaction with the operating system!  On certain common filesystems like FAT and exFAT it might be doable in theory, but technically, it is not possible without help from the OS.  Fortunately, current operating systems try quite hard to flush modified data to any and all removable filesystems without leaving the removable device idle for more than a fraction of a second, so in practice, it tends to not be a problem: when the activity ceases for at least a second or two, all changes ought to have been written to the device.

I have some old USB drives whose activity light is programmed to stay blinking for ~5s after the last write received on the USB bus - during which it buffers the data and doesn't actually write to flash until almost near the end of that interval, saving the wear of unnecesary erase and write cycles (e.g. if some application decides to do lots of tiny writes over a short time, instead of one big write.) I noticed this because a single sector read causes a brief flash of the LED, while a single sector write makes it stay blinking for 5s. There are also a few large capacitors visible through the transparent case, which I suspect may be to flush the data to flash upon unexpected power loss. Of course these are not very high capacity (the biggest is only 512MB) but they were made at a time when companies cared more about making a good product over absolute profit (SLC flash rated for more TBW than some modern small QLC SSDs, and even after which it'll still retain data for 10 years.)

[radiolistener]

Virtually all of them implement standard USB Mass Storage class, so they look like pendrives basically and use no special drivers. Storage Class has no concept of blinking LEDs, this is done by the device itself on its own.

Yes, it is possible that it can be controlled with firmware on MCU side and the driver code on PC side don't involved in LED control. But I remember some driver code which controls GPIO LED from driver side... But it also possible that the code that I remember was for Ethernet LED's, unfortunately I don't remember details. I remember it because it allows to implement user defined function for the LED on the driver code from PC side.

[prabhatkarpe4]

Why don't you share a schematic for this?

I need to make this happen using a MOSFET. Is it possible?
 

[tooki]

Why don't you share a schematic for this?

I need to make this happen using a MOSFET. Is it possible?

It sounds to me like you don't even understand the discussion that's going on, because if you did, you wouldn't have asked. You've been told repeatedly that it can't be done.

Why is it you "need" to make this happen with a MOSFET? Is it a school homework assignment?

[Nominal Animal]

But I remember some driver code which controls GPIO LED from driver side... But it also possible that the code that I remember was for Ethernet LED's, unfortunately I don't remember details. I remember it because it allows to implement user defined function for the LED on the driver code from PC side.

Even in that case, the driver communicates with the device firmware to change the LED.  That is, there is no way for the host to control the LED directly, only via the device firmware.  Some firmware can simply offer the option for the host to modify the LED states via some kind of control messages, that's all.

Compare to for example keyboards, and their Caps Lock and Num Lock LEDs.  While the keyboard is in control of these LEDs, it does convey their state changes to the host, and both PS/2 and USB HID have controls so that the host can change the LED state (which naturally also affects the logical Caps Lock/Num Lock states).  For USB HID, see USB HID Usage Tables (PDF v1.5), LED Page (0x08) for further details.

For Ethernet (over USB), see Communications Device Class (CDC, PDF v1.2) Ethernet Control Model (ECM) protocol (currently in ECM120.pdf in the previous ZIP archive).  If I recall correctly, it does not have any activity LED controls at all (so those would have to be driver-specific extensions), and the LEDs are fully controlled by the device firmware.

Why don't you share a schematic for this?

For the USB2512B/USB2514B hub based approach via EasyEDA (for manufacturing and assembly at JLCPCB, or PCBWay or similar services), I could; it's just that you don't seem to be genuinely interested in the topic, and only interested in achieving some specific goal which has little or nothing to do with electronics.

Like tooki above, I suspect this is purely an assignment you cannot or do not want to do yourself, and are looking for others to do it for you.  If you admitted to it, we could help you learn how to do it yourself, but we'll never ever do it for you.

I need to make this happen using a MOSFET. Is it possible?

Only in a half-assed stupid way that only works in specific circumstances, by picking a MOSFET (or a set of MOSFETs for a slightly better but still fakey design) whose gate threshold voltage V_GS(th) matches your needs; noting that it isn't actually a threshold per se, but a curve.