Archives

Hi All from a newbie,

I'm trying to learn how to program an XGauge ISO PID that uses 2 Bytes of data in the MTH Calculation. Such as is used in RPM or FPR. So I can add some to my ScanGauge. I'm particularly interested in MAF & Fuel Tank/EVAP Pressure. I haven't figured it out, yet. I'm still waiting for an additional response from LinearLogic.

I did want to share this XGauge Coding information file I received from them, in the hopes that others may find it useful. It really should be in their User's Manual. I didn't find it on your site/forum. So, I hope it isn't a repost. If so, the newb apologizes.

XGauge Coding.rar (http://www.cleanmpg.com/forums/downloads.php?do=file&id=24)

If anyone has any info they can contribute on the 2 Byte math functions, I'd really appreciate it.

I'm not really a hypermiler. But, I am FE minded. My 2002 Celica GT-S currently manages around 35/6 Winter and 38/39 Summer on a 150 mile roundtrip daily commute. My total MPG for all driving over the last 30K miles (about a year) is 36.93MPG. Which does exceed the EPA 32 Hwy MPG:D So, I am interested in learning techniques that will improve upon that.;)

Thanks,
2way

I think that if you exceed EPA, that makes you a hyper-miler. Welcome, and thanks for the data. I'm trying to figure out the X-Gauge thing myself.

Louis B

I've got the simple ones figured out... the ones that send back a single value (although the two's complement math is interesting to figure out). Its the ones where you need 2 values to compute that it seems XGauge doesn't support and they have to be hardcoded into the ScanGauge.

Hi All from a newbie,

I'm trying to learn how to program an XGauge ISO PID that uses 2 Bytes of data in the MTH Calculation. Such as is used in RPM or FPR. So I can add some to my ScanGauge. I'm particularly interested in MAF & Fuel Tank/EVAP Pressure. I haven't figured it out, yet. I'm still waiting for an additional response from LinearLogic.


I found a document called "xgauge coding information" recently, and I guess it is the same as your .rar file. Interesting stuff, but confusing also.

Clearly the MTH function of scangauge can not operate on two data bytes.

Anyway, for example, the RPM reading could be displayed at least partly by using only the A-value in a calculation. The B-value represent only the 256/4=64 RPM, while the A value represent rpm from 64 to 16000-and-something RPM

You could easily get around that by shaving off digits so that f.ex 2340 RPM is displayed like 2.3 x1000 RPM. Maybe the special RXF value 'offset 2:value 4" will be useful as it will divide the data by 100...

This is similar for many other values requiring math on two bytes of value...

Clearly the MTH function of scangauge can not operate on two data bytes.Appears so. Unfortunately, most of the things I'd like to add require the 2nd byte as a multiplier or divisor.

I'm also looking for any info on Toyota specific PIDs and commands (ISO).

It seems to me that it can operate on greater than a byte, such as the RPM value above.

You have to set the second half of RXD correctly, so that you are looking for 16 bits or 0x10 bits. So, lets adjust the example in the coding doc:

RXD = 3008 is last 8 bits of return packet.
RXD = 2810 is last 16 bits of return packet.

You need to be a bit more careful with the math multiply/divide and offset so that you never push the value over 4 bytes.


As for responses that have a byte of multiplier or divisor, yeah, I'm not seeing an obvious way to do that.

-mr. bill

As for responses that have a byte of multiplier or divisor, yeah, I'm not seeing an obvious way to do that.Me either and LinearLogic hasn't responded on my query of that.

Can you post an example request/response where one byte is a multiplier or divisor?

-mr. bill

01 10 2Bytes MAF air flow rate Min 0 MAX 655.35 Units g/s ((256*A)+B) / 100

Great. Those should work fine. That's just a 16 bit number. 65535 is just 2^16-1. The divisor is 100, or 0x64.

That's why the units min/max goes from 0 to 655.35 (65535/100).

-mr. bill

So, I can treat it like a single 16bit # & just use a divide by 100? i.e. a 2Byte #. Kewl
Now, if I could just get the Toyota Specific ones :)

So, something like this?:
TXD 686AF10110
RXF 044105100000
RXD 2810
MTH 000100640000

I did this in a hurry.... so, be gentle.

Or do I need to do something the 256*A?

