Archives

There has been some interest in retrieving diagnostic data from the FEH using the ScanGauge, so I thought I'd give a brief description of how to do it. First, start by reading this on SG's web site:

http://www.scangauge.com/support/OBDIITestStatus.shtml

In the FEH Powertrain/Emissions Diagnostic manual, mode $22 PIDs are described on pages 2-12 through 2-16. Unfortunately, scaling and offsetts are not provided, but I have figured most of them out through experimentation. Also unfortunately, I have not found a source for the TBCM PIDs, except for a few.

At any rate, on your ScanGauge press MORE>MORE>CMNDS the default is Memory 0, but you have 10 to choose from. Press EDIT, then enter the mode and PID using the <> and ^ buttons. For example, the PID for the Traction Battery Voltage is $490B in mode $22.
So, use the ^ button to step up to 2, then > and repeat for the next 2, > and ^ to step up to 4, then 9, 0, and B. You should have 22490B in memory 0. Press OK and then SEND. You will get back something like 62490B2E83. The 62490B indicates a repsonse to the request, the 2E83 is the hexadecimal representaion of the voltage. The scaling is .03052 for this PID, so to get voltage you calculate the decimal value and multiply by .03052.
2E83 hex =2*4096+14*256+8*16+3=11907, and voltage =.03052*11907=363.4V.

I can't reliably get the TBCM PIDs, of which SoC is one, with the SG, but I think Ron can figure this out. I will post my list of scaling and offsets for the PIDs, and hopefully they can be verified and/or corrected by the masses.

Luckily, for the Generator and Motor RPM there is no scale of offset.

If you get 0xxx this is forward motor spin.
If you get Fxxx this is reverse motor spin.

And BTW, do you think you can have 16 presets?

In mine, I got it to go 0-9 and A-F.
My A-F were there one day, then whammo... they disappeared.
Wonder if I "unlocked" something.

