That "might" depend on what code reader/scanner was used. Generic or even ones claiming to cover Ford's extended codes don't even cut it now a days.

 

Did the DTC check with the FEH's own readout not a scanner.

 

That's a good thought to check for codes. I never did that. I have a scangauge hooked up but I never did a code scan after that odd thing happened. I'll check it today... Kind of doubt that I'll find anything but it's worth a scan to see if PCM saved something.

Is there a recommended thread that shows where to check grounding locations (other than the 12V battery cable)?

 

The Shop Manual Wiring Diagram booklet has the ground points. When I started running parallel ground paths on my Suburban I went to certain ground points and cleaned them up and then ran a 14 gauge wire from one to the next. Seemed to do some good.

Also, after three start-warmup-stop cycles the systems clears DTCs if the fault has been cleared (or just disappeared). This is what baffles me about the SES light on my FEH: there were no DTCs stored and there had not been the three start-warmup-stop cycles to clear them.

 

Bill, the only way I know of to retrieve the DTC for the wrench light is with a scangauge X-gauge code. I was able to pinpoint the traction battery blend door issue this way. BillyK has a plethora of those X-gauge codes posted on a sticky in this forum. If you haven't invested in the SG yet I would highly recommend it. It's actually kind of fun to monitor the different systems and see what makes this thing tick.

I wasn't aware of the three start thing... I guess that might explain why I didn't see any codes when I checked... That or there never was a code to read.

 

Hold down the trip odometer reset button and turn the ignition key to run but not start. Then sit back and watch. This'll begin a sequence that checks all lights then runs through the software codes and then tells you what DTCs are stored (if any - amongst many things). After the initial sequence checks of the lights & needles, you have to push the reset button to move to the next item in the sequence.

 

You have missed the obvious, and I'm surprised at Bill because he usually points these things out.

The 4% ( or 98%) you see on the scan gauge is just a number... a few bits of data.
The number displayed has NOTHING to do witn the actual health, or state of charge of the battery. The scangauge is a Computer. Have you ever had data corruption on your computer? Ever get an incomplete download from the internet?
No different here.

We'd like to think we se actual data... data that means something, but this is an illusion.
Even the temperature reading is not really temperature, it is a computer sending voltage to a resistor, and measuring voltage drop. The temperature is inferred from voltage.

The 4% did not mean 4% from dead. Just 4% from some arbitrary zero referance.
The whole point of the recalibration exercise is because the computer lost confidence in where "zero" was. But in this case zero cam mean Lowest allowed to go to hold enough reserve power to start.

Let me put it this way... Even if the charge meter was 99.9% accurate, over a year, it could display a number that was 33% in error from actual reality.
It is counting watts in, and watts out, just like balancing your checkbook.
However... some watts go into heat, not charge, and the computer cannot account for those missing watts.

Hence, the recalibration event is like a stress test, a bench test to see the actual health of the battery. It is much more visible the Honda Hybrids. The charge meter can go from full to empty in a few seconds as the computer goes "Ops... I thought the battery was full, but voltage drop while accelerating (stress test) indicates otherwise."

Hope that helps. ( your battery did not drain overnight )
John

 

You seem to be implying that what is shown on the scangauge is not real. It may not be accurate based on the interruption of the calibration event... That makes some sense. What is shown on the scangauge is exactly the data that the computer is seeing (and believing). That explains the strange behavior of the ICE on start up. It's misleading to say that scangauge data in general may be completely inaccurate. Unless the scangauge, or a sensor is malfunctioning (possible) the data is representative of exactly what the computer is reading. I don't know that we can say that the battery did not discharge over night either. Obviously there was a significant loss of voltage from the time that data was last read by the computer or the gauge would not have read what it did. I agree after your explanation that it may not have actually lost so much voltage as what the SOC was showing, however, the computer was seeing exactly what I was seeing and generated some strange behavior just after initial start up as a result. The behavior adjusted only after I put it in park and waited for 10-15 seconds. Whatever occured, it wasn't a typical calibration event from my experience anyway. This was the first time I have ever interrupted the sequence at any point in the calibration cycle. In this case I interrupted it twice due to short trips into town. I won't be doing that again if I can help it.

Your explanation is certainly plausible; the computer may have lost track of where it was during the discharge cycle and thus displayed a "best guess" based on where it left off. Whatever the case, 4% SOC was displayed and the "bits of data" that generated that reading were the same bits that the computer was reading. Possibly what you're saying is that there's a question as to whether or not the computer sees those bits as 4% or 20% or ?

 

Sorry, you may have a good idea about how the computer works, but you don't understand how sensors work. The temp sensor has a very linear resistance characteristic versus temp. Measure the resistance and you know the temp... actually a very simple concept.

On the battery state of charge, I believe Ford selected the range of the charge/discharge for the NiMH battery for a couple of reasons. One is that the state of charge is very linear relative to voltage. Thus if you know the terminal voltage, you know the state of charge. Again, a simple concept.

 

The scangauge gets data off a CAN bus... a communications path. Think of ethernet, only different protocol. You can define priorities to devices attached to the CAN bus. The scangauge is a low priority device. It gets it's needs taken care of last. You may think it is just tuning in to what is there, like tapping a phone line... or listening to the radio. This is not how it works. The scangaug must "ask" for each piece of data, and the device on the other end must respond. There are several devices or modules that can respond, if the scagauge knows who to ask. It is a two way conversation and that takes up bandwidth, and the scangauge is asking the questions say, once per second, and multiple questions at that. If the bus is busy, the scangauge is ignored.
Mine get corrupt or incomplete data sometimes ( water temp -40F ) and sometimes a value gets "stuck" or frozen from time to time for a few seconds. I'm not saying this is exactly what you saw, just don't put too much trust in the number.

The FEH can charge about 1% every 30 seconds... best case, if you were parked and not driving. How long did it take to ge back to normal of 53%? 49% should have taken the car about 25 minutes to recover from. Longer if you were driving at the time.
If it went quicker, the number you saw was corrupt, not the battery.

As for resistors or thermocouples they drift over time as they age and can be affected by shock, vibration, and extreeme temperatures that permanently change their properties.
Not so linear either. Linear in the range you are interested in, perhaps