At first glance, that looks about right. (I haven't had espresso this morning yet.)

But everywhere you see documented (256*A+B) that's just a conversion of two bytes into a single 16 bit value. If the Scangauge was doing byte math, you'd have do do something with 256*A.

But since it can do 16 bit math (with a 32 bit intermediate result) you can ignore the 256*A.

-mr. bill

Kewl. Just noticed that your in MA, too!

I never really had to deal much w/hex..... mostly very low level binary. So, I'm not seeing anything that should be a math problem then:) Just me being uneducated in the ways of the force.

Hmm... now to find time to play with the scangauge. I still haven't had time to add xguages to the one in my less driven car.

TNX -mr. bill

-Bill

I've just install a ScanGauge/XGauge in a 2006 Honda Civic, and would like to add additional guages for Lambda, Short & Long Term trim, but are struggling with the XGauge encoding.

The 06 Civic uses CAN. For example, for the short term trim, I'm using:

TXD: 0106
RXF: 014100000000
RXD: 2008
MTH: 00C80100FF9C

I get no gauge activity. I believe the issue is the Can ID needed for the TX command, but trying 07E00106 produces no result either. If I use 'command' for a manual command (without any ID) the ECU responds correctly.

Is there some magic CAN ID which will work, or is it vehicle specific? Is there something in my filter or data location which is wrong? Any other ideas?

I've just install a ScanGauge/XGauge in a 2006 Honda Civic, and would like to add additional guages for Lambda, Short & Long Term trim, but are struggling with the XGauge encoding.

The 06 Civic uses CAN. For example, for the short term trim, I'm using:

TXD: 0106
RXF: 014100000000
RXD: 2008
MTH: 00C80100FF9C

I get no gauge activity. I believe the issue is the Can ID needed for the TX command, but trying 07E00106 produces no result either. If I use 'command' for a manual command (without any ID) the ECU responds correctly.

Is there some magic CAN ID which will work, or is it vehicle specific? Is there something in my filter or data location which is wrong? Any other ideas?
If you get the correct response with the CMNDS function, the xgauge will work if the coding is correct. I don't understand your RXF entry.


The coding for a CAN reading of STFT is correct on the SG website, although I would set the display to read a decimal point.

TXD: 07E00106
RXF: 044185060000
RXD:2808
MTH:07D00100FC18
NAM: SF1

So, I can treat it like a single 16bit # & just use a divide by 100? i.e. a 2Byte #. Kewl
Now, if I could just get the Toyota Specific ones :)

So, something like this?:
TXD 686AF10110
RXF 044105100000
RXD 2810
MTH 000100640000

I did this in a hurry.... so, be gentle.

Or do I need to do something the 256*A?That worked :D However, now I need to figure out the math to get at least one place beyond the decimal point.

That worked :D However, now I need to figure out the math to get at least one place beyond the decimal point.

just change your RXF to 044145100000
and your MTH to 000100010000

and you will get up to two digits after the decimal.

Thanks, Carl! I hadn't had a chance to look @ it. You're a great timesaver;)
Now, if I could find a Toyota specific list..... I wonder if LinearLogic belongs to ETI? http://www.etools.org/

RXF = 044185100000
MTH = 0001000A0000
should give me one decimal point, right?

Actually, I like your's better. It gives 2 places after the decimal on single digit numbers and one place on double. Thanks again.

hi Guys,

I am from Singapore and just got my ScanGaugeII. I am driving a 2007 JDM Honda Stream with the R18 engine. SGII has got no problems with the built in gauges but I cannot seem to get any respond for the xgauge codes... not even the ones on SG website..

even when I try to enter these TXD codes in the command, it doesn't receive any respond... No idea what is the problem.

any help is appreciated. Thanks!

hi Guys,

I am from Singapore and just got my ScanGaugeII. I am driving a 2007 JDM Honda Stream with the R18 engine. SGII has got no problems with the built in gauges but I cannot seem to get any respond for the xgauge codes... not even the ones on SG website..

even when I try to enter these TXD codes in the command, it doesn't receive any respond... No idea what is the problem.

any help is appreciated. Thanks!

It seems that the CANLF on Hondas has some problem. If you go to mode, does yours show CANLF? I don't have a Honda to test, but hopefully Ron can figure out what is going on.

Thx Carl,

yes... mine is in CANLF mode... sigh... i am very much interested in the xgauge readings for my car..

Mr Ron, do your best please..;)

It seems that the CANLF on Hondas has some problem. If you go to mode, does yours show CANLF? I don't have a Honda to test, but hopefully Ron can figure out what is going on.
There is a bug with ScanGauge creating 29 bit CAN addresses, where it messes up the CAN address. I've even narrowed down the problem area for you. Refer to my post on 03-06-2008:

"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."