03' Classic Prius and scanguageII

SUCCESS!

I programmed an XGAUGE for MG1 torque and it works perfectly. The key was letting the Scangauge recognize the car. Thereafter, it was straight forward.

Bob Wilson

 

This makes sense. MG2 handle regenerative braking so you're seeing the ohmic heating as it works as a generator.

By pure chance, on the drive home I had on the Scangauge:

• ICE rpm - also available on Graham miniscanner
• MG1 torque - also on Graham miniscanner
• instant MPG - only on Scangauge, calculated?
• coolant temperature - not used in this case

Because I'd recorded and plotted the BSFC for our 1.5L engine using Graham data, I was able to drive keeping the ICE in the peak efficiency band. So if I saw the ICE running and MG1 torque low, I would 'trick' it to go off. Ad hoc impressions, it appeared to do some good but I was also struck by the need to record the data.

A couple of years ago, I built a thermistor spoof circuit:

This interface is operated by an MSP430, a TI, $25, development system:



What this means is I can adjust the circuit for 12-14 V operation and build out a K-line and L-line monitor and control. With the USB programming interface, it can report the data as a stream to a laptop. Regardless, the operation of the MSP430 will be completely under software control.

After building out the box, we can write software for these versions:

• data logger, layer 1/2 - passive capture for the initialization sequence and framing (aka., pulling data bytes from the streams.)
• standalone Scangauge - using the initialization sequence, this will allow us to program Scangauge in comfort.
• data logger, layer 6 - report via USB text in CSV format for easy analysis. This will include multivalue packets such as MG1 rpm and torque.
• data system, layer 6/7 - interactive with the laptop, it does an exhaustive test of commands and reports the results . . . survey the ECUs to see what comes back.

I'll have to mod the circuit a bit to deal with a 12 V system but it shouldn't be a big deal. Two lines at these speeds, piece of cake.

Bob Wilson

 

I've got a rough design ready for review:

The box cover holds the two RJ-45 connectors and a USB connector wired to the EZ430 development system. The F2013 provides a microcontroller to monitor and report data using the debug system. For accuracy, a watch crystal ensures accurate timing.


There are four operational modes:

• bit timing - used to understand the initialization protocol and bit timing of the data bits. Documentation references a 5 baud sequence.
• SG standalone - spoof the ECU so the ScanGauge will report "connected" and allow programming in the house
• Data recording - wire-tap the L and K-lines and report the data in excel compatible, decimal. A simple lookup table can convert to hex as needed.
• Data sequence and recording - in this mode, the laptop software exhaustively tests the different commands and reports any results. The loop can also look for the other ECUs.

In this mode, bit state transitions are reported by timestamp. The software is a little tricky because of the limited memory but tweaking the timers and judicious compression should allow up to 100 bit transitions to be recorded.


In this mode, the laptop loads code to respond to OBD scanner initialization. Several methods are mentioned and each scanner will have to be tested. But only the ScanGauge is our target.


In this mode, the traffic is reported in CSV mode to be excel compatible. The length and CRC bytes are reported first followed by the data values.


In this mode, the laptop under software control sends sequences to be tested and the results reported. It will scan all values.


This shows the power requirement. To protect the 5V USB supply a fast acting fuse will be installed.


The 12 V. supply is not used and a DC-to-DC converter that steps up the USB 5 V. provide scanner power. I measured the ScanGauge power drain from a 9 V. battery as ~80 ma. So the system and glue-logic work from the 5 V. supply.


This circuit should provide a logic monitor on one pin to the F2013 and a second pin can pull-down the line as needed to set a bit. I'll need to check the resistance values to make sure everything works as expected. I may also need some caps to minimize ring. Otherwise, piece of cake.

Bob Wilson

 

Check Wiki but usually USB is limited to 500 ma. Fortunately I found some 5V to 12V, DC-DC converters on EBay for $6. After measuring the Scangauge at ~80 ma @9V, this should work. The diode is a wire-OR so we'll always have power for the Scangauge and other OBD devices.

It is a Texas Instruments part, F2013, and I would recommend:
http://focus.ti.com/lit/ds/slas491e/slas491e.pdf

