Jump to content

How big of a tire can fit on a stock 97 tahoe?


Recommended Posts

Posted

Sorry, I am sure this has been posted probably a ton, but I didn't see a post about it and I am new here.

 

I have a 97 Tahoe LT (if that matters) 4X4 The stock size was 245/75/16's and I know 265/75/16's will fit but I was wondering if 285/75/16's will fit?  I would not mind having to crank up the torsion bars to make the fit if I have to.  I was wanting to crank them up about 2" and put 2" lift blocks on the back (I know this is not the best way but I plan to add a leaf to get this lift later)  With these mods will 285's fit on the stock rims? and not rub (or atleast not rub to bad).

 

Thanks.

Posted

You may have to trim the airdam a little.

 

The tires are a little big for the stock rims and some tire shops may not want to install them on those rims, but alot of people are running 285's on stock wheels and are claiming they have no handling or wear problems.

 

And yes, going +2 in tire size will reduce performance, especially when towing.  Alot of Tahoes seem to have 3.42 rear gears in them.  That is not enough gear IMO to go +2 on tire size and still have plenty of power for towing.  If you have 3.73's you will be better off.

Posted
My 95 Yukon with a 3" body lift scrubs with 33/12.50R15's over bumps and driveway inlets with the wheels turned more than half way in either direction.  The 33's are pretty close to the height you'd be at with 285's, but the reason they scrub is more due to the width than the height.  It has 3.73 gears and cannot pull a grade on the highway and maintain 70 mph without shifting down.  I am so annoyed with the lack of power that I'm planning on downsizing my tires in the near future.
Posted

Mr Dave, first (if I am not mistaken) you are also on the corvette forum!  I have a 84 vette and post over there from time to time.

 

Second I have a freind with a 96 tahoe 3" body and the bars cranked up and it rubs to on tight turns but I also think its due to the width.  But I think I may just play it safe and go with the 265's since I plan to tow (though we towed my stang with his with 33's thru the mountains and had no problem).

 

Still debating I would like more opinions Thanks.

Posted
Mr Dave, first (if I am not mistaken) you are also on the corvette forum!  I have a 84 vette and post over there from time to time.

Yep thats me!   :eek:   I recognized your username from the forum too.  We must have the same taste in transportation.   :eek:   Although I sold my little gray 5.0 to get the SUV.  Now all I need is a car trailer to start hauling my old LeMans to the body shop so I can get it going.

Archived

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

  • Latest Articles

  • Posts

    • Batteries don’t always show signs of a few years ago my vehicle started fine in the morning and took me to work. After work the battery was completely dead and I needed a jump. No, I didn’t leave anything on and the battery was only a couple months old. It was replaced under warranty. 
    • AFM is confirmed in the Corvette engine, so I'm assuming the higher volume trucks will get it as well
    • If his battery was that bad I would think it would have been showing signs before this that were ignored. Stinks that it happened the way it did in rush hour traffic, but this seems like a pretty fringe scenario. I don't mind it that bad and never turn it off. The only slight annoyance for me is the slight delay between brake to gas, but I have gotten used to it and figure if it can save a little gas why not.
    • That is a good correction. I think “severity” was probably the wrong word for what I meant. What I really mean is closer to event priority, relevance, and actionability — not “this code is severe” or “replace this part.” I agree that a truck can have a lot of trivial or historical communication codes, and if the product starts pushing alerts for every stored or low-value event, people will ignore it very quickly. So the alert logic would need to be filtered. For example, I would not want a random old communication code to generate a push notification by itself. A useful alert would probably need to be based on things like: - new vs historical - active vs stored - repeated vs one-time - duration of the event - whether it happened near the driver-marked symptom - whether it happened together with voltage drop, reset, bus-off, misfire, oil-pressure change, etc. - whether the same pattern repeats under similar conditions So instead of saying “severity,” maybe the product should organize events by affected system and priority. For example: Misfire event: Show misfire counts / roughness first, then fuel trims, RPM/load, DFM/AFM state if available, coolant/oil temp, voltage, and related DTCs. Oil-pressure event: Show oil pressure first, but only in context — RPM, load, oil temperature, coolant temperature, DFM/AFM state if available, voltage, and baseline comparison. Communication event: Show which module/network/message dropped, whether voltage dropped, whether the recorder reset, whether it was active or historical, and whether it repeated. Voltage/reset event: Show battery voltage, crank/wake/sleep state, module reset, communication dropouts, and what came back online first. That also solves the display-order problem you mentioned. The main report should not always show the same fixed list first. It should show the system that appears abnormal first, and then the supporting values for that system. I also agree that the truck already has an oil pressure gauge and MIL. The point would not be to duplicate those. The value would be in showing what else was happening before and after the warning or symptom. For example, if the MIL comes on for a misfire, the truck already told the driver there is a problem. The useful part would be: - which cylinder or bank looked abnormal first - whether it happened after an AFM/DFM transition - whether fuel trims were already moving - whether oil pressure or voltage changed at the same time - whether the same pattern happened previously without a MIL On the OBD port point, I think you may be right for a consumer-facing version. OBD is much easier for the average owner: - easier install - easier removal - inside the cabin - easier phone connection - easier data download - easier to include a pass-through port for another scanner OBD is also the right place for DTCs, freeze frame, VIN, calibration information, Mode 6, and normal scan-tool parameters. The reason I was looking at ECM-side recording is that some events may be gone by the time someone plugs in a scanner, and some powertrain-side network evidence may not be available the same way through the DLC. But I agree that if an OBD-based version can capture enough useful evidence for most owners, that is probably the cleaner consumer product. Maybe the split is: - OBD/DLC version for most consumers - ECM-side version only if it proves it adds evidence that the OBD version cannot get - shop/pro version if deeper powertrain-side event evidence is actually useful So I would not want to force the inline approach if the OBD workflow solves most of the real-world problem. Your last point is probably the key product requirement: the report should be specific to the system showing the abnormality. Not “here are 50 parameters.” More like: “Misfire-related event detected. Here are the misfire/fuel/DFM/context values.” or “Oil-pressure-related event detected. Here is oil pressure compared with RPM/load/temp/baseline.” or “Communication event detected. Here is what dropped, when, and whether voltage/reset happened first.” That is a much better way to think about the report.
    • It was all part of the tiny bit of fuel savings it goes towards what was mandated by the government. Much like cylinder deactivation. That was relaxed by the recent administration. All that doesn’t help the individual buyer. But as a whole helps the manufacturer to try to reach the previous ridiculous past mileage per gallon mandate. So yes it was mandated and added cost to the vehicle. 
  • GM-Trucks.com Clubs

  • Popular Contributors

×
×
  • Create New...