03' Classic Prius and scanguageII

Hi Bob,

SG does not have the option to connect to a computer. It is a standalone unit, much like a calculater. You punch it the numbers, it displays the results.

Perhaps what you are thinking of is something like below links?

prj.perquin.com

Opendiag OBD-II Schematics & PCB Layout | Planetfall

Those can be built by DIYers using inexpensive parts and there is no need to use SG as a device to poll different codes and responses, just connect directly to OBDII port. They can either use the GPL Linux scantool or write their own programs. The PIDs can refer to my table or discover it themselves. The only problem maybe difficult to find laptop with COM port nowadays, might need COM2USB converter.

 

I have the Auto Enginuity ProLine connector, a USB-to-OBD interface and their programming manual. But I'm trying to avoid going that route, for now.

I've spent a little time looking at the audio data and so far, it looks a little 'strange.' It is supposed to be a file of floating point numbers but things are a little scrambled.

Are you doing a survey of possible command that get responses from the different controllers?

Bob Wilson

 

Hi Bob,

I 'll be trying one of those after I 've finished experimenting the DTC. I 've a rough bitmap of the HV ECU PID and suspect where the INF. code are hidden but need to verify first.

Hi w2co,

According to the repair manual, the DLC3 only uses pin 4,5,7 & 16, which means it only has 1 K Line, the L Line is not used.

 

Darn it! I'm getting a little too curious about it now.

The electrical wiring diagram ("Toyota Prius Electrical Wiring Diagram 2003 Model", EWD493U) shows the data link connector having:

	Column 1	Column 2	Column 3	Column 4	Column 5	Column 6	Column 7	Column 8	Column 9
0	pin	id	signal
1	4	CG	chassis ground
2	5	SG	signal ground
3	6	AB	airbag ECU
4	7	SIL	K-line	ECUs: Batt	Air Bag	Engine	HV	Brake	EMPS
5	8	OP3	HV ECU
6	11	OP1	transponder key ECU
7	12	OP2	HV ECU
8	13	Tc	ECU: Air Bag	Engine	HV	Brake	EMPS	MF display
9	14	Ts	Brake and EMPS ECU
10	15	WFSE	L-line to HV-ECU
11	16	BAT

I found that my Auto Enginuity required the L-line to pass the signal it sends to the HV ECU. With L-line floating, no Auto Enginuity data (see fourth reference below, pp. 10.)

I have found a few references on the net that seem to explain what is going on:

• http://www.alfa145.co.uk/obd/14230-1s.pdf
• http://www.alfa145.co.uk/obd/14230-2s.pdf
• http://www.alfa145.co.uk/obd/14230-3s.pdf
• http://lens1.csie.ncku.edu.tw/Project/MOE/97_activity/970911_presentation_02.ppt

Using the second source, the SG 0x82 consists of two fields, the upper two bits are the format:

1. 0x80 - format with physical address bytes
2. 0xC0 - format with logical address bytes

The low order, six bits are the data length:

1. 0x02 - length of two bytes after the three header bytes:
   1. format byte
   2. destination byte
   3. source byte
   4. byte #1
   5. byte #2

Because 0x02 is the length field, two bytes, there is no 'length byte'. So the two bytes that follow, are supposed to be:

1. SLD - service identification byte
2. DATA - byte
3. CS - checksum (not shown in TXD)

In the case of our Prius, the "SLD" is always 0x01. It is also consistent with being a "length" byte. Regardless, the DATA byte appears to be the requested data identifier. It makes sense that the CS is generated.

BTW, I'm finding these references are helping me understand the audio data I captured earlier. I don't have a trustable decode but I'm seeing recognizable patterns.

Bob Wilson

 

OK, I finally found the time to test the INF. code. Before testing begun, I noted down all the initial values. There already exists 1 INF. code, 115, which must have been set a few years ago when I'm testing my retrofitted Cruise Control. According to the RM, INF. code 115 means Stop Light Switch Malfunction. The other 4 codes registered '0'.

I switched off the car and waited 5 mins. or more for any charge that remains in the Inverter to be completely discharge. Then I put on my HV insulated gloves (Caution! Safety 1st) and pull out the Interlock. I switched on the car and as expected, it can't get to [READY]. I switched off the car and put back the Interlock. This time when I switched on the car, it can get to [READY] but the Master Warning Light & the Hybrid System Warning Light came on.

I use SG to scan but can't find any code. Then I checked the INF. code, 1 extra code, 350, was registered. According to the RM, INF. code 350 means Interlock Malfunction - Safety devices operating with vehicle is stopped (ILK signal ON). So it seems this code relates to what actually happened. After restart the car 3 times, the MWL & HSWL goes off by itself. The INF. code still remains though.

Here are the suspected INF. code:

	Column 1	Column 2	Column 3	Column 4	Column 5	Column 6	Column 7
