Jump to content

Recommended Posts

Posted

Hi guys, just looking for some advice. 

 

The issue: I recently had my battery replaced and shortly after this was done my low beams (both sides) quit working. The next day my stereo started turning off and on again, and there's a message on the dash saying "service theft deterrent system" with the lock symbol. I can still drive it though (not at night) and it doesn't lock me out. I checked the fuses and relay for the low beams and they seem fine. I haven't checked the bulbs yet but it seems too coincidental that both would go out at the same time, though I could be wrong. 

 

In case this is relevant info: I had the battery replaced a month ago via AAA, but it turned out to be from a bad batch. It died after a few weeks while I was conveniently at a local shop getting a wheel alignment, so the mechanic there jumped it twice (once to get it onto the rack and another to get it back in the parking lot). They showed me how the interior lights were flickering before shutting it off (I didn't see the headlights at that point).  AAA replaced the battery in the lot after that since it was under warranty. 

 

Any suggestions would be appreciated. I'll take it to a mechanic next week but I wanted to do some research first to see if there's an easy fix I may have missed. Truck is a 2011 GMC Sierra 1500 SLE.  

 

Thanks!

Caitlin

Posted

Welcome to the forum! Is there power at the fuses and relay? I would check in the vicinity of the battery and see if there is a ground or power wire that got broken or has corroded connections. Do the high beams still work? If all that is ok  next step is to determine if there is power and ground at the bulbs before chasing further. Possibly a bad light switch but that doesn't explain the security light

Posted

Thanks :) 

 

There appears to be power at the fuses/relay, but I wasn't 100% sure about the relay so I ordered a replacement -- and I also ordered a circuit tester (both should arrive soon). The high beams appear to work properly.  I'll definitely check around the battery -- I did a quick look last night but the lighting in my garage wasn't too great. Appreciate the help!

Posted (edited)

relay failure is extremely rare, there is usually another of the same relay in the box so  switching them around is an easy way to check them .test light is a very useful tool for doing quick checks of fuses, grounds etc. If the hi-beams work it's probably not the switch. When you get your tester check all the fuses, both fuse boxes

Edited by richard wysong
Posted

Just a WAG but I would look towards the turn signal/high beam switch as the issue. You could pull the relay for the low beams and see if there is a signal to it, compare it to the high beam relay input.

Posted

I would discount the battery from the issue, batteries do not target systems for sabotage; batteries either have, almost have, or don't have enough voltage to do the job. Batteries (like anything else mass produced) can have batch issues so you can't really blame AAA or the battery. I think you got a switching issue; if it's a ground issue clean the grounding point and the terminals on the wires that go there, use dielectric grease to inhibit further corrosion growth.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Latest Articles

  • Posts

    • Monday looks like a good day for the dealer to test an ac issue. Hopefully it all turns out good.
    • Paid $2.72 for E85 today.
    • Welcome back! No, it definitely doesn't pass the sniff test. Even "ceasefire" needs an alternative definition these days.    $5.29 at Kroger today
    • That makes sense, and I think you are describing the real product problem. Capturing data is the easy part. If the owner or technician has to manually dig through five minutes of millisecond-level logs, the product has already failed. The device would be at the ECM harness, not at the OBD port, so I agree that data retrieval and event marking need to be thought through carefully. The way I am thinking about the architecture is: The recorder itself should not depend on a phone, app, Bluetooth, Wi-Fi, or cloud connection to capture the event. It should always keep a local rolling buffer and lock the event locally. A button, phone app, or small cabin device would only act as an event marker. If the driver feels a stumble and presses the button 10–30 seconds later, the pre-buffer has to already contain the useful data. For data retrieval, the practical options would be a sealed service USB lead, Wi-Fi download, or a phone/cabin companion device. I would not expect the owner to remove the ECM-side module or work with raw files directly. The cloud or AI side would be for interpretation, not for capturing the event. The truck may have no connection when the issue happens, so the evidence has to be saved locally first. After that, cloud processing could help decode the data, compare it against baselines, and generate a readable report. For the first version, I would keep the automatic triggers conservative and objective: driver event marker bus-off error passive voltage drop / brownout device reset FIFO or queue overflow a normally periodic message disappearing side-to-side communication mismatch, if the topology supports that For “learning normal,” I agree with your point, but I would not want to overclaim it as automatic root-cause diagnosis at first. A realistic first step would be learned baseline comparison for that specific vehicle and operating condition. For example, a value would only be compared against similar conditions: RPM range load / MAP throttle position gear / vehicle speed coolant and oil temperature battery voltage AFM/DFM state, if decoded and validated Then the report could flag things like: this periodic message disappeared compared with its normal timing this value deviated from this vehicle’s normal range under similar conditions the same abnormal pattern repeated after the same type of event the anomaly occurred together with voltage, oil-pressure, misfire, or communication changes But I would still call that “abnormal pattern detected,” not “replace this part,” unless there is enough validated repair data behind it. So the intended product would not be “here is a huge log.” It would need to be an event package: what triggered the capture how much pre/post data was preserved what changed before and after the event whether the device itself reset, overflowed, or saw a bus error selected graphs around the event raw data only as supporting evidence From your perspective, what would make this kind of report useful instead of just another datalog? For example: What are the top 5 parameters or events you would want highlighted first? Would you trust a learned baseline for that specific vehicle, or would you prefer fixed thresholds? How much false-positive flagging would be acceptable before you stopped looking at the reports? What would a one-page report need to show for an independent shop to take it seriously? For misfire, AFM/DFM, oil pressure, or U-code complaints, what would you want the tool to flag automatically?
    • 2024 Silverado 2500 HD LTZ grille no camera Parts list   84603331 84913656 84913657 84913654 84913655 84911567 84911568 85646092 85646093 85797921 85797922   11570637  x10-15   grille/bumper bolts 11546500  x10      grille clips 11571006  x10      push/retainer clips 11546454  x6       nut retainers 11611609  x6       M5 bolts 11610700  x6       molding/trim retainers
  • GM-Trucks.com Clubs

  • Popular Contributors

×
×
  • Create New...