Google up the EZ430 and you can find complete system documentation including the bi-directional, USB stick. The USB stick provides full debug as well as a programming interface. At $25, it is a nice, affordable, turnkey system.

Bob Wilson

 

I've made a couple of Scangauge adapters with 9 V. battery terminals and a protection diode replicating vincent's adapter. This allows the Prius to provide ISO-9141 initialization and bring the Scangauge in to configure XGAUGEs.









That should be clear enough. <grin>

Details to follow after the epoxy sets.

Bob Wilson

 

I managed to get the SGII to display DTCs:



MORE=>MORE=>CMNDS

	Column 1	Column 2
0	CMNDS	Response
1	8316F113FF00	87F1165315203140000087

CMNDS
83 - Physical addressing, length 3 bytes (13FF00)
16 - Target address, HV ECU
F1 - Source address, SGII
13 - Mode $13, SAE J2190
FF00 - All Function Group

Response
87 - Physical addressing, length 7 bytes (53152031400000)
F1 - Target address, SGII
16 - Source address, HV ECU
53 - Mode $53, positive respose to Mode $13
1520 - 1st DTC
3140 - 2nd DTC
0000 - 3rd DTC
87 - CRC or Checksum

Decode DTC
The 1st two bits of the 1st nibble:

00 - powertrain
01 - chassis
10 - body
11 - undefined

1520 => 0001 0101 0010 0000
________P__1___5____2____0

3140 => 0011 0001 0100 0000
________P__3___1____4____0

P1520 - Stop Light Switch Malfunction
P3140 - Interlock Malfunction

This agree with my previous reported INF. code 115 and 350 respectively.

I think the reason why SGII can't display the DTC using SCAN function may be it is using Mode $03 (SAE J1979) which only scan for emission-related DTC. Mode $13 can scan both emission-related and non-emission related DTC.

 

Huh?

So we can read the whole response in hex and not just the selected bytes formated for XGAUGE readout?

I was working under the impression that with XGAUGE we could only read out one of multiple values to display. But if we can get the hex value of the whole response packet, perfect.

Excellent! This completes a major challenge. Interesting that it shows three values, the same as the Graham miniscanner. It begs the question of whether using the battery ECU as the target with the same code if we'll get three values in a hex response.

Are we still limited to just two ECUs, HV and battery?

Thanks,
Bob Wilson

 

Hi Bob,

Yes, CMNDS can be used but the filtering is not good. Sometimes you don't get the correct responses and you have to keep sending until you get the valid responses. I only use it for testing.

OTOH, Xgauges has RXF that do the filtering for you. The drawback is that it can only display up to 5 characters on the display.

The format is the same for other ECUs. You just have to substitute $16 for $D5 and it will display the DTC for battery(if any).

So far, I only got responses from HV & Battery ECU, no response from ECM and others. That is why a lot of my basic gauges from SGII are showing blank. I believe yours has no problem since your MPG gauge is working.

The ECM is typically located at $10~$17:

You can use CMNDS to find out ECM address:

	Column 1	Column 2	Column 3	Column 4	Column 5	Column 6
0	CMNDS	Response	Remarks
1	821xF10100	86F11x4100aabbccddCS	try x from 0 to 5 and 7	6 is known for HV	aabbccdd are 4 bytes bit-mapped PIDs	CS is CRC

e.g. aabbccdd = BE1FB811

PID 01 ........................10........................ 20
$1x: 10111110000111111011100000010001

'1' is PID supported, '0' is not supported. So, PID $01, $03, $04, $05, $06, $07, $0C, $0D, $0E, $0F, $10, $11, $13, $14, $15, $1C, $20 are supported.

Since the last PID $20 is supported, that means there are some more PID from $20 ~ $3F. You can continue to send mode $01 PID $20 to get their bitmap. If the last one is even, i.e. no more PID, you can stop.

e.g. to set up Xgauge for PID $0C.

OBD-II PIDs - Wikipedia, the free encyclopedia

	Column 1	Column 2	Column 3	Column 4	Column 5	Column 6	Column 7	Column 8	Column 9
