Jump to content

GMC Sierra aftermarket headlights/LED DRL's

maxum3300

By maxum3300
in Modifications & Accessories

Recommended Posts

maxum3300 Enthusiast

maxum3300

Posted
Posted

Hey guys, I have a 2015 GMC Sierra which has the single projector bulb that works double duty as the DRL, low and hi beam. I like the look of the 2016 Sierra headlights with the LED DRL but dont want to convert to the OEM 2016 Sierra lights is too expensive. I found these on ebay so I purchased them. http://www.ebay.com/itm/381738373248?_trksid=p2057872.m2749.l2649&ssPageName=STRK%3AMEBIDX%3AITThere are hundreds of these lights on ebay and amazon that all look identical but different brands. They are probably all made by the same manufacturer and branded with different names. I thought this was exactly what I was looking for until I read a review on amazon where a customer states he was disappointed to find out the LED tube light does not function as the DRL but only comes on with the parking lights. I emailed the seller and he confirmed that the LED's do not function as DRL's even though the title says "LED tube DRL". I have not received the lights yet as they are still in route. They have been shipped but have not arrived yet. There is a picture that shows the rear of the light assembly and the wiring. My question is if I can locate the DRL power wire and the LED power wire couldn't I just cut the wire to the DRL and tap it to the LED power wire so the LED would work as the DRL?

arcasey Enthusiast

arcasey

Posted
Posted

I wouldn't jump right in and do that. LED's typically draw less voltage than incandescent or halogen bulbs. If you connect the LED's that are designed to run on 5V to a 12V power input you may burn them up. I know most of the swaps that are being done require another headlight harness for everything to function properly.

maxum3300 Enthusiast

maxum3300

Posted
  • Author
Posted

I wouldn't jump right in and do that. LED's typically draw less voltage than incandescent or halogen bulbs. If you connect the LED's that are designed to run on 5V to a 12V power input you may burn them up. I know most of the swaps that are being done require another headlight harness for everything to function properly.

All LED lights require some sort of driver board. I would imagine the voltage going into the driver would be 12 volts and the driver would step down the power. I may be wrong but i believe LED's run on AC current and the driver converts the 12 volt DC to AC. The more I think about this I could probably just run a wire from a switched source in the fuse box to the LED tube light.

CaptainMcFunk Enthusiast

CaptainMcFunk

Posted
Posted

i'd say do it, people swap incandescent bulbs for led bulbs all the time, so you should be able to just swap the power wire over and be good to go.

arcasey Enthusiast

arcasey

Posted
Posted

All LED lights require some sort of driver board. I would imagine the voltage going into the driver would be 12 volts and the driver would step down the power. I may be wrong but i believe LED's run on AC current and the driver converts the 12 volt DC to AC. The more I think about this I could probably just run a wire from a switched source in the fuse box to the LED tube light.

 

You are correct, but the drivers may not be able to accept the higher voltages. All I am saying is use caution. A friend of mine burned up an LED strip on a Dodge Durango trying to install an emergency flasher module. He installed the module and connected a 12V input power signal to the LED power wire and it flashed 3 times and has never worked since. Also, another example of what I'm talking about would be some of the Steamlight flashlights, specifically the Protac HL line. The HL and the HL3 are designed to run off two and three CR123a batteries. Streamlight has recently produced a HL4 which is designed to run off 4 CR123a batteries. Streamlight also designed the HL4 light to accept two of their 18650 mAH Lithium Ion batteries that produce a voltage of 3.7V each. The CR123a only produce 3V. Just this small subtle increase in voltage is enough to burn up the electronics inside the HL and HL3 lights that are not designed to run at the increased voltage.

 

Replacing "Bulbs" is not an issue because most of the replacement bulbs are designed to be run with a 12V input. What I was really trying to warn you of is connecting the LED tube inside the Headlight Assemblies directly to a 12V input because I don't think the LED strips are designed to run at 12V in the stock LED DRL Headlights. Again I could be wrong, going solely off of memory here.

 

A trick you can try to make the LED strips work if they are not designed to run on a 12V input is you can install a resistor inline to bring the voltage down to the required level. This is based on the principle of Ohm's Law (Voltage = Current * Resistance).

maxum3300 Enthusiast

maxum3300

Posted
  • Author
Posted

You are correct, but the drivers may not be able to accept the higher voltages. All I am saying is use caution. A friend of mine burned up an LED strip on a Dodge Durango trying to install an emergency flasher module. He installed the module and connected a 12V input power signal to the LED power wire and it flashed 3 times and has never worked since. Also, another example of what I'm talking about would be some of the Steamlight flashlights, specifically the Protac HL line. The HL and the HL3 are designed to run off two and three CR123a batteries. Streamlight has recently produced a HL4 which is designed to run off 4 CR123a batteries. Streamlight also designed the HL4 light to accept two of their 18650 mAH Lithium Ion batteries that produce a voltage of 3.7V each. The CR123a only produce 3V. Just this small subtle increase in voltage is enough to burn up the electronics inside the HL and HL3 lights that are not designed to run at the increased voltage.

 

Replacing "Bulbs" is not an issue because most of the replacement bulbs are designed to be run with a 12V input. What I was really trying to warn you of is connecting the LED tube inside the Headlight Assemblies directly to a 12V input because I don't think the LED strips are designed to run at 12V in the stock LED DRL Headlights. Again I could be wrong, going solely off of memory here.

 

A trick you can try to make the LED strips work if they are not designed to run on a 12V input is you can install a resistor inline to bring the voltage down to the required level. This is based on the principle of Ohm's Law (Voltage = Current * Resistance).

 

