So, IF I ever get my RMA'ed board back from Gigabyte
user error, in central EU this would be declined. in US will depend on the retailer and how much they value customers to eat the cost of new motherboard
So, it seems that ASROCK and Gigabyte have this annoying wiring that allows power to bleed back through the DLED 12v+ pin from the motherboard AFTER IT IS TURNED OFF!.
Its not motherboard "allowing" bleed back, its user plugging in something not allowed which pushes power back
Gigabyte doesnt support plugging anything BUT the ARGB leds into their DLED sockets.
"LEDs in Sleep, Hibernation, and Soft Off States
Allows you to set the lighting mode of the motherboard LEDs in system S3/S4/S5 state.
This feature is supported only with a 5V digital LED strip.
Off Disables the selected lighting mode when the system enters S3/S4/S5 state. (Default)
On Enables the selected lighting mode when the system enters S3/S4/S5 state."
= DLED 5V is sourced from ATX Standby to allow LED lighting working while computer is off
, and after contacting Phanteks, the confirmed it
...
Panteks plugged into SATA 5V rail of PSU.
DLED plug fromthe MB plugs into the Phanteks DLED SATA powered HUB (not controller).
....
Anyway, I contacted Phanteks, and they confirmed that the phenomenon I was experiencing was indeed something that will happen using Gigabyte boards, or ASROCK, and why they said the hub was only compatible with MSI and ASUS.
no surprise there, they seem to be selling fluff led gadgets - "hub" being a $20 plastic box with a set of connectors and no active components
like this https://www.aliexpress.com/item/10000095545686.html
proper wiring, or $0.1 diode was out of their budged so its back to the old blame it on the others tactic, nothing wrong with our product no sir :-)
This means when the computer is off, somehow Gigabyte allows power to run BACK through the DLED 12+V pin, and that feeds back to the Phanteks (or any) DLED hub and then from there, feeds back through the SATA connection, and then from there, energizes the SATA 5V rail, and anything plugged into the SATA 5V rail gets low voltage.
You are EXTREMELY lucky you didnt set DLED_V_SW1/DLED_V_SW2 to 12V, that would result in even more smoke, this time from SSD/HDD and power supply.
To solve this problem, I cut the 12v+ wire on teh extension cable that feeds power from the DLED riser on the motherboard, effectively stopping any power from going through one side of the Y splitter. Remember the other side still has power from the DLED riser to power the waterblock and rad fan LEDs.
good
and again: its not 12V+, its whatever you set with DLED_V_SW1/DLED_V_SW2. 12V would be spectacular for a second.
The reason I shared this is becasue I'm wondering if I can do the same thing with the RGB aspect of lighting. I'll just cut the 12+V wire coming from the motherboard RGB extension cable, buy an RGB hub, and use the hub and SATA 5V rail to power the RGB lights. That would allow the PSU to deal with over voltages and stuff like that, which they are capable of doing.
However, DLED has a "data" wire, but I'm not sure how RGB works. If I cut the power cable coming from the MB, how will the signal to change colors get there?
You seem to be learning quickly ![Smiley :)](https://www.eevblog.com/forum/Smileys/default/smiley.gif)
You cant do the same thick because LED_CPU/LED_C RGB connectors are for directly "low-side switching" "common anode" LEDs. First the directly/indirectly switching part:
Indirectly = ARGB are addressable leds, that means you send digital signal and they take care of interpreting it and switching power internally. They have build-in mini decoder and transistors inside the package.
Adafruit tutorial covering WS2811 (they call them neopixels) https://learn.adafruit.com/adafruit-neopixel-uberguide
These are great because all you need to drive them are direct digital control signals, no expensive power transistors requierd.
Directly = transistors are on the motherboard, what you get on the connector is raw power and not the control signals.
project I linked earlier shows how you control analog RGB led strips https://www.instructables.com/id/WiFi-LED-Light-Strip-Controller/ you have to manually modulate power to separate color strands using somewhat beefy transistors.
Low-side switching means you are not PWM modulating the +12V. Instead you are controlling the Ground connection using N-channel MOSFET https://www.electronics-tutorials.ws/transistor/tran_7.html
"common anode" means all the LEDs have their + power wired together.
https://www.hackster.io/techmirtz/using-common-cathode-and-common-anode-rgb-led-with-arduino-7f3aa9
The last part means No, rewiring +12V from motherboard to the power supply wont solve anything because thats not the bottleneck. Bottleneck is tiny, cheap mosfet transistors on the motherboard. What you could do is either buffer analog signals with bigger transistors, or drive them using ARGB decoder like https://www.adafruit.com/product/1378 Im sure someone in china makes a $10 product letting you drive basic RGB strip from ARGB signal.
Hey thanks for all of the comments. I really appreciate it. Very helpful. See below for my replies.
"user error, in central EU this would be declined. in US will depend on the retailer and how much they value customers to eat the cost of new motherboard"
How did you come to the conclusion it was user error? It could have just been bad transistors on the MB? Also, the retailer is Amazon and has absolutely zero to do with the RMA back to Gigabyte. I just wish GB would either fix my board or tell me to kick rocks so I can get on with it.
"Its not motherboard "allowing" bleed back, its user plugging in something
not allowed which pushes power back
Gigabyte doesnt support plugging anything BUT the ARGB leds into their DLED sockets.
"LEDs in Sleep, Hibernation, and Soft Off States
Allows you to set the lighting mode of the motherboard LEDs in system S3/S4/S5 state.
This feature is supported only with a 5V digital LED strip.
Off Disables the selected lighting mode when the system enters S3/S4/S5 state. (Default)
On Enables the selected lighting mode when the system enters S3/S4/S5 state."
I contacted Giagbyte and explained what I was doing, and they never said I could not plug an SATA hub into the DLED when I contacted them, and they never suggested I stop doing it. Gigabyte tech said to make sure the S states are off, which is default, which it was. I explained exactly what I was doing like I did above, and they never once said it should not or would not work. They finally said it was "strange" and they would look into it. Incidentally, ASUS and MSI have not that limitation. Also, it doesn't say anywhere not to use DLED powered hubs. I mean, yeah, what you are saying makes logical sense, but Gigabyte never said anything about it and it's not in the manual.
"proper wiring, or $0.1 diode was out of their budged so its back to the old blame it on the others tactic, nothing wrong with our product no sir :-)"
Well, they didn't deny it was their hub not working. They were really forthright about it. They just said it doesn't work with ASUS/ASROCK for that very reason (Phanteks tech actually said there are other strange things that can happen too, but didn't go into it.).
Actually, they don't even need a .1 diode. They could have just blanked the power connection going into the hub itself, and been perfectly compatible with Gig and ASR boards, and just adding in the manual that power was limited to the SATA power and that the power states options would not work with DLEDs plugged into the controller. I actually told the tech how I got it to work, and he said that was interesting that I got it to work doing only what I did, and that he'd pass that on to the electrical engineer.
"DLED 5V is sourced from ATX Standby to allow LED lighting working while computer is off"
Yes, we figured that out, and by "we" I mean John Gerow over at Johnny Guru who is also Corsair's marketing manger for Corsair PSU. He said the motherboard should stop that no matter what is plugged in.
"You seem to be learning quickly
![Smiley :)](https://www.eevblog.com/forum/Smileys/default/smiley.gif)
"
Necessity is a good motivator--lol. I wish it would just Fing work, you know? I don't want to be an electronics person, although I am learning some really useful and cool stuff. So, there is that! A good positive is that I know how to do some soldering and I am going to put a string of white LEDs in my front room up in the c90 degree roof to wall meeting area using a LED diffuser and a 600 chip per 16' strip that puts out something like 10,000 lumens (Doesn't use 5050). That way can get the room lighting off the floor and get rid of stupid lamps and cords--and have enough damn light finally--my house has no overhead light wiring in the living room.
"You cant do the same thick because LED_CPU/LED_C RGB connectors are for directly "low-side switching" "common anode" LEDs. First the directly/indirectly switching part:"
Right, I kinda got that because RGB is like you said, a dumb circuit. If I cut the power then I get nothing because the MB can't communicate with the strip. I can't even find a 12V RGB hub anyway, and no shit. I'd have to plug the hub into 12V outlet in the PSU, and, where would that be? So, yeah, figured that out.
"You are EXTREMELY lucky you didn't set DLED_V_SW1/DLED_V_SW2 to 12V, that would result in even more smoke, this time from SSD/HDD and power supply.
OK, so I don't know where that setting is, but why would I set a 5V peripheral to 12V? And why would there be such an option in the BIOS? I may be dense, but not shit4brains. I'm not changing anything that says anything about power until I completely understand it.
![Smiley :)](https://www.eevblog.com/forum/Smileys/default/smiley.gif)
" Im sure someone in china makes a $10 product letting you drive basic RGB strip from ARGB signal."
You mean like this?
https://www.amazon.com/DEEP-COOL-Convertor-Motherboard-Non-Compatible/dp/B07QPYSC82 I'm not understanding that thing. Somehow they must connect the DLED data wire to the hub and then convert it, so that the MB/Software can use the 12V riser for 5V DLEDs? I don't understand what it is doing.
"and again: its not 12V+, its whatever you set with DLED_V_SW1/DLED_V_SW2. 12V would be spectacular for a second."
That was my mistake. I didn't cut anything DLED 12V because it isn't 12V it's 5V! I meant I cut the DLED 5V+ power wire, and now the LEDS plugged into the LED hub use SATA 5V power and no MB power. That's what solved the problem, becasue like you said, the data wire is still there.
----------
I still don;t know why the strip would fry the RGB fets, unless there was a bad resistor in the strip or the strip was just defective all the way through it? Couldn't it have been a bad motherboard RGB circuit?