0	Mode (hex)	PID (hex)	Data bytes returned	Description	Min value	Max value	Units	Formula
1	01	0C	2	Engine rpm	0	16	383.75	rpm	((A*256)+'B')/4

	Column 1	Column 2	Column 3	Column 4	Column 5	Column 6	Column 7	Column 8
0	XGauge	TXD	RXF	RXD	MTH	NAME	Notes
1	Engine Speed	821xF1010C	031x0441050C	2810	000100040000	rpm	XXXX rpm	substitude x for ECM address

RXD - $28 => 40 decimal, starting from bit 40 or 6th bytes onwards.
RXD - $10 => 16 decimal, 16 bits since there are 2 data bytes returned.

The formula ((A*256)+'B')/4 => High byte (A) and Low byte ('B'). SGII will auto compute 16 bits number so no need to put into MTH.

MTH - $0001 => 1 decimal, multiply
MTH - $0004 => 4 decimal, divide
MTH - $0000 => 0 decimal, addition or subtraction

You can check your newly created rpm against the SGII basic gauge RPM if they are the same.

 

Here are the Xgauge alternatives to CMNDS:

	Column 1	Column 2	Column 3	Column 4	Column 5	Column 6	Column 7
0	XGauge	TXD	RXF	RXD	MTH	NAME	Notes
1	HV DTC 1 (emission & non-emission related)	8316F113FF00	03161453	2010	000100010000	HC1	XXXX hex.
2	HV DTC 2 (emission & non-emission related)	8316F113FF00	03161453	3010	000100010000	HC2	XXXX hex.
3	HV DTC 3 (emission & non-emission related)	8316F113FF00	03161453	4010	000100010000	HC3	XXXX hex.
4	Battery DTC 1 (emission & non-emission related)	83D5F113FF00	03D51453	2010	000100010000	BC1	XXXX hex.
5	Battery DTC 2 (emission & non-emission related)	83D5F113FF00	03D51453	3010	000100010000	BC2	XXXX hex.
6	Battery DTC 3 (emission & non-emission related)	83D5F113FF00	03D51453	4010	000100010000	BC3	XXXX hex.

DTC 1, DTC 2 & DTC 3 can only be read one at a time.

 

This is a really exciting thread. I wonder, with Bob's work on an OBD monitor, if it will become possible to work out the commands that do things (besides just the ones that clear codes).

Fortunately the NHW11 doesn't have so many things that can't be done some other way (flash codes for DTCs, door dances to program keys, etc.) ... it even looked to me like even brake bleeding on the NHW11 would only require control of one solenoid, which could be done the Old Fashioned Way(tm) if there was no way to command the ECU (but it would be nicer to have the command).

But it would be really nice to have the command to crank the ICE for a compression test.
I have a new set of spark plugs at home, and figure that if I'm stuck with a car where I have to DISASSEMBLE THE WINDSHIELD WIPERS to change the spark plugs, it would sure be a good time to get compression readings too....

-Chap

 

You don't need to remove the windshield wipers to change the spark plugs.

 

I think it all depends whether the diagnostic routines are resident inside the ECU or downloaded by the tester.

For the former, if you know the Test Number, you can use Mode $31 to start the diagnostic routine, Mode $32 to stop and Mode $33 to get the results. If you know the specified address, you can use Mode $38 to enter the diagnostic routine by address, Mode $39 to exit and Mode $3A to get the results.

For the latter, there is no way except to use THHT or Techstream.

I 've only experimented with Mode $01 and Mode $13. These are read-only modes and it does not cause any problem even if you sent the wrong PID, it just displays blank.

Mode $31~$33 and $38~$3A are totally different. Without knowing the exact diagnostic routine and their functions, experimenting with it could be fatal and possibly crippled the car.

I read in another thread that you have the ELM scanner. I suggest you first try to program in the PIDs rather than getting SGII. SGII has no option to connect to PC so it is PITA to key in the PIDs and can't do data logging. I think ELM is default to functional addressing. To change to physical addressing, you need to change the Set Header command; ATSH 8n 16 F1 or ATSH 8n D5 F1 where n is the no. of data bytes. The returned values are raw values so you might need to write you own program to do the conversions.

