Archives

Hey all! This thread is the spin off of a thread over in the Automobiles / Honda section. We were discussing determining if a Honda (or other) car is operating in a lean-burn state by looking at the A/F ratio. All lean-burn Hondas are factory equipped with wide-band (LAF) O2 sensors, and this data is published to the OBD2 port. I believe this value is reported as a raw O2 sensor voltage, which needs to be converted to A/F by a specific function (frequently depends on O2 type).

The support doc at http://www.scangauge.com/support/pdfs/XGAUGE.pdf shows how to get the O2 raw value from 0-99. The correct scaling would show an A/F of 14.7 while cruising, and 17-22 while in lean-burn. Possible as low as 11-12 while in open loop (full throttle).

A common scaling function would be 0v = 10 A/F, 5V = 20 A/F.

Anyone with some X-gauge experience willing to tackle?

I don't personally have a ScanGuage but I'd like to see where this goes.

If the A/F value could be used as a factor in the FE calculation, we could get it much more accurate on these lean-burn equipped cars. That's probably beyond the scope of this experiment, but oh well. :)

Hi Ben:

___A wonderful find! The sliding scale gives the ability to read the variance from stoich all the way to fully lean at 22:1 and calculate the i and incorporate it into the aFCD for fuel calc’s on an Insight. And HCH-I too ;) It is not so much the i and aFCD numbers members would be looking for given the OEM instruments but the rest of the trip functions would than work with a real world model of fuel consumption leading to DTE and fuel left etc.

___Good Luck and thanks!

___Wayne

Hey all! This thread is the spin off of a thread over in the Automobiles / Honda section. We were discussing determining if a Honda (or other) car is operating in a lean-burn state by looking at the A/F ratio. All lean-burn Hondas are factory equipped with wide-band (LAF) O2 sensors, and this data is published to the OBD2 port. I believe this value is reported as a raw O2 sensor voltage, which needs to be converted to A/F by a specific function (frequently depends on O2 type).

The support doc at http://www.scangauge.com/support/pdfs/XGAUGE.pdf shows how to get the O2 raw value from 0-99. The correct scaling would show an A/F of 14.7 while cruising, and 17-22 while in lean-burn. Possible as low as 11-12 while in open loop (full throttle).

A common scaling function would be 0v = 10 A/F, 5V = 20 A/F.

Anyone with some X-gauge experience willing to tackle?

I don't personally have a ScanGuage but I'd like to see where this goes.

If the A/F value could be used as a factor in the FE calculation, we could get it much more accurate on these lean-burn equipped cars. That's probably beyond the scope of this experiment, but oh well. :)

The mode 01 PID 14 is actually two different PIDs. I looked at the coding on the SG website and I think it's wrong. I coded up the O2 sensor voltage PID on my FEH according to the OBD-II standards and watched it fluctuate between around 100mV to about 900mV while the engine was running. When off it went to 20mV and stayed there. So I guess my 2005 FEH has a narrow band sensor, so it won't give a very good number for A/F.

To program the O2 sensor voltage for a CAN vehicle, the xgauge is:

TXD: 07E00114 (bank 1, sensor 1)
RXF: 044145140000
RXD: 2008
MTH: 000100020000
NAM: O2V

This will give a full-scale reading of 1.275V

The secondary O2 sensor is similar with a coding of:

TXD: 07E00115
RXF: 044145150000
RXD: 2008
MTH: 000100020000
NAM: DSV

The xgauge on the LL website is retrieving the trim value, which has an offset of 128 and scaling of .78125, but the math is incorrect on their site.

A lot of newer, high efficiency engines use wideband sensors. Some older ones too, like the civic hx, as well as anything capable of lean burn.

See my previous post. I'm trying to read the wideband o2 using mode 01 pid 34. This works as a command, as does the short and long term fuel trim using 0106 and 0107.

The problem is the ID which is sent to the ECU. Normally this will be 0x18DB33F1, but the ID as entered in the TXD gets scrambled in a way that I can't fathom.

eg entering 07E0 results in a CAN packet:
ID 18DB0700 Data 2 1 34 55 55 55 55 55

Using 33F1 as the ID results in a packet ID of 18DB3300, but 03F1 gives 18DB0334 - the pid now has been transposed into the second part of the ID. Trying different values for the TXD ID gives CAN IDs of: 01F1 gives 18DB01F1, 02F1 gives 18DB0201, 03F1 gives 18DB0334, 04F1 gives 18DB0400 It appears that the first byte of the TXD is used as an offset, and the second byte will be zero if you use an offset beyond the end of the packet.