I also got my SG to display in Chinese and Greek!
( again, I'm not sure how, I was just pressing buttons, and it happened, luckily, I could reset it... )

So looks like Linear Logic sells to the Asian market, as well as Europe!

Hi, Carl.
Today I was thinking, a lot of this information (SoC, battery current, MG speeds, etc.) can be valuable as a real-time feed. Obviously it's impossible for you to program every last parameter for every last car, but what do you think about a "custom" field that the user could experiment with? I guess it's basically the same thing you have now except for updating on its own rather than sending the command and getting a freeze-frame reply back. (I haven't tried it myself but I believe that's how GPSMAN explained it.)

Does that sound totally nuts?

Hi, Carl.
Today I was thinking, a lot of this information (SoC, battery current, MG speeds, etc.) can be valuable as a real-time feed. Obviously it's impossible for you to program every last parameter for every last car, but what do you think about a "custom" field that the user could experiment with? I guess it's basically the same thing you have now except for updating on its own rather than sending the command and getting a freeze-frame reply back. (I haven't tried it myself but I believe that's how GPSMAN explained it.)

Does that sound totally nuts?


I think that is Ron's intention with the firmware upgrade he is working on. In the present gauge mode, he is sending his selected subset mode $01 PIDs as defined by SAE J1979 (see wikipedia). The mode $22 PIDs of J2190 are manufacturer specific, so he will probaly have to make it user programmable, and provide a list on the website if he can legally do so. If you have a SG, an '04 Prius is CAN, so you can send PIDs to see what comes back. After all, since Ford is using Toyota technology, the PIDs should be the same, right?:D

Luckily, for the Generator and Motor RPM there is no scale of offset.

If you get 0xxx this is forward motor spin.
If you get Fxxx this is reverse motor spin.


I thought that I had determined that these were represented by either 1 or 2's complement format; the Fxxx would be an unorthodox method of representing negative numbers and would limit it to 4095 RPM max. I will try driving in reverse and seeing what the TM value comes back as; I may have to change that entry in the excel spreadsheet!

There has been some interest in retrieving diagnostic data from the FEH using the ScanGauge, so I thought I'd give a brief description of how to do it. First, start by reading this on SC's web site:

http://www.scangauge.com/support/OBDIITestStatus.shtml

In the FEH Powertrain/Emissions Diagnostic manual, mode $22 PIDs are described on pages 2-12 through 2-16. Unfortunately, scaling and offsetts are not provided, but I have figured most of them out through experimentation. Also unfortunately, I have not found a source for the TBCM PIDs, except for a few.

At any rate, on your ScanGauge press MORE>MORE>CMNDS the default is Memory 0, but you have 10 to choose from. Press EDIT, then enter the mode and PID using the <> and ^ buttons. For example, the PID for the Traction Battery Voltage is $490B in mode $22.
So, use the ^ button to step up to 2, then > and repeat for the next 2, > and ^ to step up to 4, then 9, 0, and B. You should have 22490B in memory 0. Press OK and then SEND. You will get back something like 62490B2E83. The 62490B indicates a repsonse to the request, the 2E83 is the hexadecimal representaion of the voltage. The scaling is .03052 for this PID, so to get voltage you calculate the decimal value and multiply by .03052.
2E83 hex =2*4096+15*256+8*16+3=12163, and voltage =.03052*12163=371.2V.

I can't reliably get the TBCM PIDs, of which SoC is one, with the SC, but I think Ron can figure this out. I will post my list of scaling and offsets for the PIDs, and hopefully they can be verified and/or corrected by the masses.

Thanks Carl for joining and posting on Cleanmpg, and welcome to our group here. The top hypermilers in the world are here and will return the help you shared today with their knowledge. Glad to have another fellow owner like you here.

GaryG

Carl, I'm sure you know what you are doing and I know what I am doing, but I may not know what I am saying!

I'm thinking of it like a clock, where midnight can be 0:00h or 24:00h.
With the motors, standing still can be 0000 or FFFF.

Reverse is like this: (counter clockwise)
FF48 183 from zero in the negative direction
FEAE 337 from zero in the negative direction
FE19 -486
FD8A -629
FCEB -788

Or you used the term "complementary" which is totally correct.

FFFF - FF48 = 183
FFFF - FEAE = 337
FFFF - FE19 = 486

But you have to remember the negative sign!
-John

Carl, take a look at this information regarding OBD11 for the FEH:
http://www.motorcraftservice.com/vdirs/diagnostics/pdf/OBDSM500_HEV.pdf

GaryG

Carl, I'm finding out that the lower register of mode 22 is the same as mode 01.

Therefore, there is a lot of redundancy.
And if it helps anything, you don't have to change modes to get EVERYTHING.

For example: engine coolant temperature returns on both:

0105 and 220005.

All I can see is $22 required 2 extra zeros.
It did not work with simply 2205.
???

Intake Air Temperature works on both:

010F and 22000F

Am I seeing a pattern here?
I suspect the first 50-60 codes overlap at the bottom of the list, and then from 60-250 the codes are in $22 alone, and that's were we get the hybrid ones.
Have more testing to do!
-John

Interesting PID I have found for the FEH....mode 22 PID 16C3 is "octane flashed into vehicle at final assembly during spark test" mine is set at 5B, which is 91 octane! What does everybody else have in their FEH for this?

I am nearly ready to publish my list of PIDs for the FEH, pending some final scrubbing of the offsets and scalings. Over 200 PIDs and counting....

I look forward to seeing the list. I just got my scanguage II yesterday.

Mine says 5B also from 16C3.

Have you found one for % ethanol detected?
Ethanol would make the density, or specific gravity of the fuel go up, so that could be one way to detect it.

Interesting PID I have found for the FEH....mode 22 PID 16C3 is "octane flashed into vehicle at final assembly during spark test" mine is set at 5B, which is 91 octane! What does everybody else have in their FEH for this?

I am nearly ready to publish my list of PIDs for the FEH, pending some final scrubbing of the offsets and scalings. Over 200 PIDs and counting....

OK, here's a VERY preliminary spreadsheet of the FEH enhanced PIDs.

Still trying to figure out what PIDs 1100 and 1108 are, they return 4 bytes of data...

Many values that can be negative are in 2's complement format. For example 0x8000 is a 2's complement representation of -32,768 while 0x7FFF would be +32,767.

For values with scaling and offset, scale first then subtract the offset.


DISCLAIMERS:

For Amusement Only!! Use at your own risk. Don't play with the SG while driving!

There are probably (definitely) many errors and typos, but please do not modify and then post elsewhere.

Not everything listed can be obtained with the SG, somethings can be obtained occasionally with some work. Don't post strange results based on the scaling and offsets I've listed, because they may be wrong...

I should have a beta version of the user-programmable SG by this weekend, barring some more unforseen glitches. I will keep scrubbing the scaling and offsets and update the file when I can.

http://members.cox.net/carl.ebay/2005_feh_PIDs_a.xls

"user-programmable SC" - does this mean you can create your own gauges?

Duncan

Yes, the user-programmable SG will allow you to have your own custom gauges. For me, HV battery temp and SoC are high on the list, along with charge/discharge limits.

Apparently they are having some issues with the new software, and I will now have to wait until Monday.

Cool!
I did not see that one on the SC website.

It won't be on the web site until it is formally launched. Beta testers like me will try to thrash them and report back any problems. My guess would be in a month or so they will release the new software.

Carl, nice work. I had a lot of that "chart" complied myself, now I am cross-checking.

It is possible, even "likely" that for temperature sensor data you think is degrees C minus an offset of 40 is really plain old degrees F.

Check those parts out that you think are degrees C with new eyes....
It works very well in the cases that I have seen that it is simple degrees F, no offset.
-John

Possible, I suppose but not likely. For temperature measurements that also have sensor data in volts, I verified the two measurements. For temp PIDs that conform to OBD-II specs, the offset and scaling is already defined. What temp measurements do you think are incorrect?

On some, not all, you had "measured values" at, or nearly at freezing. ( 1'C).

Did you really run measurements in freezing weather?

The only ONE that I found was fuel rail temp of 0x2B wich is certainly not 3C, but just as certainly it is not 43F, either. In my local copy, I had already removed the offset. I will try to upload my latest version, which is already several revs beyond what I posted.

The only ONE that I found was fuel rail temp of 0x2B wich is certainly not 3C, but just as certainly it is not 43F, either. In my local copy, I had already removed the offset. I will try to upload my latest version, which is already several revs beyond what I posted.

Thanks Carl for the update and posting this info on CMPG!

GaryG

Having had the latest SG firmware for a week and a half, I have noticed a few things that have made me change my driving habits. Some interesting discoveries:

The ICE will not charge the HV battery above 53%. Once you get to 53%, only regen can get it higher. It is possible, but very difficult, to get the SoC to 60%. You can nudge it a tiny bit higher with repeated brief L FS. On the Nav display, 60% SoC is where the green touches the bottom of the + sign of the battery. At 39.9% SoC, the green disappears. Above 53% SoC, you get electric assist to the wheels, even at freeway speeds.

Battery temps above 95F will cause the A/C to run most of the time. There are some cases where even with battery temp below 95F, the FEH will not shut the ICE off even with high SoC. I have found an FAS will re-allow EV after a minute or so.

Overnight the SoC will drop by 1% or more. If you park at night with 40% SoC, in the morning the SoC will be around 38.8%. Driving away using the electric motors with the ICE idling can get the SoC down as low as 32.2% before the ICE will start driving the wheels and charging the battery. FE when this happens is very bad. ICE will shut off around 42% SoC. This is also the point where the charging load starts to drop if you force the ICE to stay on.

There are still some PIDs that can't seem to be displayed with the new software. Hopefully these last bugs will be worked out real soon.

Having had the latest SG firmware for a week and a half, I have noticed a few things that have made me change my driving habits. Some interesting discoveries:

The ICE will not charge the HV battery above 53%. Once you get to 53%, only regen can get it higher. It is possible, but very dificult, to get the SoC to 60%. You can nudge it a tiny bit higher with repeated brief L FS. On the Nav display, 60% SoC is where the green touches the bottom of the + sign of the battery. At 39.9% SoC, the green dissapears. Above 53% SoC, you get electric assist to the wheels, even at freeway speeds.

Battery temps above 95F will cause the A/C to run most of the time. There are some cases where even with battery temp below 95F, the FEH will not shut the ICE off even with high SoC. I have found an FAS will re-allow EV after a minute or so.

Overnight the SoC will drop by 1% or more. If you park at night with 40% SoC, in the morning the SoC will be around 38.8%. Driving away using the electric motors with the ICE idling can get the SoC down as low as 32.2% before the ICE will start driving the wheels and charging the battery. FE when this happens is very bad.

There are still some PIDs that can't seem to be displayed with the new software. Hopefully these last bugs will be worked out real soon.

Very good info Carl! You confirm what I've read and how I operate my FEH based on battery SOC. Try shifting to neutral and tapping the brake pedal to go EV instead of FAS to go EV. It works for me like a charm even if the battery is hot or cold.

GaryG

I can confirm most of what Carl has posted.
I don't yet have his version of the SG but have seen all the same with other means.
Regarding battery Temperature:

Above 38'C (100'F) is when A/C cooling becomes mandatory, and EV is essentially disabled.
When this occurs, the car will not allow EV at 37'C when cooling, but will at 35'C (95'F).
So you can have EV at 96, 97, 98, or 99 degrees on the way up in temperature, but not on the way down.

Also, water temperature must be 140'F to enable EV, but the car will stay in EV down to 125'F.
So you can have EV at 126'F on the way down, but not on the way up!

All reports look like the 2005-2007 behave the same.
Early testing indicates that 2008's require 160'F water temperature to enable EV.
This sounds like a step backwards, but Ford must have a good reason.
The 2008 does get better MPG after all!

More info:

Oh... the cars will always allow EV when battery is below 95'F ( or 35'C ).
What you probably noticed Carl is: When the A/C turns on, there is a minimum time required for each A/C on cycle.
I have not timed it, but let's just say, 30 seconds for argument sake, like the 30 seconds minimum of engine run time required after
each key restart. So, if your battery is at 95 degrees, and the A/C just kicked on 1 second before you wanted EV, the engine must run for
that minimum of 30 seconds ( or 29 seconds more ) and then you will be able to have EV. But 30 seconds later, your driving conditions may
no longer be right for EV, so it appears EV is being blocked at 95'F, when there is no such limitation, just the 30 seconds ( or whatever ) of
minimum A/C run time each time the A/C clutch engages. -John

Well, with our continuing 108 degree weather I can confirm that my FEH won't shut off the ICE with the double-tap in nuetral when the battery is hot. I am still getting a mode where it won't shut the ICE off even below 95F battery air temp. This isn't a case of missing the A/C cycling time by a few seconds. I have been stuck in this mode for ten minutes or more, not wanting to FAS because I'm hoping the ICE will shut off on its own at any time. It may be that the battery air temp PID isn't accurately reflecting the actual battery temp that the FEH is using, but that's just a guess. Also, my battery air temp has not dropped below 89.6F, even when starting out in the morning. It is usually around 116F when leaving work in the evening.

I had high hopes for this tank but am already down to 36.5 mpg 160 miles into it.

Well, with our continuing 108 degree weather I can confirm that my FEH won't shut off the ICE with the double-tap in nuetral when the battery is hot. I am still getting a mode where it won't shut the ICE off even below 95F battery air temp. This isn't a case of missing the A/C cycling time by a few seconds. I have been stuck in this mode for ten minutes or more, not wanting to FAS because I'm hoping the ICE will shut off on its own at any time. It may be that the battery air temp PID isn't accurately reflecting the actual battery temp that the FEH is using, but that's just a guess. Also, my battery air temp has not dropped below 89.6F, even when starting out in the morning. It is usually around 116F when leaving work in the evening.

I had high hopes for this tank but am already down to 36.5 mpg 160 miles into it.

Carl, do you have the Sanyo or Panasonic HV battery? I heard the '08 FEH changed to the Panasonic and that may be your problem. The '05 workshop manual states the ideal temperature of the HVTB is 82F with a desired range between 77F to 100F. Even in 96F temperatures here in South Florida, I never have a problem shutting down the ICE for EV. If I heat the battery more with "L" regen, I still can shift to active neutral (above 6mph) and go EV by tapping the brakes. Passive neutral below 6mph will not allow a change in EV or ICE running mode. I think that design was to allow the techs to charge or test things like the A/C and not have the ICE shutting down all the time.

If changes to the HV battery design have been made in the '08, this needs to be brought to the attention of our readers.

GaryG

I have been able to double tap the ICE off in N above 6mph on occasion when the battery temp is 95F or less, but never for 100F or higher. I have also coasted to a stop in N with the ICE off, only to have it turn on because the SOC dropped below 40%. Supposedly this shouldn't happen, but it does, and charging occurs, even though stopped in N. My FEH acts like the "rules" of operation are more like "guidelines."

When you get your SC firmware upgrade, maybe you can see if you can double tap the ICE off with battery temps >95F. Also, I would be interested to see how fast the battery temp drops in your FEH when the A/C is on.

Also, this morning I started with a 42% SOC, and after .2 miles of electric drive with ICE idling, the SOC had dropped all the way to 33.8%!

I have been able to double tap the ICE off in N above 6mph on occasion when the battery temp is 95F or less, but never for 100F or higher. I have also coasted to a stop in N with the ICE off, only to have it turn on because the SOC dropped below 40%. Suposedly this shouldn't happen, but it does, and charging occurs, even though stopped in N. My FEH acts like the "rules" of operation are more like "guidelines."

When you get your SC firmware upgrade, maybe you can see if you can double tap the ICE off with battery temps >95F. Also, I would be interested to see how fast the battery temp drops in your FEH when the A/C is on.

Also, this morning I started with a 42% SOC, and after .2 miles of electric drive with ICE idling, the SOC had dropped all the way to 33.8%!

Your conditions are far more heated than mine. It may be that after starting the ICE after my FEH has been sitting in the hot sun in the mid 90's is much different than in your case in the 100's. I've never had a hot condition enough to prevent EV with tapping the brakes in neutral. Most of the time, shifting to "L" to go EV will do it if the battery has the minimum charge required.

I've been very much aware of the strategy for heating the CAT at an idle can brings the battery SoC below 40%. This happens almost every time I start out after sitting for 5-10 minutes because my battery is always low. This is when I make good use of the FS in "L" and often heat the battery as much as possible during my summer days. As soon as I see a FS in "L" will not allow EV, tapping the brake pedal in neutral works 100% of the time for me.

Also, I've never had a restart at a stop in neutral, so Ford may have changed the strategy. If I know I'm going to be sitting for a while, I turn the key off and not drain the battery to a very low SoC now. It aways restarts when I shift out of neutral with a low SoC any way.

As soon as Ron says the the new SC11 with the new firmware is ready to ship, I'll place a new order and send my old one back for reprogramming after I get the replacement. I'd be lost without a SG now.

GaryG

I posted a picture of xgauge coding for the FEH. I have heard that most battery xgauges don't work on 2008, and one report that SoC doesn't work for 2007. I have at various times had most of the PIDs successfully coded into my SG with software 3.14. If there is any PID that you can't get to work, let me know.

PS - FEH owners are fortunate vis-a-vis Toyota with regards to PIDs (and hence xgauges.) Toyota apparently decided not to follow the SAE J2190 standard for formatting their PIDs.
Out of over 200 PIDs on my FEH I can put all but 3 into xgauges.

Quote
Originally Posted by Johndixs View Post
Re the ScanGuageII and specifically how it calculates MPG , I have a question:

I have some experience with aircraft fuel flow measurements, which typically require a mass flow sensor and a fuel temperature probe. Obviously, knowing the mass flow and the fuel temp, one can calculate the flow in lbs/hr. What does the ScanGuage do? Have the manufacturers now installed some sort of flow sensor, or it a calculated fuel flow based on throttle position etc? if that is the case, it would be nice to know the accuracy spec.

Thanks,
John Dixson
End Quote

I'm not an expert, but the SG does not have a way to measure fuel flow or fuel cut. It uses the Mass flow and most likely the same sensors the PCM uses to calculate MPG. Vehicle speed sensors and RPM must be also be used because the SG has an speed adjustment to calculate many things. The only problem I see is you can't adjust tenths between 1% and 2% so the FEH/MMH OD would match better to the fuel tank mileage.

Don't let the low cost of the SG fool you, I find it is highly accurate!

GaryG

Wow! This new x-gauge is something else Carl. Took it on the commute today with the SoC % gauge and I can see I will improve my mileage with its tenth of a percentage readings. Far better than the nav sys factory gauge and it reads below 40% so nicely. I can now tell when I can go EV and when I should kick on the ICE before a stop.

It's hard to believe that I know I will increase my mileage with just this added feature, but I saw it today even in windy weather.

Debbie Katz you gotta get one of these. I daisy chained it with my old SGII and am making another bracket. It is much easier to program than I ever thought from the info Carl provided on the Scangauge website. Just read the manual and use the info for the FEH on the site. Carl has got Ron to put up a special section (most complete) for the FEH. I don't know if other hybrid owners are making the headway Carl has provided for us by working directly with Ron, but you folks need to add this information so Ron can put it on his website.

You can bet I'll be taking advantage of this data and help FEH/MMH owners with better techniques to improve MPG.

GaryG

Wow! This new x-gauge is something else Carl. Took it on the commute today with the SoC % gauge and I can see I will improve my mileage with its tenth of a percentage readings. Far better than the nav sys factory gauge and it reads below 40% so nicely. I can now tell when I can go EV and when I should kick on the ICE before a stop.

It's hard to believe that I know I will increase my mileage with just this added feature, but I saw it today even in windy weather.

Debbie Katz you gotta get one of these. I daisy chained it with my old SGII and am making another bracket. It is much easier to program than I ever thought from the info Carl provided on the Scangauge website. Just read the manual and use the info for the FEH on the site. Carl has got Ron to put up a special section (most complete) for the FEH. I don't know if other hybrid owners are making the headway Carl has provided for us by working directly with Ron, but you folks need to add this information so Ron can put it on his website.

You can bet I'll be taking advantage of this data and help FEH/MMH owners with better techniques to improve MPG.

GaryG

Hi Gary --

I haven't sent my SGII in for re-flashing yet, because I can't bear to be without it :( With it on my dash, I'm learning things now about hypermiling in our cold (& lately *very* snowy :eek:) WI winters. I'm tempted to just buy a 2nd one & daisy-chain it like you have, but then there's how to explain to my husband why I need yet *another* thing to look at instead of the road :rolleyes:

I'm even more tempted after reading your message :D

Hi Gary --

I haven't sent my SGII in for re-flashing yet, because I can't bear to be without it :( With it on my dash, I'm learning things now about hypermiling in our cold (& lately *very* snowy :eek:) WI winters. I'm tempted to just buy a 2nd one & daisy-chain it like you have, but then there's how to explain to my husband why I need yet *another* thing to look at instead of the road :rolleyes:

I'm even more tempted after reading your message :D

Debbie, there are way to many gauges available to watch on one SGII that I recommend getting another SGII for that reason alone. Now that we have such a big choice to add 25 additional gauges that are far better than the nav sys is unreal. I thought I knew just about everything my FEH was doing and would watch the Trip information only to make sure I ended up with a good tank MPG. Now that I see the nav sys battery level gauge is a POS compared to the X-gauge, I can watch a much better instant MPG, coolant temp, etc. and trip information at a glance with two small SGII gauges.

With you being up there in the cold, you can't keep switching back and forth on one SGII to monitor the things you need to. That would be far more dangerous than trying to watch the road than having two SGII gauges with most the information you need all set up. So for safety sake, I recommend you do what I have done.

BTW, I don't know if I could do without my old SGII long enough to have it sent back to LL to get the updated programming now that I see what two is like.

GaryG

Quote
Originally Posted by Johndixs View Post
Re the ScanGuageII and specifically how it calculates MPG , I have a question:

I have some experience with aircraft fuel flow measurements, which typically require a mass flow sensor and a fuel temperature probe. Obviously, knowing the mass flow and the fuel temp, one can calculate the flow in lbs/hr. What does the ScanGuage do? Have the manufacturers now installed some sort of flow sensor, or it a calculated fuel flow based on throttle position etc? if that is the case, it would be nice to know the accuracy spec.

Thanks,
John Dixson
End Quote

I'm not an expert, but the SG does not have a way to measure fuel flow or fuel cut. It uses the Mass flow and most likely the same sensors the PCM uses to calculate MPG. Vehicle speed sensors and RPM must be also be used because the SG has an speed adjustment to calculate many things. The only problem I see is you can't adjust tenths between 1% and 2% so the FEH/MMH OD would match better to the fuel tank mileage.

Don't let the low cost of the SG fool you, I find it is highly accurate!

GaryG

Actually, the new SG firmware does have a fuel cut parameter. Go into SETUP>FUEL>CUTOFF and set it to 20. Now, if the TPS is less than 20 AND loop is open, the SG will cut fuel.

I have tested about 200 xgauges in my FEH and have a tough time deciding which 25 to leave in....

Actually, the new SG firmware does have a fuel cut parameter. Go into SETUP>FUEL>CUTOFF and set it to 20. Now, if the TPS is less than 20 AND loop is open, the SG will cut fuel.

I have tested about 200 xgauges in my FEH and have a tough time deciding which 25 to leave in....

Keep it simple Carl because the standard gauges with the new SoC are still great to monitor. For instance, today I had one of my SGII monitoring SoC, coolant temperature, instant MPG and Load. The other was monitoring Trip. I had a ~20mph headwind that we all just love going about ~55mph in them. A glance at the SoC and I noticed it was climbing over 60%, then 70% and just under 80%. This was the first time to see my battery SoC level on both the Navi and the SGII climb that high. This was all happening at a steady speed on State Road 80 crossing the State. The really weird thing was what happened after the rapid charge, it was a rapid discharge. Had the CC on so I could watch all the gauges and not worry about speed dropping off or increasing. When the battery started to discharge and the Nav flow arrows then went to the wheels from the HV battery, something happen that made me glad I was monitoring instant MPG on the SG. Going 55mph, the instant MPG shot up to 80-90mpg in a ~20mph headwind! It stayed there for more than a few minutes, but I didn't think to time it. Can't give you any Load # on the ICE, but it had to be less than 50%.

Another new experience for me in my '05 FEH!

GaryG

I have an 08 FEH.

Using scangauge published data from the site, I have a number of xgauges working, however I cannot get battery temperature to display.

Also, I am using the "alternate" code for battery voltage.

Carl, any suggestions for a better code set for battery temperature?

thanks,
Steve

I have an 08 FEH.

Using scangauge published data from the site, I have a number of xgauges working, however I cannot get battery temperature to display.

Also, I am using the "alternate" code for battery voltage.

Carl, any suggestions for a better code set for battery temperature?

thanks,
Steve

The battery air temp apparently doesn't work in 2008s. Try using the Tav xgauge. This is the average battery module temp and seems to be what the FEH uses in making battery temperature-related decisions. In 05-07 FEHs, the battery air temp doesn't update when cold, so maybe that's why Ford dropped it in the 2008 MY.

Debbie and those thinking about sending your SGII back to be reprogrammed to the new firmware, you need to hold off. That upgrade will not give you SoC. Ron is working on a fix, so you need to E-mail him at LL and tell him your waiting to send your SGII back as soon as he finds the fix. It may take a new processor which he says will be free of charge.

GaryG

Debbie and those thinking about sending your SGII back to be reprogrammed to the new firmware, you need to hold off. That upgrade will not give you SoC. Ron is working on a fix, so you need to E-mail him at LL and tell him your waiting to send your SGII back as soon as he finds the fix. It may take a new processor which he says will be free of charge.

GaryG

Ron is still working on the firmware fix for the 3.15* SG's. Apparently, this has led to him discovering some other differences between the older obsolete microprocessor and the replacement one. Microchip wasn't even aware of these issues until Ron discovered them when diving into why the SoC didn't work on the FEH.

So the benefits of the add-a-gauges are extending even beyond the FEH world....

I posted a picture of xgauge coding for the FEH. I have heard that most battery xgauges don't work on 2008, and one report that SoC doesn't work for 2007. I have at various times had most of the PIDs successfully coded into my SG with software 3.14. If there is any PID that you can't get to work, let me know.

PS - FEH owners are fortunate vis-a-vis Toyota with regards to PIDs (and hence xgauges.) Toyota apparently decided not to follow the SAE J2190 standard for formatting their PIDs.
Out of over 200 PIDs on my FEH I can put all but 3 into xgauges.

Carl, Being new, I'm not sure where you "posted a picture of the xgauge coding for the FEH". Could you elaborate?

Also, will the new firmware have the SoC% built-in or just make the xGauge calculations work better?

I just got my SGII last week and can't wait to be able to read the SoC%, based on GaryG's experiences above.

Carl, Being new, I'm not sure where you "posted a picture of the xgauge coding for the FEH". Could you elaborate?

Also, will the new firmware have the SoC% built-in or just make the xGauge calculations work better?

I just got my SGII last week and can't wait to be able to read the SoC%, based on GaryG's experiences above.

A list of the FEH coding can be found on the LL website. Last I checked, there were two that had wrong entries - CHT and FRT (Cylinder Head Temperature and Fuel Rail Temperature) and a couple where the description wasn't exactly right - the second Gauge called Max Battery Module Temp is actually Average Battery Module Temp (Tav) and the Gauge called Avg Batter Temp is actually Maximum Module Temp Change (Txc).

Every one of the gauges you want to see has to be entered into your SG's memory and then selected when in the gauge mode. Also note that units are hard coded into the gauges, so if you want metric readings you have to alter the MTH entry.

Reading the PDF provided in the XGauge coding thread should get you going.

Corrections to LL Gauge coding:

Cylinder Head Temp Degrees F:
TXD: 07E0221624
RXF: 046205160624
RXD: 3010
MTH: 000200010000
NAM: CHT (or whatever you want)

Fuel Rail Temp Degrees F:
TXD: 07E022168E
RXF: 04620516068E
RXD: 3008
MTH: 000200010000
NAM: FRT (or whatever you want)

If you need more info, let me know.

Hi All

Thought I'd post a picture of where I located my second Scangauge II. It looks like from the photo that part of one gauge is blocked by the steering wheel, but it's not at all. The only gauges that are blocked is just a little bit of the top of the tact and speedo, but I can still see where the needles are.

The bottom SGII is shaded under the dash and the top SGII is shaded with a bracket I made out of aluminum 1/16 channel I got at Home Depot. The bottom bracket is made out of 3/4"X1/16 straight aluminum stock and screwed in with the existing cluster screws in the '05-'07 FEH/MMH. The bottom gauge is connected to the OBD II and I ran a 1' ethernet cable to the top gauge.

I didn't hide the wires, but there is not a big mess either. I'm thinking of a upgrade to the '09 FEH or MMH if there is a Lithium HV battery improvement. I want to be able to take out the SG's in my '05 so it looks stock when I sell it.

The picture is in my Photo's http://www.cleanmpg.com/photos/showphoto.php/photo/5867/cat/500/ppuser/36

GaryG

Has anyone managed to make PID 4915 or 496E (Discharge Current) from TBCM, TCM respectively?

Based on a gh thread:
http://www.greenhybrid.com/discuss/f26/power-flow-scangauge-ii-16372/

TXD 0745224915 or 07E122496E
RXF 046285490615 or 04628549066E
RXD 3010

with math changes depending on charging vs discharging is needed. Thing is, the math shown just doesn't make any sense as to why it would actually make any of the numbers show correctly, nor does the system being shifted by 1995, but only during charge. I tried sending using CMDs, but I couldn't seem to get a response (too much stuff talking on the bus, and no filter confusing the SG?)

Do we not know how to use/scale these PIDs? Are we looking at the right data?

Has anyone managed to make PID 4915 or 496E (Discharge Current) from TBCM, TCM respectively?

Based on a gh thread:
http://www.greenhybrid.com/discuss/f26/power-flow-scangauge-ii-16372/

TXD 0745224915 or 07E122496E
RXF 046285490615 or 04628549066E
RXD 3010

with math changes depending on charging vs discharging is needed. Thing is, the math shown just doesn't make any sense as to why it would actually make any of the numbers show correctly, nor does the system being shifted by 1995, but only during charge. I tried sending using CMDs, but I couldn't seem to get a response (too much stuff talking on the bus, and no filter confusing the SG?)

Do we not know how to use/scale these PIDs? Are we looking at the right data?

Scaled 2's complement PIDs are difficult to deal with using the SG simple math. You can get the xgauge to display charging or discharging correctly, but not with the same xgauge. I have mentioned this on this site on several occasions, but nobody has suggested a way to do it. It is also way at the bottom of things for Ron at Linear Logic to worry about. He is still trying to resolve the issue of the old vs. new processor not being able to talk to the FEH's Traction Battery Control Module.

BTW, I was meaning to ask one of the experts here:

I just got my Scangauge (yesterday), using it with one of the mgtmotorsports mirror mounts on my '08 MMH, and SoC works perfectly with 3.15 firmware. Is this an indicator of the new processor? Is there a forum thread that sumarizes 'what is what' there?


I agree with you BTW that 2's complement math is a little bit confusing for most people, but I have a M.S. degree in Computer Engineering - Specializing in data coding theory and cryptography. I looked at the math that is going on there, and I have to conclude that either the SG is doing something wrong, or none of us have a clue how this PID actually works. Reverse engineering the binary math based upon the SG Xgauge Coding document that you posted, I cannot figure out what is going on here. I find it very noteworthy though that this is the only PID in the current group which uses 16 bits rather than 8 bits coming out of the same module. That seems extremely fishy to me (especially having done embedded software design for aircraft control systems at a prior point in my career).

If someone can provide me with the RAW Hex data that comes back from the 0745224915 and 07E122496E commands and tell me wether they were charging slow, charging fast, discharging slow, discharging fast, etc. I might be able to help Ron to figure out whether it is the SG doing something strange here, or if it is the FEH/MMH that are a bit screwy....Software People can be a little odd sometimes (as evidenced by the fact that I haven't written software in about 5 years, but I still talk to myself)

I just got my Scangauge (yesterday), using it with one of the mgtmotorsports mirror mounts on my '08 MMH, and SoC works perfectly with 3.15 firmware. Is this an indicator of the new processor? Is there a forum thread that sumarizes 'what is what' there?


If the version has an asterisk at the end, it's an old processor with the 3.15 firmware (3.15*). This happens when older SGII's are sent in for the firmware upgrade. I purchased a new one recently and SoC works great. Still have my old one and I'm holding off on the mail-in upgrade until this is resolved.

There is a thread on greenhybrid that has details:
http://www.greenhybrid.com/discuss/f26/scangaugeii-soc-xgauge-16289/

--Rick

BTW, I was meaning to ask one of the experts here:

I just got my Scangauge (yesterday), using it with one of the mgtmotorsports mirror mounts on my '08 MMH, and SoC works perfectly with 3.15 firmware. Is this an indicator of the new processor? Is there a forum thread that sumarizes 'what is what' there?


I agree with you BTW that 2's complement math is a little bit confusing for most people, but I have a M.S. degree in Computer Engineering - Specializing in data coding theory and cryptography. I looked at the math that is going on there, and I have to conclude that either the SG is doing something wrong, or none of us have a clue how this PID actually works. Reverse engineering the binary math based upon the SG Xgauge Coding document that you posted, I cannot figure out what is going on here. I find it very noteworthy though that this is the only PID in the current group which uses 16 bits rather than 8 bits coming out of the same module. That seems extremely fishy to me (especially having done embedded software design for aircraft control systems at a prior point in my career).

If someone can provide me with the RAW Hex data that comes back from the 0745224915 and 07E122496E commands and tell me wether they were charging slow, charging fast, discharging slow, discharging fast, etc. I might be able to help Ron to figure out whether it is the SG doing something strange here, or if it is the FEH/MMH that are a bit screwy....Software People can be a little odd sometimes (as evidenced by the fact that I haven't written software in about 5 years, but I still talk to myself)

There is nothing wrong with the SG or the math. I understand exactly what is happening and it makes perfect sense. The PID 4915 is a two-byte, scaled 2's complement representation of the current into/out of the HV battery. The scaling is .03052, which is a full scale reading of 1000 divided by 2^15. For 20A of discharge, the PID will return a hex value of 0290. This is multiplied by hex 0271 (625), divided by hex 0800 (2048), nothing added. This value is then divided by 10 due to the "8" in the RXF entry. This gives the reading of 20.0 in the xgauge. For 20A of charging, the PID will return a hex value of FD70, which is 2's complement for -656. It is multiplied by hex 0271 (625), divided by hex 0800 (2048), nothing added for a hex value of 4D57, which is 19799. This is divided by 10 due to the "8" in the RXF, giving a reading of 1980. If you were to subtract 2000 from this you would get the correct charging current, but then you would get -1980 for 20A of discharge current.

I would love to find a solution to this as there are numerous other PIDs in scaled 2's complement form. I am an IC designer and the only code I write anymore is verilogAMS, so you sound like a good candidate to solve the problem. Any more info you need, just ask.

This thread timing is fortuitous. I had just programmed my Sg II with that 4915 pid yesterday but was unable to test it until today. To keep it simple, I just wanted to see the 100mA increment digits. I put in TXD 0745224915, RXF 046205490615, RXD 3010 and MTH 007D1000FA24 (borrowed from TBV scaling of *125 /4096, or *.03052 as CardD said). This gave readings that were all over the place, so I decided to see what the raw numbers were. I did this with MTH 000100010000 (noop). Lo and behold, I'm getting 100mA increments (i.e. assume the reading is 10x the desired reading), plus and minus swings that coincided with discharge and charge, respectively, but I think the scaling may be off a tiny bit.

This is on a 2006 MMH. By the way, the references to 100mA increments are credited to Davide Andrea of Hybrids Plus and the FEH technical documentation that he's posting on the EAA-PHEV web site. See http://www.eaa-phev.org/wiki/Escape_PHEV_TechInfo .

I'm not finished tinkering with the settings, but they're good enough for now for me.

cheers,
Bill

This thread timing is fortuitous. I had just programmed my Sg II with that 4915 pid yesterday but was unable to test it until today. To keep it simple, I just wanted to see the 100mA increment digits. I put in TXD 0745224915, RXF 046205490615, RXD 3010 and MTH 007D1000FA24 (borrowed from TBV scaling of *125 /4096, or *.03052 as CardD said). This gave readings that were all over the place, so I decided to see what the raw numbers were. I did this with MTH 000100010000 (noop). Lo and behold, I'm getting 100mA increments (i.e. assume the reading is 10x the desired reading), plus and minus swings that coincided with discharge and charge, respectively, but I think the scaling may be off a tiny bit.

This is on a 2006 MMH. By the way, the references to 100mA increments are credited to Davide Andrea of Hybrids Plus and the FEH technical documentation that he's posting on the EAA-PHEV web site. See http://www.eaa-phev.org/wiki/Escape_PHEV_TechInfo .

I'm not finished tinkering with the settings, but they're good enough for now for me.

cheers,
Bill

Whoa! We need to back up here a little. Your MTH of 007D1000FA24 is very strange. You are correctly scaling, then subtracting 1500. This will definitely give odd readings. Then you changed the MTH to 00010001000 and said you are seeing the 100mA increments. No, you are seeing the 1 increments any PID would return with a scaling of 1. The correct current increment is, of course, 30.5mA. The PID is an integer with units of amps, scaling of .03052 gives 30.5 mA steps. With the RXF value of 046205 you will only get an integer display for your xgauge.

Don't confuse the CAN sniffing info on the eaa.phev website with PIDs. They are very different animals.

Ok, I can explain the reason I tried the minus 1500. The information I got from the EAA-PHEV site suggested that the information returned would be positive but in the range of 500 decimal to 2500 decimal, centered around 1500 decimal which would be the zero point. The -1500 was of course to try to correct for that.

I guess I don't understand why the data coming back from CAN probes would be different from what the SG II is getting with XGauge probes. The CAN probes had returned raw data with no scaling needed (other than accounting for 100mA increments).

Ok, so assuming I am just confused, I should be able to eliminate the offset (-1500) and use the other MTH setting and get a correct reading. Then I can mess with getting the decimal point displayed.

Thanks for the correction!

cheers,
Bill

I'm sorry; the .03052 scaling with zero offset just isn't working for me. The displayed numbers are all over the place. The noop MTH still gives me some numbers that look almost real.

cheers,
Bill

Well folks, you can stop guessing.....I just couldn't leave it alone, so I started thinking about how would I have coded this up to make the binary/decimal conversion, and I believe I now know exactly where the 1995 (which by the way is really 1999.9) comes from. There is a slight error in how the Scangauge is performing 2's complement multiplication, and I don't know if it is in how the device is coded, or how the processor is performing the math. I'm working literaly right now to try to find a 'math' statement which the Scangauge will accept to fix the problem.

Good news, and bad news. The good news is, I know exactly how to tell Ron to fix this problem. The bad news is....yep, Ron has to fix the firmware in order to make 2's complement work properly. As a 16-bit word, -1 is represented as 0xFFFF in 2's complement. In decimal, this represents an unsigned value of 65,535 or (2^16 - 1). Now, taking 65,535 by the scaling factor for the TBC parameter (625/2048 decimal or 0x0271/0x0800 HEX) will yield 19999 (The CAN bus doesn't allow floating points, so the last digit is really after the decimal).

When charging the battery, 0xFFFF becomes 0xFFFE etc (like we are counting down) so as the charge grows, the number appears to get smaller.

To fix this, either the multiplication needs to be performed in direct binary, or a simple code segment in the SG will fix the problem:

/* This code was written by Justin Davis, CISSP #115889 and may be used freely by anyone developing or modifying the Scangauge II or
other software which inherits from the Scangauge. A suggestion would be using one or more of the N/A bits of RXF Offset 3 to indicate 2's
Complement, so that fixing this would not break anything which needs to be 1's complement or uncomplemented based on other assumptions.
*/
unsigned short x;
short y;
bool sign=false; //Using bool assumes C++; short or char would be just as effective in C;
x=readdata(); //Whatever this function is really named/called as
if (x & 0x8000) // And is a single operation, therefore faster for most processors than doing a >= 32768 compare
{ //If we got here, this means that the sign is negative
sign=true;
x ^= 0xFFFF; // XOR to flip 0 to 1 and 1 to 0
x += 1; //Add 1 to finish the conversion to a representation of a positive number from negative 2's complement.
}

/* Now the multiplication and division would work properly without the sign, but the sign boolean must be used*/
if(sign)
{
y = -1 * (short) x;
}
else
{
y = (short) x; // No sign change necessary
}
/* Now we actually have a signed representation of the data in variable y, and can make signed scaling, addition, etc. work properly.*/
I'm sure that given the code and/or processor to look at the fix might actually be much simpler than this. My guess is that the code is using a typecast from an unsigned short to a signed short incorrectly or not at all. Depending on the processor, compiler, etc. this may not be processed correctly, which is why I generally overload the typecast operator to manually convert this for all of the major integer types within the embeded systems I have developed. Also it has been a little while since I wrote a single line of code and compiled it (5 years) so I could have put something out of order or slightly incorrect syntax here.


I haven't taken the time to figure out if the MATH correction for add/subtract of B213 is correct, but my guess would be that it is off slightly due to the assumption of 1995.0 rather than 1999.9 in the writeup where I found the data I was trying to use. Since I am expecting this will get fixed now that we know what the problem is....not worth my time to try out the math.


Update:
I thought about the 'fix' for this and realized that it could take Ron a bit of time, especially given the RXD field allowing for really odd bit lengths and such which then require sign extension, and a lot more code to correct.

I can understand the math now, that is where 1995 and 14444 came from I think the 1995 and 1444 are just 'visual' what appears on the SG, both of which are the result of the 2's complement problem.

For reference, B213 for the add/sub factor on PID 4915 should really be B1E0 - (Thanks Carl)
(literally -20000) I believe, where C794 would be C782 on the PID 496E to make
-14462. B213 would equate to 19949 being subtracted, where C794 would be 14444 rather than 14462 - Which is actually very messy because the actual number is
79998, but this turns into 14462 when we throw a bit away to go from a DWORD to a WORD.


In total:
TBCM PID TCM PID
TXD 0745224915 07E122496E
RXF 04628549066E 045285490615
RXD 3010 3010
Dischg
Math 027108000000 027102000000
Chg
Math 02710800B1E0 02710200C782

If you use separate PIDs for Charge vs Discharge, you should be able to get both to show up at the same time. Then, just ignore any of the numbers that show up looking ridiculous, and you can show everything you want to see (granted it will take two gauges).


As an aside, when I set the Math to 000100010000 and use an RXF with 86 for offset 3, it doesn't behave quite as I would expect - I would look for a HEX display to show all 4 digits represented (for a 16 bit word anyway), even if they were zeros. I'm not sure what the proper behavior would be for the 10x 100x flags in this case, because they don't make much sense when one looks at hex....but I guess standard mult. If I leave RXF offset 3 as 06 though I'd expect to see the RAW 16 bits represented as HEX showing as 0000 to FFFF where leading 0s are shown. I only mention it because I know the fix for the leading zeros should be VERY easy to fix inside of a sprintf statement somewhere in the code and I'd hate to see something like that slip into the next firmware because it wasn't mentioned.

Then we just have to hope that no one ever makes concatenated PIDs.....those would be up to 6 bytes, and would require a nasty number system to be defined to make it calculable on a 32-bit microprocessor (Don Knuth's "The Art of Computing," Vol. 2. if anyone was actually interested captures how this is done).

Well folks, you can stop guessing.....I just couldn't leave it alone, so I started thinking about how would I have coded this up to make the binary/decimal conversion, and I believe I now know exactly where the 1995 (which by the way is really 1999.9) comes from. There is a slight error in how the Scangauge is performing 2's complement multiplication, and I don't know if it is in how the device is coded, or how the processor is performing the math. I'm working literaly right now to try to find a 'math' statement which the Scangauge will accept to fix the problem.

Good news, and bad news. The good news is, I know exactly how to tell Ron to fix this problem. The bad news is....yep, Ron has to fix the firmware in order to make 2's complement work properly. As a 16-bit word, -1 is represented as 0xFFFF in 2's complement. In decimal, this represents an unsigned value of 65,535 or (2^16 - 1). Now, taking 65,535 by the scaling factor for the TBC parameter (625/2048 decimal or 0x0271/0x0800 HEX) will yield 19999 (The CAN bus doesn't allow floating points, so the last digit is really after the decimal).

When charging the battery, 0xFFFF becomes 0xFFFE etc (like we are counting down) so as the charge grows, the number appears to get smaller.

To fix this, either the multiplication needs to be performed in direct binary, or a simple code segment in the SG will fix the problem:

/* This code was written by Justin Davis, CISSP #115889 and may be used freely by anyone developing or modifying the Scangauge II */
unsigned short x;
short y;
x=readdata(); //Whatever this function is really named/called as
bool sign = false; // Bool assumes C++, false assumes a positive sign
if (x >= 32768)
{ //If we got here, this means that the sign is negative
sign= true;
y = (short) (x - (unsigned short) 65535);
}
else
{
y = (short) x;
}
/* Now the multiplication and division will work properly*/

I'm sure that given the code and/or processor to look at the fix might actually be much simpler than this. My guess is that the code is using a typecast from an unsigned short to a signed short incorrectly or not at all. Depending on the processor, compiler, etc. this may not be processed correctly, which is why I generally overload the typecast operator to manually convert this for all of the major integer types within the embeded systems I have developed. Also it has been a little while since I wrote a single line of code and compiled it (5 years) so I could have put something out of order or slightly incorrect syntax here.


I haven't taken the time to figure out if the MATH correction for add/subtract of B213 is correct, but my guess would be that it is off slightly due to the assumption of 1995.0 rather than 1999.9 in the writeup where I found the data I was trying to use. Since I am expecting this will get fixed now that we know what the problem is....not worth my time to try out the math.


Yes, this is all stuff Ron and I have discussed before. The problem is, you can't assume any 2-byte PID with the MSB set is in 2's complement format. There are several PIDs for the FEH where that is not the case. In fact, look no further than SoC - a two-byte PID with scaling of .001526. 53% SoC is represented by a PID value of 87AE. I was hoping for a solution within the framework of the existing firmware, but I guess that was unrealistic.
New firmware would also have to have some bit to indicate if the data is in 2's complement format or not.

As far as the offset, you can see in my example a few posts earlier that -20A of current yielded a reading of 1980, indicating the offset was 2000 (19999/10). Where the 1995 came from I guess I can't remember - senior moment perhaps.
-
BTW, the MTH you gave in your edited post will give wrong answers - F830 will subtract not 2000, but 200 due to the RXF division by 10. B1E0 is what it should be. The C782 for the 496E PID is OK, but C780 might be a tad better.

The C782 for the 496E PID is OK, but C780 might be a tad better.
Now you have me curious. Is there a reason why subtracting 2 more/adding an additional -2 would be better? Just due to the extra bit which is lost?

Now you have me curious. Is there a reason why subtracting 2 more/adding an additional -2 would be better? Just due to the extra bit which is lost?

This is truly splitting hairs, but it is probably due to the truncation result of integer math. Take for example, a hex reading of F0 for discharging and FF10 for charging. This is 29.3A discharge and -29.3A charge. For charge, multiply FF10 by 0271, divide by 0200 and get (disregarding overflow bit) 375B. Add C782, get FEDD, which is 2's complement for -291 decimal. The SG divides by 10, displays -29.1 when it should be -29.3. There are cases where C781 is closer and cases where C782 is closer. Probably C781 gives the least squared error over the range of practical (<50A charging) values. But since I don't know if Ford truncates or rounds the PID value, it's impossible to say which is actually closer.

Perhaps it would be appropriate if we had a separate thread where we are capturing issues any folks are having with the '08 FEH/MMH.

I suspect that I am one of the only folks whose xGauge based 4WD idiot light doesn't work? It is stuck on 'OFF' and given the lovely :( 12+ inches of snow I have been driving on, I'd be the idiot to think my 4WD was actually off. Has anyone confirmed this PID on a different vehicle than the '08 MMH? So far I have only tried a very few (SoC, TBC - above, 4WD) there may be several others which do not function as expected. I've been planning to test all of the PIDs from the .xls file you (Carl) published, but I haven't had a chance due to work here recently.

Perhaps it would be appropriate if we had a separate thread where we are capturing issues any folks are having with the '08 FEH/MMH.

I suspect that I am one of the only folks whose xGauge based 4WD idiot light doesn't work? It is stuck on 'OFF' and given the lovely :( 12+ inches of snow I have been driving on, I'd be the idiot to think my 4WD was actually off. Has anyone confirmed this PID on a different vehicle than the '08 MMH? So far I have only tried a very few (SoC, TBC - above, 4WD) there may be several others which do not function as expected. I've been planning to test all of the PIDs from the .xls file you (Carl) published, but I haven't had a chance due to work here recently.

I think it's been confirmed that the AWD xgauge doesn't work. I used the PID from a non-hybrid escape and it appears that it doesn't work on the FEH. It's a bit in a PID of flags, but doesn't seem to work. One person said it worked 1 time, but never again. I suspect that bit is indicating something else than AWD engagement. I emailed Ron at LL to remove the xgauge from the list, but I guess that fell through the cracks.

Carl

Is it possible we can also program the Xgauge to give us more hybrid trouble codes? Every time I've gotten "Stop Safely Now", "Service Engine Soon" or any other warning light, the SGII says no codes found. The fact is, I've never seen a code on any of the three Scangauges I've owned or have owned. I have however used my SG and found codes on non-hybrid vehicles and repaired and cleared the codes.

GaryG

Carl

Is it possible we can also program the Xgauge to give us more hybrid trouble codes? Every time I've gotten "Stop Safely Now", "Service Engine Soon" or any other warning light, the SGII says no codes found. The fact is, I've never seen a code on any of the three Scangauges I've owned or have owned. I have however used my SG and found codes on non-hybrid vehicles and repaired and cleared the codes.

GaryG
Actually, this is something I've been working on recently. Once I can get the addresses for the rest of the modules, retrieving the DTCs from them should be no problem. You may have to program an xgauge to do it, though. I haven't had much of a way to test this yet. Hopefully I can stop by LL one evening and have Ron look at what I'm doing.

Same thing with me and the SG on my other vehicles. I have retrieved codes from my Olds and my Toyota, but never from the FEH. I've gotten the STOP SAFELY NOW message three times, but cycling the key once or twice has always cleared it. Haven't gotten it since the battery harness work.

Actually, this is something I've been working on recently. Once I can get the addresses for the rest of the modules, retrieving the DTCs from them should be no problem. You may have to program an xgauge to do it, though. I haven't had much of a way to test this yet. Hopefully I can stop by LL one evening and have Ron look at what I'm doing.


That would be great Carl. I'm sure there are a big number of folks who's warranty are out like myself and would love to know the problem to repair it our selfs. This would also increase sales for LL as I know the HV battery SoC Xgauge has. Those of us with repair manual sets could assist others here in identifying codes, needed tests and give repair instructions with those codes.

I'm having a "Service Soon" warning that the SGII can't read that resets when I cycle the key on and off. Many people on these boards have the same problem but it clears before they take it to the dealership. Those that are out of warranty have to pay ~$100 for the dealer to scan and find nothing.

All help is always appreciated Carl!

GaryG

That would be great Carl. I'm sure there are a big number of folks who's warranty are out like myself and would love to know the problem to repair it our selfs. This would also increase sales for LL as I know the HV battery SoC Xgauge has. Those of us with repair manual sets could assist others here in identifying codes, needed tests and give repair instructions with those codes.

I'm having a "Service Soon" warning that the SGII can't read that resets when I cycle the key on and off. Many people on these boards have the same problem but it clears before they take it to the dealership. Those that are out of warranty have to pay ~$100 for the dealer to scan and find nothing.

All help is always appreciated Carl!

GaryG
The next time you get a message, use your SG to send a mode 3 request. MORE>MORE>CMNDS then enter 03 in one of the memories and hit send. If you get back 4300, the problem is with a module other than the PCM. Or, you can edit a memory in the CMNDS and put 220200 in and hit send. That should give you the number of stored and pending DTCs. Hopefully I can get up with Ron and he can tell me if accessing the other module DTCs is possible like I think it is.

Could use some advice on a few appropriate Xgauges for a new 2008 FEH owner. I was thinking SoC and Tav based on what I have read in this thread. Have made my first short trip with my new SGII, and it seems like MPG, MPH, RPM, etc, just isn't quite enough. Was able to set the engine size, and did my best on setting the tank, as I had just filled up prior to getting the SGII. I'm a techno-geek, so programming in hex is right up my alley. Would also welcome any suggestions on mounting, cable routing, etc. The OBD-II connector on the 2008 FEH is on the left side of the steering column. Other than the velcro strips that came with the SGII, I was thinking that there must be a good way to secure the cable, and I would like it to dress it up and route it so it looks clean and stays out of the way. It was so cool to see that 9999 MPG when I was in EV mode! Saw some 100 MPG going down hill around 30 MPH, so that was pretty kewl too. So far my best tank pre-SGII was about 30.5 MPH. Now that I am about a month in to my ownership, and with a little over 2700 miles, I am pretty sure I am past the break-in period. Hopefully we are past our really cold weather here in SE WI, so am hoping with the warmer weather (above freezing soon!) and the SGII, I can start exceeding the EPA MPG rating of 34 city/30 highway, and start breaking into the hypermiler ranks. ;)

Hi guys,
I know this is a pretty old topic :o but is the closest one I found on the net regarding this subject.
I am trying to display 2005 FEH hybrid parameters on Torque OBD scanner software and I need the 2005 FEH PID. It was posted in an excel file on an external link on this topic, but this is no longer available. Can you please help in finding this PID list (I understood that these should be mode 22 PID).

Is it possible to transcode Scangauge Xgauge data into a set of info to be added to Torque software?

Thank you,
Daniel

I was reading this page, there's lots of technical info there, and some PID's are listed too.

http://www.eaa-phev.org/wiki/Escape_PHEV_TechInfo

Hi guys,
I know this is a pretty old topic :o but is the closest one I found on the net regarding this subject.
I am trying to display 2005 FEH hybrid parameters on Torque OBD scanner software and I need the 2005 FEH PID. It was posted in an excel file on an external link on this topic, but this is no longer available. Can you please help in finding this PID list (I understood that these should be mode 22 PID).

Is it possible to transcode Scangauge Xgauge data into a set of info to be added to Torque software?

Thank you,
Daniel

Cox just recently ended their web hosting which is why that link is dead. I can post the latest FEH PID data here or I can email it to you if you PM me.

The eaa-phev website referenced above has incorrect info for max charge and discharge PIDs. Per Ford documentation these are power values, not current with a scaling of .25. The Scangauge website still has some errors in it also, but most of the data there is good.

As other threads have shown, starting in 2009 the PCM and some other modules for the FEH changed from PIDs to DIDs. The Fusion Hybrid is exclusively DIDs and for it the address for the battery module changed from 0745 to 07E4.

As long as you can change the transmit address in the Torque software you should be able to get the battery data.