Thanks for the info but it's not an issue now. I'm buying a set of SLT lights from another forum member from this site. Thanks.

Archived

This topic is now archived and is closed to further replies.

Go to topic listing

  • Latest Articles

  • Posts

    • SFC Retired
      2023 DRW Wheel Liners

      By SFC Retired · Posted

      Did have to make 1 modification because of the WeatherTech rear mud flaps and that was needing 3 longer screws than what came with the install package. 😄
    • SFC Retired
      2023 DRW Wheel Liners

      By SFC Retired · Posted

      Picked up the liners yesterday. Installed passenger side WITHOUT any modifications. All mounting holes lined up perfectly. Rain is interfering today with drivers side. Very Happy! Will add pics when finished
    • KARNUT
      OCI, not when but why?

      By KARNUT · Posted

      As a matter of amusement I’ll leave this conversation with this. Do you beat the government average fuel estimate? Statistics are a guide to me. Not a rule. Someone once said I have to have the last word. If true and possible may be. I’ll blame that on working in a family business.
    • bluev8
      Intermittent no-code issues on 2022.5+ V8 trucks — what did the shop fail to capture?

      By bluev8 · Posted

      That is a fair point, and I agree that trying to log “everything in the truck” would be the wrong direction.   There are a lot of modules and a lot of traffic. If the product became a full-truck datalogger, the amount of data would get huge very quickly, and most owners would never use it.   I think the first useful version would need to be narrow: - powertrain-side event evidence - selected high-value parameters - communication / voltage / reset events - pre/post event window - short report first, raw log only as backup   One distinction I should make is between active OBD/PID polling and passive bus capture. If you are polling PIDs through OBD, then yes: the more parameters you request, the lower the effective sample rate becomes, and you are adding diagnostic traffic to a vehicle that is already busy running itself. With passive CAN capture, the recorder is not asking all the modules for data. It is listening to traffic that is already on the bus. So it does not consume vehicle bus bandwidth in the same way that a scan tool polling hundreds of PIDs would. But your point still applies in a different way.   Even if passive capture does not add bus traffic, the recorder still has limits: - processing rate - storage rate - timestamp accuracy - decoder workload - event filtering - report size - user attention span   So the answer cannot be “log everything and let the user figure it out.” The product would need to store enough raw evidence to be useful, but only decode, graph, and present the important parts around the event.   A practical report should probably show: - what triggered the capture - how much pre/post data was preserved - which selected parameters changed - how those values compared to baseline - whether the same pattern happened before - whether any voltage, reset, bus-off, lost-message, or communication fault occurred - selected graphs around the event - raw data only as supporting evidence   So I agree with you. More data is not automatically better. The real product is the reduction from raw data into a useful event report.
    • bluev8
      Intermittent no-code issues on 2022.5+ V8 trucks — what did the shop fail to capture?

      By bluev8 · Posted

      That makes sense, and I agree with most of that.   I think the product would need both: 1. a default powertrain template, so it is useful out of the box; 2. user-selected priority parameters, so the owner or shop can choose what they want to see first.   Different users are going to care about different things. One owner may care about oil pressure and voltage. Another may care about misfire trend, AFM/DFM behavior, or U-codes. A shop may want communication events and repeatability first. Your baseline point is probably the most important one. Raw data is not very useful unless the report can show what normal looked like for that vehicle under similar conditions.   The way I would think about it is: - start with a basic known-good baseline - learn normal behavior for that specific vehicle over time - allow the event to be overlaid against baseline - show whether the event was a one-time spike or a repeatable pattern - provide a simple severity level, but with clear limits on what that severity means   For example, early severity could be something like: - Info: event captured, no obvious abnormal pattern - Watch: value moved outside baseline, but not repeated - Warning: repeatable abnormal pattern under similar conditions - Critical: communication loss, voltage drop, bus-off, reset, or severe repeated event   I would not want the first version to say “replace this part.” That would be overclaiming unless there is repair-confirmed data behind it. It would be more honest to say “this pattern deserves inspection.”   On the OBD port question, I think OBD absolutely has a role. OBD is probably the right place for: - DTCs - freeze frame - VIN - calibration information - normal scan-tool parameters - Mode 6 / enhanced diagnostic data if available The reason I am still looking at an ECM-side recorder is that the failure may happen before anyone connects a scan tool. If the owner plugs in a scanner after the event, the pre-event evidence may already be gone unless the ECU happened to save it. So I do not see this as “OBD versus ECM-side.” I see it more like: - ECM-side recorder: always armed, rolling buffer, event evidence - OBD/DLC companion: DTCs, freeze frame, VIN, calibration, normal scan data - phone/cloud: status, notes, upload, report generation, notifications   I agree that phone connection and push notifications would be useful. I just would not want the phone or cloud connection to be required for capture. The recorder should save the event locally even if the phone is not connected. The phone should help with event marking, download, notes, upload, alerts, and report viewing.   For a default GM V8 event report, would this list make sense? - RPM - calculated load / MAP - throttle position - vehicle speed - gear / torque converter state if available - coolant temperature - oil pressure - oil temperature if available - battery voltage - commanded AFM/DFM state if available - actual AFM/DFM state if available - misfire counters / roughness by cylinder if available - fuel trims - relevant U-codes / communication events - bus-off / lost periodic message / module reset / voltage drop events Which of those would you remove, and what would you add?

  • GM-Trucks.com Clubs

  • Popular Contributors

×
×
  • Create New...