Jump to content

Noise from under driver's seat upon opening door?


Recommended Posts

Posted

I've had my 2018 GMC Sierra SLT for three weeks now.

I noticed there is a whirring sound that comes from under the driver's seat if I unlock it and open the driver's door.  It seems like it happens only after it has sat for a while.  It lasts maybe 3 seconds and sounds like a seat motor.

I have the seat position recall turned off as I am the only driver.

I don't have easy access enabled.

It may not be from the driver's seat, but that's where it sounds like it's coming from.

 

Any ideas?

 

Thanks!

Posted

Fuel pump priming prior to start up? If you close the door and open again and don’t hear the same sound, good chance that’s all it is - totally normal - my truck does it, so does the Ford at work...

Posted

Cool, Thanks guys!

That makes sense.

It just never lasted long enough for me to locate it, and it would only do it once.

Posted

Forgive me, I'm old, and maybe have a warped sense of humor, but with these new vehicles when I read whirring sound, my first thought was hamsters in a cage.  :D

  • 2 weeks later...
Posted

Glad that has been figured out, mine does the same and I been under it and found nothing.  Thanks for the explaining!

Posted

I noticed what looks like a fuel pump on drivers side right in front of gas tank.  I thought fuel pumps were pretty much all in the gas tank anymore.  Maybe that isn't a fuel pump, sure has hoses etc heading to tank.  Just got this truck and trying to figure everything out, not like my old Dodge that I knew every sound and part location. 

Posted

It could be part of the evap setup.  My truck has the evap tank there, with tubes running to the fuel tank and the engine.

Archived

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

  • Latest Articles

  • Posts

    • This video may not be the exact content for the joke thread but its a lot of laughs so here it is, I've only watched a portion of it so far but if anyone is looking for some light hearted good soap box driving action, its here. As a note in the upper left of the screen it shows the number out of 100 to refer back to any particular vehicle for comment !.    https://www.facebook.com/reel/1351928276956715
    • 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. 😄
    • 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
    • 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.
    • 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.
  • GM-Trucks.com Clubs

  • Popular Contributors

×
×
  • Create New...