If that doesn't work out, you can always get the Mongoose cable which I think is much better suited to your needs.

 

Wow! I had missed the Mongoose+TechStream news. See what I get for not reading the forums for a while?

I'm sure I'm dreaming here, but has anybody got TechStream (and the Mongoose software layer) to run in any OS other than Windows?

Understood - I would never have suggested trial and error, but I was wondering whether Bob's work could possibly lead to a passive OBD monitor that could observe the traffic from a THHT while invoking those functions. Now with the ability to run TechStream with a Mongoose, it might be even easier to use library interposition at the J2534 layer. There might be something in the TechStream EULA where you promise not to do that.

Thanks for that tip! I hadn't got that far in playing with the ELM yet. (I had thought I was making the most convenient choice by getting the USB version of somebody's ELM cable, which turns out to just have a generic USB-serial chip stuck in front of the ELM, but the particular USB-serial chip wasn't recognized by the usb-com driver in my OS. I had downloaded that chip's datasheet and was deliberating whether to add code to the driver for it or just write something over libusb for my specific purpose, then other things came up.)

-Chap

 

I was wondering what happens if the "for <100 only" version is used with currents exceeding 100.

Just to test how the scale-by-10 feature in an xgauge works, I created a mph xgauge with the scaling changed (multiplied by 20 and set the high bit in rxf[2] to get a display with one decimal place). I multiplied by 20 instead of 10 so I could watch the gauge overflow by driving only 50 mph instead of 100.

At the point where the reading exceeded 99.9, the scangauge just reverted to a 3 digit integer display and had no trouble displaying 100 and higher. So, I thought the XX.X A version might be ok even for >= 100 A.

I guess there could be a difference because the current can go negative while mph can't ... ok, I just tried my mph gauge with "add" of -1024 hoping for a display of -102 and I saw the problem. The scangauge will display a funky value when the reading passes -XX.X on the negative end, though it behaves nicely and shifts to XXX on the positive end. Too bad.

I wonder if Linear Logic would consider that a bug and improve it in the firmware? It would be nice if they could fix the only-1-gauge-per-txd/rxf limit too; I can't think of any reason in principle they couldn't.

-Chap

 

Do you suppose the root problem has been duplicate RXF all along? Gauges with the same TXD would naturally have the same RXF also.

If I had to guess how the SG worked, I'd imagine it sends out the TXDs every so often, and waits for messages to come in. When any message comes in, it gets checked against the RXFs for the four displayed gauges. They probably just stop at the first match. I'm sure they could afford to just check all four for every message (I don't care how slow a uC they're using!).

I guess that could increase memory use, if now they modify the message in place for MTH etc.; they'd need to keep the original msg around for checking the remaining RXFs.

It would sure make the SG more useful to be able to view closely related gauges at the same time. If they were to fix that in the firmware I would pay them $25 for an upgrade the same way they worked the upgrade to xgauges.

-Chap

 

Oops! What I meant to say was -99.9A to 999.9A. If you were to change the multiplier to 200, the same overflow will happen too. It is not limited to the negative side but because of the smaller range (one character to display the minus sign) as compared to the positive side, it is more prone to overflow. I'm not sure you can call it a bug, they could simply say it is a wrong usage of scaling and offset. Perhaps it would be nice if they consider to display blank or some other thing rather than some funky value when an overflow condition occurs?

 

Yes, you are right. Initially, what I 've read from other forums only mentioned TXD cannot be the same. What I 've found out later is RXF should be different!

That is true if you are using physical addressing. Sometimes, functional addressing may need to be used if you don't know which ECU to address or which ECU may response. e.g. read DTC. I don't have DTC from various ECU so I 'll just show how the same TXD can have different RXF.

	Column 1	Column 2	Column 3	Column 4	Column 5	Column 6	Column 7
0	XGauge	TXD	RXF	RXD	MTH	NAME	Notes
1	PIDs supported by HV ECU	686AF10100	031614410500	2810	000100010000	p16	1st 2 bytes in hex.
2	PIDs supported by Bty ECU	686AF10100	03D514410500	2810	000100010000	pD5	1st 2 bytes in hex.

That is something I don't understand too.

I agree.