See my previous post. I'm trying to read the wideband o2 using mode 01 pid 34. This works as a command, as does the short and long term fuel trim using 0106 and 0107.

The problem is the ID which is sent to the ECU. Normally this will be 0x18DB33F1, but the ID as entered in the TXD gets scrambled in a way that I can't fathom.

eg entering 07E0 results in a CAN packet:
ID 18DB0700 Data 2 1 34 55 55 55 55 55

Using 33F1 as the ID results in a packet ID of 18DB3300, but 03F1 gives 18DB0334 - the pid now has been transposed into the second part of the ID. Trying different values for the TXD ID gives CAN IDs of: 01F1 gives 18DB01F1, 02F1 gives 18DB0201, 03F1 gives 18DB0334, 04F1 gives 18DB0400 It appears that the first byte of the TXD is used as an offset, and the second byte will be zero if you use an offset beyond the end of the packet.

I responded to your earlier post, but you never explained your RXF entry. Two things to look at:

When you enter 0134 in CMNDS and hit send, do you get something other than 4134xxxxxxxx back?

Secondly, what version is your SG? Looking particularly for the 3.15* version, which has CAN issues.

My RXF was wrong as the packet is padded with two dummy bytes.

Command 0134 returns 413480008002
Command 0106 returns 410680
Command 0107 returns 410780

ScanGauge reports V3.15 - I'm not sure from your post if that is the most recent firmware or the firmware with CAN issues.

My RXF was wrong as the packet is padded with two dummy bytes.

Command 0134 returns 413480008002
Command 0106 returns 410680
Command 0107 returns 410780

ScanGauge reports V3.15 - I'm not sure from your post if that is the most recent firmware or the firmware with CAN issues.

So the xgauge for lambda should work with the following:

TXD: 07E00134
RXF: 044145340000
RXD: 2010
MTH: 002833330000
NAM: LMB

or, for A/F, multiply lambda by 14.7

MTH: 00C411110000
NAM: A/F

Ah, if the ECU reports Lambda values, much easier to find A/F than with raw sensor voltage. Very nice.

Anyone with a lean-burn (Civic HX, Insight, HCH-1) and a Scanguage able to test this?

So the xgauge for lambda should work with the following:
TXD: 07E00134
RXF: 044145340000
RXD: 2010
MTH: 002833330000
NAM: LMB


No go. First the ScanGauge is generating a packet with an ID of 18DB0700 rather than 18DB07E0, and second the Honda wants to see an ID of 18DB33F1 before it responds.

No go. First the ScanGauge is generating a packet with an ID of 18DB0700 rather than 18DB07E0, and second the Honda wants to see an ID of 18DB33F1 before it responds.

Hard to understand how the CMNDS returns the correct value but the xgauge doesn't work.
Have you gotten any xgauges to work? Do all the default gauges (RPM,MPH,MAP,fWT, etc.) work? What is the SG sending for them? How do you know what the car wants to see for a mode 01 PID request?

The short answer is that the SG uses different CAN address for the xgauges from the default gauges, and it seems to be a bug.

The long answer is below.

No, none of the xgauges work. The default gauges do all work. The CAN address which the SG uses for the default gauges is 18DB33F1, but for the xgauges it is 18DBxx00, where xx is the first part of the TXD, and the last part of the address seems to be based on the first byte of the TXD.

18DB33F1 is the OBDII address for EID CAN. 18DA10F1 should work as well (= "physical power controller").

Look, it seems to me that the SG has a bug creating xgauge (but not normal) addresses with 29 bit CAN. The normal gauges create the right address according to 15765-4 - 18DB33F1. The xgauges appear to create the address as if it was an 11 bit address rather than 29 bit, but then overruns and corrupts the last portion of the address. The first part of the address is correct at 18DB, but then the second part is related to the first byte of the TXD command. The TXD commands given in the example should work for 11 bit CAN (0x7E0 or 0x7EE), but seem incorrect for 29 bit CAN, where I would expect 0x18DB33F1 or 0x18DA10F1.

The root cause for the bug is that the SG can address controllers other than the PCM with xgauges (eg battery controller), so is creating the CAN address from the TXD. This works for 11 bit but not 29 bit CAN. With 29 bit CAN the TXD should allocate 4 bytes for the address rather than 2 bytes.

Hope this helps.