0	XGauge	TXD	RXF	RXD	MTH	NAME	Notes
1	INFO. Code 1	8216F101AA	0316044105AA	2810	000100010000	ic1	XXX
2	INFO. Code 2	8216F101B1	0316044105B1	2810	000100010000	ic2	XXX
3	INFO. Code 3	8216F101B7	0316044105B7	2810	000100010000	ic3	XXX
4	INFO. Code 4	8216F101BD	0316044105BD	2810	000100010000	ic4	XXX
5	INFO. Code 5	8216F101DF	0316044105DF	2810	000100010000	ic5	XXX

If we can get more people to feedback what they have for these suspected INF. code, then we should be able to confirmed it.

 

Thanks w2co and vincent1449p, I picked up my scangauge Friday evening. A key element was seeing the 'information codes' that may finally let us read out the subcodes from P3125, the generic inverter code.

Using vincent1449p's sketch and some guesses, it looks like I can make a simple, NHW11 pass through:

• Gnd - power
• 12 V - power
• L-line - status to HV ECU
• K-line - command and status

However, it should also be useful to make a standalone, test fixture to allow programming in the house instead of the car:

• Gnd - power
• 12 V - power
• L-line - a 600-1200 ohm, simulated load
• K-line - a 600-1200 terminator resistor and a 1200-6000 ohm pull-up to 12 V. It may also need a microcontroller to handle the 5 baud initialization.

Bob Wilson

 

Excellent! I've got the parts and am making my own.

Bob Wilson

 

I took an old, ethernet cable and cut it in half:

The power cable connects a 9V battery to:

• pin 1 - negative
• pin 8 - positive, 9 V

The other end was punched down into an RJ-45 socket following vincent1449p's approach:

• pin 1 - ground
• pin 6 - K-line
• pin 7 - L-line
• pin 8 - B+, 12 V

To hold everything together, I used my favorite JB Weld epoxy.

LATE NOTE: It worked perfectly on the drive in this morning. However, it is irritating that we don't have someway to record the data for offline analysis. I understand they are planning a USB cable version (someday.)

Bob Wilson

 

Unusually high MPG?

This morning, I'd gone about 3 miles and was in S-4 at a stop light. So I reset the tripmeter, MPG, and scangauge 'Current'. When I got to work, the Prius indicated 52 MPG but the scanguage showed 104 MPG, nearly a factor of 2. Any ideas?

Bob Wilson

 

Curious trouble programming:

• MORE>MORE>MORE>XGAUGE>EDIT
• the "_" is there for ~3-4 seconds and disappears
• if fast, I've gotten up to "2" before the "_" disappears
• substituted a serious power supply for 9V battery, still broke
• version 3.17mb
• if fast, I can save and recall XGAUGE but 2-3 sec window too small

I'll send a note to Linear Logic but was curious if there is something I missed in the manual.

Thanks,
Bob Wilson

 

Hi Bob,

This happens with off-line editing and I believe it is due to the lack of keep alive signals. There is no problem if you connect directly to the car.

I wonder if pulled high K-Line or L-Line might help. If not, a simple timer circuit to send a pulse every 3 ~ 4 secs. might do the trick.

 

According to the spec, L-line comes from the instrument. However, it may help to pull the K-line up. I've seen no evidence of a 'heart beat'. However, we can't rule out the 5 baud initialization. Regardless, now that I know this is normal with the product, I can workaround it.

Bob Wilson

 

Hi Bob,

I did not find any documentation on SG regarding 'heart beat'. I 've read it from Elm Electronics:

http://www.elmelectronics.com/DSheets/ELM323DS.pdf

I also looked at the Elm323 circuit and both the K-Line and L-Line already have 510Ω pulled up internally. I suspect the SG would have internal pullup resistors as well in order to follow the spec. So, adding pullup resistors most likely not help and I think it may cause more stress to the transistors due to lower resistance.

If the SG also send 'keep-alive' or 'wakeup' messages periodically like the ELM323, then the timer circuit will not work either. The ELM323 is expecting a response pattern from the ECU to know there are still connected. That probably need a PIC to generate the required response, not an easy task.

My current workaround is to keep pressing OK, save the changes, then go back to re-edit.

 

What doesn't make sense to me is why they would be trying to 'tickle' the ISO-9141 during programming. I'll try the pull-up a little later tonight.

Bob Wilson

 

I think it has to do with response time. If the bus is not in 'sleep' mode, you can get response quicker after you sent a request. Otherwise, you need to initiate the bus first before you can send your request.

http://www.obdclearinghouse.com/index.php?body=get_file&id=1343

 

I tried a 507 ohm, pull-up resistor but it didn't work. I think you're right that we'll need an active bus. Since my adapter monitors the K and L-lines, I'll verify I can program it in the car and record the bus activity.

BTW, I've gone with MSP430s, a $25 development kit and daughter board. It looks like some glue logic and little programming is in order. <grins>

Bob Wilson