1998 Civic: code P0171: fuel pressure regulator?
in [Technical]
|
Prev: GOODYEAR settles lawsuits
Next: Toyotaâs Chief Test Driver Dies inCrash in Germany. BMW occ...
From: Tegger on 1 Jul 2010 19:12 Kaz Kylheku <kkylheku(a)gmail.com> wrote in news:20100702015602.11(a)gmail.com: > On 2010-06-30, jim beam <me(a)privacy.net> wrote: >> On 06/30/2010 12:41 PM, Kaz Kylheku wrote: >> 1. because of the age of the vehicle, i'd go to >> http://oxygensensors.com/ and get a new oem sensor - ngk or denso, not >> bosch on a honda. > > I put in my vehicle info, and that site didn't come up with > any NTK/NGK sensors, just Walker, Denso and Delphi. Hmm. > > That site has free shipping in the US; I'm in Canada. They will > undoubtedly slap on at least 15 bucks for shipping here, if they even > ship here at all. Plus, by the time the item arrives, I will waste at > least another $20 in excess fuel consumpion! On a tank, it goes less > than 400 km, whereas it should be closer to 600. 250 miles versus 400. > > Better idea: yesterday afternoon I went to Vancouver Auto Parts > and got a made-in-Japan NTK sensor for $78 + tax, and installed it right > away. Now it drives better, and the smell of unburned fuel in the > exhaust is gone. Haven't seen any rough idling or power dropout. > > I will wait for the MIL to go off after a few drives. If not I will > reset the codes and see whether they reappear. You should reset the ECM /now/. That way you'll know for sure if any subsequent codes are set that are separate from the current P0171. And if it's fixed, it's fixed; that's a good thing. But if you were smelling raw-gas out the tailpipe, I would have been expecting fuel-trim and/or misfire codes in addition to the lean code. -- Tegger
From: jim beam on 1 Jul 2010 21:43 On 07/01/2010 03:09 PM, Tegger wrote: > "E. Meyer"<epmeyer50(a)msn.com> wrote in > news:C852426C.1CF3F%epmeyer50(a)msn.com: > > >>> >> >> Honda DOES use P0170. It is the "Temporary DTC" for both P0171 and >> P0172. This according to the FSM for the '00 Acura TL. >> >> > > > > That's odd. > > I have TSB 03-020. This is Honda's official OBD-II DTC list as of > March 29, 2003. > > The TSB specifically says: > "This is a list of all DTCs for all OBD II models. No one model has all > these DTCs." > > P0170 is NOT listed. > > Can you give some details on the "Temporary DTC" thing? > > it's a "P0" universal code which applies to all obdII vehicles tegger, not a honda-specific code like "P1", etc. -- nomina rutrum rutrum
From: Kaz Kylheku on 2 Jul 2010 11:11 On 2010-07-01, jim beam <me(a)privacy.net> wrote: > On 07/01/2010 10:19 AM, Kaz Kylheku wrote: >> On 2010-06-30, jim beam<me(a)privacy.net> wrote: >>> On 06/30/2010 12:41 PM, Kaz Kylheku wrote: >>> 1. because of the age of the vehicle, i'd go to >>> http://oxygensensors.com/ and get a new oem sensor - ngk or denso, not >>> bosch on a honda. >> >> I put in my vehicle info, and that site didn't come up with >> any NTK/NGK sensors, just Walker, Denso and Delphi. Hmm. >> >> That site has free shipping in the US; I'm in Canada. They will >> undoubtedly slap on at least 15 bucks for shipping here, if they even >> ship here at all. Plus, by the time the item arrives, I will waste at >> least another $20 in excess fuel consumpion! On a tank, it goes less >> than 400 km, whereas it should be closer to 600. >> >> Better idea: yesterday afternoon I went to Vancouver Auto Parts >> and got a made-in-Japan NTK sensor for $78 + tax, and installed it right >> away. Now it drives better, and the smell of unburned fuel in the >> exhaust is gone. Haven't seen any rough idling or power dropout. > > ok, good. > > >> >> I will wait for the MIL to go off after a few drives. If not I will >> reset the codes and see whether they reappear. > > you should just reset them. if they re-appear, that's when you go to > the next stage in diagnosis. Yay! Went out by itself yesterday while driving: zero effort. Bring laptop to car, plug in cables, fiddle with software: nonzero effort. It's more satisfying if the MIL goes out by itself. The ECU diagnosed it, let it confirm the fix. You never know; the threshold standard for confirming the fix may be stronger than the standard for merely not flagging a recurrence. Hysteresis is an obvious design choice for this kind of thing. If alarms are programmed trigger and clear on the exactly the same threshold, then they will tend to flip-flop. Suppose that, in a device, flomposity values greater than 19.7 trigger an alarm, and your fix reduces flomposity values to 19.2 percent. If you reset the alarm, it does not re-trigger. But suppose the management software requires a flomposity level of less than 10 percent in order to clear the alarm spontaneously. If you get it to do that, it's a better fix.
From: jim on 2 Jul 2010 11:43 Kaz Kylheku wrote: > > You never know; the threshold standard for confirming the fix may be > stronger than the standard for merely not flagging a recurrence. > Hysteresis is an obvious design choice for this kind of thing. > > If alarms are programmed trigger and clear on the exactly the same > threshold, then they will tend to flip-flop. > > Suppose that, in a device, flomposity values greater than 19.7 trigger > an alarm, and your fix reduces flomposity values to 19.2 percent. If > you reset the alarm, it does not re-trigger. But suppose the > management software requires a flomposity level of less than 10 percent > in order to clear the alarm spontaneously. If you get it to do that, > it's a better fix. I'm not sure that is the case, but your general idea is more or less correct. To set the codes in the first place requires the fault to occur in two consecutive driving cycles. To clear the code also requires 2 or 3 driving cycles without a fault. So having the light go out by itself is a stronger indication that it is working properly consistently even if the threshold for a fault is the same (which it probably is). -jim
From: Bob Cooper on 2 Jul 2010 13:59
In article <Ub2dnRMTNuetlLPRnZ2dnUVZ_qidnZ2d(a)bright.net>, "sjedgingN0Sp"@m(a)mwt,net says... > > Kaz Kylheku wrote: > > > > > You never know; the threshold standard for confirming the fix may be > > stronger than the standard for merely not flagging a recurrence. > > Hysteresis is an obvious design choice for this kind of thing. > > > > If alarms are programmed trigger and clear on the exactly the same > > threshold, then they will tend to flip-flop. > > > > Suppose that, in a device, flomposity values greater than 19.7 trigger > > an alarm, and your fix reduces flomposity values to 19.2 percent. If > > you reset the alarm, it does not re-trigger. But suppose the > > management software requires a flomposity level of less than 10 percent > > in order to clear the alarm spontaneously. If you get it to do that, > > it's a better fix. > > I'm not sure that is the case, but your general idea is more or less > correct. To set the codes in the first place requires the fault to occur > in two consecutive driving cycles. To clear the code also requires 2 or > 3 driving cycles without a fault. So having the light go out by itself > is a stronger indication that it is working properly consistently even > if the threshold for a fault is the same (which it probably is). > The big difference in clearing the code yourself vs letting the ECU do it is you immediately know that your fix worked, and you don't have the CEL shining at you for the cycles it takes to shut off. It is not my experience that it requires 2 consecutive driving cycles for the code to set. I have cleared codes and they reappear immediately upon restart. They probably get set according to the polling timing of the ECU. I don't see a reason for error codes to have ranged on/offs. You have an error when you hit a single point of measurement. If it is due to intermittent conditions it may turn off. Every o2 sensor error I've had, the code remained until the sensor was replaced. Just my experience. A home thermostat has a ranged on/off to reduce cycling, a safety valve has a ranged pop/reseat to reduce chattering. But for ODB an error is just an error in my experience, and if the CEL stays on something needs fixing or replacing. It never finds another point of measurement lower than required to set the code. But that's for a single code. Maybe some sensor errors cause other sensor errors to appear for good sensors. That may be classified as an intermittent code for the good sensor until the bad sensor is replaced. I do know that unplugging the TCC connector on some TH125 transmissions can cause the first and second gear sensors to throw their error codes, even though the trans is working fine without the lock-up. Those I usually call permanent intermittent codes. |