As mentioned in the thread by TS370000, I've got my geek on and am toying with some PIC chip codes to talk to the ECU on my TS. This arvo I managed to hash together a quick routine that repeatedly asks the ECU what the engine RPM is. Good news is I can see the request from my PIC going in to the ECU and the ECU responding with something, and that the "something" changes when I give the accelerator pedal a squirt, so I can only assume that it's RPM I'm seeing coming back from the ECU.

This page (http://mmcdlogger.sourceforge.net/) was helpful regarding what codes I can expect to send/recieve from the ECU. The codes given are for the 4G63 engine, whereas mine is the 6G72. According to the website the listed codes should work for other engines of the same vintage. Engine RPM (0x21) looks like it is right so far. We shall see for the others.

Interesting (annoying?) to note that the error/item codes given for the ECU in the workshop manual bear no relation to the request codes for the MUT protocol. Eg, oxygen sensor output voltage in the workshop manual is listed as "Item 11" in the MUT tables, whereas the value required to send to the ECU to read the same value is 0x13.

More later.

Some screenshots of progress so far (click for bigger):

http://i153.photobucket.com/albums/s222/ac1176/Bloody%20Cars/th_20141228_171948_zps12efcc47.jpg (http://s153.photobucket.com/user/ac1176/media/Bloody%20Cars/20141228_171948_zps12efcc47.jpg.html)

The above shot shows the datastream sending/receiving from the ECU. Time is the horizontal axis and amplitude is vertical. The shorter blips on the oscilliscope is the PIC sending "What is the current RPM?", and the taller section is the ECU replying "RPM is currently doing this". The above shot is with the ignition at On and the engine stopped, so the ECU is sending "RPM=0" (the response from the ECU is a binary signal in series, with all bits in that binary sequence at logical 0 state, or all "high" in this case).

With the car started and the engine idling at about 1000RPM I get this:

http://i153.photobucket.com/albums/s222/ac1176/Bloody%20Cars/th_20141228_171919_zps68cf5682.jpg (http://s153.photobucket.com/user/ac1176/media/Bloody%20Cars/20141228_171919_zps68cf5682.jpg.html)

Note the taller responses from the ECU have changed and now some sections are high (logical 0) and others are low (logical 1). The shorter sections are unchanged as my PIC is still requesting the RPM from the ECU.

By evaluating the high and low sections of the ECUs responses the data stream appears as 5 "1" responses (the low section) followed by 3 "0" responses (the high section). Ignore the first blip response from the ECU - that's the "start" bit telling the PIC that the ECU is about to send its data:

http://i153.photobucket.com/albums/s222/ac1176/Bloody%20Cars/Logic_zps44699d14.jpg

Because the ECU responds with its lowest bit first and highest bit last, the resultant stream needs to be reversed in order to decode correctly. Ie, "11111000" becomes "00011111". If you plug this into a binary to decimal converter (http://www.binaryhexconverter.com/binary-to-decimal-converter) the result is 31. According to this page (http://mmcdlogger.sourceforge.net/) the formula for decoding this number into actual RPM is 31.25 x 31 = 968.75RPM, dangerously close to the 1000RPM my tacho was displaying at the time I took that pic.

Also worth noting is that the baud rate for communication listed on this page (http://mmcdlogger.sourceforge.net/) appears to be incorrect. Actual measured baud rate is 1920bps rather than the suggested 1953bps.

As you gather I'm not computer language literate but I did scrap an old hard drive a couple of decades ago from a business that ran pick on it. Haven't encountered it much since then. Thanks for explaining that. I know pc hardware so I ask from that perspective. I get it's a chip that you program, what do you program it from. Is that a cathode ray tube. Can the system interface with an old win95-era pc with dos. Can it interface with a Palm IIIc running palm os 3.5? What do the cables look like. Very Interesting read-outs. Is the first wave at 1000rpm square and do subsequent waves 'deteriorate'? Why?

I get it's a chip that you program, what do you program it from.

Chip is programmed from a PC running MPLAB (http://www.microchip.com/pagehandler/en-us/devtools/mplab/home.html), which is free to download from the chip manufacturers' website. By necessity I'm running it on an old clunky WinXP machine, as the programming hardware I'm using requires a parallel/printer port to burn the code to the chip, but USB burners can be found to buy or build in kit form.



Is that a cathode ray tube.

Pictures above are from the screen my oscilliscope, which I'm just using to get visual feedback of the data stream going in and out of the ECU. It isn't a required component of the hardware I'm using.



Can the system interface with an old win95-era pc with dos. Can it interface with a Palm IIIc running palm os 3.5?

I assume you mean "can the Mits ECU data be made to talk directly with a PC or PalmPC". Don't see why not. That's what all the existing OBDII interrogating software currently on the market does. The biggest challenge will be writing the program for the PC to do the talking, something that's not my area of expertise. What I'm working on here is a self-contained scan tool, not unlike the original Mitsubishi MUT, which doesn't need a PC to operate.

At the moment it currently looks like this:

http://i153.photobucket.com/albums/s222/ac1176/Bloody%20Cars/th_20141228_172138_zpsbbff9f7a.jpg (http://s153.photobucket.com/user/ac1176/media/Bloody%20Cars/20141228_172138_zpsbbff9f7a.jpg.html)


What do the cables look like.

At the moment my connections are just three wires - two for 12V power to juice up the scan tool (taken from the cigarette lighter socket above the gearshift) and a single wire to exchange data with the ECU (pin 1 on the connector next to the fusebox). Pins 10 and 12 on the diagnostic connector need to be joined together in order to force the ECU to enter diagnostic mode, which I'm doing using a small jumper wire. At the moment my wires to the diagnostic connector are just clipped in place for testing purposes, but there is a way to make up a plug that fits in that odd-shapped connector on the cheap. I'll provide details later.



Very Interesting read-outs. Is the first wave at 1000rpm square and do subsequent waves 'deteriorate'? Why?

Not sure I follow what you're asking. The first screenshot was the waveform generated with engine at standstill, and the ECU reporting RPM=0. The second was with the engine at 1000RPM, and the subsequent waveform being generated (after conversion) indicated RPM=968.75.

My current code simply sends "Get RPM" and the ECU responds accordingly. The code then repeats the same request and the ECU replies. The cycle continues over and over until I pull the power from the chip. You can see the cycle repeating in the first two screenshots too - a section of square waves from my PIC starting at about a quarter of the width of the screen from the left followed by the response from the ECU just past the halfway point for the screen. The next request is just starting before being cut off by the righthand edge of the screen. The request/reply cycle is quite quick, takes about 10 milliseconds (100 times per second), and those screenshots are only indicating a 20 millisecond "slice" of time.

I noted the 2010 date. Presumably that was the time you were working on this last? Have you thought of making Concept/Pre-Alpha or Alpha releases as you go for more extensive testing and input? If I knew what minimum hardware to assemble then I can prepare for such an eventuality. Have you got as far as having the signal to the oscilloscope sent to a PC in any form?
http://www.dxzone.com/catalog/Software/Oscilloscope/

I do have an old oscilloscope. Can you provide a schematic and parts list for the board?

________

re 1999rpm square wave : The far left wave from the ecu looks square to me. Successive ones seem to me to be less so. ?

I assume you mean this page (http://www.geekmyride.org/wiki/index.php/Trent%27s_Magna) when referring to the 2010 date? Not my work, so I can't comment on the progress of it.

Data is only being transferred between the ECU and the PIC chip at this stage. No plans to go to/from a PC. Maybe later.

The project is in such early stages there isn't much point in posting a schematic. I still need to add an LCD to display stuff and buttons to allow the user to navigate through the menus.

"Squareness" of the waveforms isn't an indication of the RPM value being reported by the ECU. It's the pattern of the high and low points that indicate the data that must be read. As I'm using bare wires laced all around the drivers' foot well while I'm testing, the quality of the edges of the recorded squarewaves may be a little on the rough side, hence the slight curving of some of the edges recorded on the 'scope. Once I make up a proper cable I expect that the signal quality will improve.

No, I mean the date in the lower right corner of the oscilloscope pic.

Ok, I'll look forward by backing off. I won't interrupt too much. Don't want to turn something so informative into a chat. But you are talking to the chip from a pc. ? So presumably the pc can also read the chip.

Ok, I thought signal quality might be one answer, TY. It'll be interesting to see how they square up. Cheers.

No, I mean the date in the lower right corner of the oscilloscope pic.

Ha! No, that's just me being lazy and not bothering to set up the date and time on the 'scope before turning it on. Those picstures were taken the same day I posted in this thread.



But you are talking to the chip from a pc. ? So presumably the pc can also read the chip.

The only communication going on between chip and PC is when I download the program for the chip to run. After that the chip is totally autonomous and handles all the communication with the ECU by itself.

re date : Yes, of course. TY,

re the pc thing. I still don't get it. Maybe I'm asking it all wrong?
You program the chip. and disconnect the pc.
The chip communicates with the ecu.
The communication is sent to the oscilloscope which displays it in realtime.
What if the pc was to receive the signal and was to emulate an oscilloscope? If so which port would be used. audio, serial, parallel, modem . . . ?

The communication is sent to the oscilloscope which displays it in realtime.

Sorta. The oscilliscope forms no part of the data communication. All it is doing is "overhearing" what is going on. The conversation is exclusively between the chip and the ECU.



What if the pc was to receive the signal and was to emulate an oscilloscope? If so which port would be used. audio, serial, parallel, modem . . . ?

Not suggesting it couldn't be done, just not the way I'm doing it (and I also don't have the experience in making a PC program to communicate directly with the ECU). Serial port would be the way to do it if you were going to attempt it.

Ok, gotcha. Thanks for bearing with me. I'll dig out my old dos/win98 pc and explore that side of things.

[ note to self:
http://www.micahcarrick.com/pic-programming-linux.html
http://www.dxzone.com/catalog/Software/Oscilloscope/ ]

The plug that fits the diagnostic connector is a funny shape and as far as I'm aware isn't easily obtainable from anywhere. Luckily, with a little cutting, hacking, sanding and gluing it is possible to make a substitute plug out of parts available from Jaycar.

At Jaycar you need to buy some of their 0.156" pitch header assemblies. These are designed to allow wires to be connected to circuit boards, and happen to have the exact hole-to-hole spacing required to connect to the diagnostic plug. You want 1x 2 pin header (part number HM-3432), 1x 3 pin header (HM-3433) and 1x 8 pin header (HM-3438). The packs come with the associated crimp pins to fit the wires to and all up cost is about 3 bucks.

http://i153.photobucket.com/albums/s222/ac1176/Bloody%20Cars/P1040196_zpsa767c125.jpg (http://s153.photobucket.com/user/ac1176/media/Bloody%20Cars/P1040196_zpsa767c125.jpg.html)

The diagnostic plug actually has 7 pins on its lower row, so the 8 pin header from Jaycar needs to be cut down by 1. Use a Stanley knife with a fresh blade and cut off one of the end boxes from the header to reduce it to a 7 pin plug. Use extreme care with the knife as it is easy to slip and slice your fingers while doing this (ask me how I know).

The headers also come with a little locking ridge that needs to be cut off to allow them to fit into the diagnostic socket. Use the knife again to slice off the ridges from all three headers (with care!).

http://i153.photobucket.com/albums/s222/ac1176/Bloody%20Cars/P1040197_zps13d2e671.jpg (http://s153.photobucket.com/user/ac1176/media/Bloody%20Cars/P1040197_zps13d2e671.jpg.html)
http://i153.photobucket.com/albums/s222/ac1176/Bloody%20Cars/P1040198_zps911791e6.jpg (http://s153.photobucket.com/user/ac1176/media/Bloody%20Cars/P1040198_zps911791e6.jpg.html)

The 3 and 2 pins headers need to be slimmed down slightly so that they can be stacked onto the back of the 7 pin header. Use a bit of sandpaper laid on a flat surface to sand back the flat face with the notches cut in it to reduce the thickness of this edge. Don't go too far, as you still need the notches on the face of the header. Removing a bit less than 1mm of material is enough.

http://i153.photobucket.com/albums/s222/ac1176/Bloody%20Cars/P1040207_zps82dcaced.jpg~original (http://s153.photobucket.com/user/ac1176/media/Bloody%20Cars/P1040207_zps82dcaced.jpg.html)
http://i153.photobucket.com/albums/s222/ac1176/Bloody%20Cars/P1040208_zps0306cd2c.jpg~original (http://s153.photobucket.com/user/ac1176/media/Bloody%20Cars/P1040208_zps0306cd2c.jpg.html)

A 2.5mm drill bit is used to slightly widen the ends of each wire opening of the header. Although the pin spacing on the header matches the diagnostic plug exactly, the pins on the plug are slightly wider, so opening each wire hole on the header helps the finished plug slide on easily.

http://i153.photobucket.com/albums/s222/ac1176/Bloody%20Cars/P1040209_zpsf10c6505.jpg~original (http://s153.photobucket.com/user/ac1176/media/Bloody%20Cars/P1040209_zpsf10c6505.jpg.html)

Use the sandpaper again to round over the corners of each header to help the finished plugs slide into the diagnostic port better. Once all the parts are ready they can be glued together using superglue. Do a dry fit on the diagnostic port first to ensure that all the plugs will fit without getting stuck, and to ensure you position the 2 and 3 pin headers on the correct sides of the 7 pin header. Once you're sure you have each header located on the correct sides then apply thin film of superglue to the non-slotted side of the 7 pin header and fit the 2 and 3 pin headers to the back. Work quickly as the glue starts to set up fast. Clamp the parts together to allow them to dry properly. Do it in stages if it looks like it's going to be too fiddly to do it all in one hit.

http://i153.photobucket.com/albums/s222/ac1176/Bloody%20Cars/P1040210_zps6768c9ea.jpg (http://s153.photobucket.com/user/ac1176/media/Bloody%20Cars/P1040210_zps6768c9ea.jpg.html)

Once the glue has dried the wires can be crimped on to the wire fittings. There is a special tool available to crimp these fittings on to the wire, but by carefully squeezing the tabs on to the wire a small set needle-nosed pliers can be used to fit them as well.

http://i153.photobucket.com/albums/s222/ac1176/Bloody%20Cars/P1040200_zpsac7d53fb.jpg (http://s153.photobucket.com/user/ac1176/media/Bloody%20Cars/P1040200_zpsac7d53fb.jpg.html)
http://i153.photobucket.com/albums/s222/ac1176/Bloody%20Cars/P1040203_zps26365027.jpg (http://s153.photobucket.com/user/ac1176/media/Bloody%20Cars/P1040203_zps26365027.jpg.html)
http://i153.photobucket.com/albums/s222/ac1176/Bloody%20Cars/P1040205_zpsa6570574.jpg (http://s153.photobucket.com/user/ac1176/media/Bloody%20Cars/P1040205_zpsa6570574.jpg.html)

Once the wires are all crimped up they can be inserted into the plug. Push each one in until it clicks into place. The back of each crimp has a little barb on it that is designed to lock into the notch cut on the back of each header to prevent the wire from being pulled out.

http://i153.photobucket.com/albums/s222/ac1176/Bloody%20Cars/P1040202_zpse3c2ec24.jpg (http://s153.photobucket.com/user/ac1176/media/Bloody%20Cars/P1040202_zpse3c2ec24.jpg.html)

With a bit of patience the finished plug should fit perfectly into the diagnostic port on the car. Even if you don't want to bother with running some kind of scan tool, the plug makes it much easier to hook up a voltmeter for doing the self-diagnosis method of reading the error codes.

http://i153.photobucket.com/albums/s222/ac1176/Bloody%20Cars/P1040211_zpsb2a432e1.jpg (http://s153.photobucket.com/user/ac1176/media/Bloody%20Cars/P1040211_zpsb2a432e1.jpg.html)
http://i153.photobucket.com/albums/s222/ac1176/Bloody%20Cars/P1040212_zps237cbc0f.jpg (http://s153.photobucket.com/user/ac1176/media/Bloody%20Cars/P1040212_zps237cbc0f.jpg.html)

More progress:

http://i153.photobucket.com/albums/s222/ac1176/Bloody%20Cars/20150110_115128_zpse27b8d2c.jpg (http://s153.photobucket.com/user/ac1176/media/Bloody%20Cars/20150110_115128_zpse27b8d2c.jpg.html)
http://i153.photobucket.com/albums/s222/ac1176/Bloody%20Cars/20150110_115037_zps1686dbc6.jpg (http://s153.photobucket.com/user/ac1176/media/Bloody%20Cars/20150110_115037_zps1686dbc6.jpg.html)

Still ironing out bugs, but as proof of concept it looks like it works well. Currently only displays ECU data as raw unconverted numbers (coolant temp is unlikely to be 240 degrees with the engine off). Oxygen sensor readout does weird things, fluctuates wildly when idling (you can see the blurry readout in the 2nd picture). Anyone know if this is normal? At this stage I'm unsure if this indicates a problem with my PIC code, a fault with the oxygen sensor, or is completely normal behaviour for the O2 sensor.

busy making gaskets atm. will make plug as suggested.

re O2 : : halfway down http://www.autospeed.com/cms/article.html?&A=113022 indicates rapid flutuations are normal. I assume 'how much' indicates if not.

Good to know. I was seeing the readings cycling up and down between what looked to be <10 and the low 40s.

I've found that it is possible to talk to the ECU using a Windows laptop running Bray's Terminal (https://sites.google.com/site/terminalbpp/), a freeware program for directly driving a serial port on a PC (actually a fancier version of Windows HyperTerminal which was droppped after Windows XP). By setting the comms options to 1920 baud, 8 data bits, no parity, 1 stop bit and no handshaking you can use a standard serial cable, build this circuit (http://mmcdlogger.sourceforge.net/schematics.gif)and talk direct with the ECU by typing hexadecimal codes. The only drawback is that you can only type one request in hex at a time and the ECU spits a reply back out in hex, so it's still very manual and clunky, and you still have decode the response into something useful.

By running Terminal with the ECU I've been able to establish that at least one code provided on several sites for the ECU appears to be incorrect (at least for the V6 engine). Hex code 02 supposedly contains a bunch of information regarding air con switch on/off, power steering pump on/off, transmission park/neutral on/off etc. Correct code appears to be hex 00. Who knows if there are any others which are incorrect. Engine RPM, throttle position, barometer, O2 sensor, ISC count, battery volts appear to be OK based on their supposed conversion factors and what seems realistic. The others I haven't looked into and can't confirm their accuracy yet.

Very interesting stuff boys, Keep up the good work!

Have been poking around myself lately, what with O2 and Knock sensor problems.

Throw some people a bone and they'll roll their own MUT :woot:

Knock Sensor can supposedly be read by sending hex 26 to the ECU. I can't check it for validity, but when I tried it on the laptop I got hex 00 in response. Either that means my engine is working fine and I'm not getting any knock counts, or the ECU request info I have is incorrect and hex 26 isn't the Knock Sensor readout.

O2 sensor appears to be definitely hex 13. The drawback to using the laptop runnig Terminal to get the O2 readout is that it changes in value so quickly and so frequently that it's difficult to get any indication of correct operation becauise you have to manually send the requests one by one.

More later...

Still uncovering stuff as I go.

There's a little bit of info out there regarding communciation with the engine ECU, but there's nothing about the other ECUs. I guess priority one is getting the Engine ECU sorted out first, but I always envisaged getting the other ECUs to talk as well.

It appears the cruise control ECU doesn't talk directly with a scan tool at all. Shorting pin 10 to ground on the diagnostic connector does not put this ECU into diagnostic mode, and it continues to output normal pulses via its associated pin in the connector. I guess the official Mitsubishi MUT only acts as an automated pulse counter on the cruise control ECU, much like a person would do with a voltmeter when running self-diagnostic tests.

The other ECUs (ABS, transmission, SRS) appear to go into diagnostic mode when pin 10 is shorted to ground. Not surprising considering each of the wiring diagrams in the manual show a connection between these ECUs and pin 10 in the diagnostic port, and the normal pulses from these ECUs stop when the pin is shorted. I'm still yet to work out how to communicate with these ECUs, as the same communications settings and request codes as the engine ECU appear to do nothing with them. It'd be handy to have a Mitsubshi MUT handy to work out exactly what comes out of it when you select ABS, SRS or TCU systems....

Had to upgrade to a PIC with more program memory as I was fast running out of space to store all the code on the chip. Unfortunately this meant I had to rewrite a lot of my code to suit the new processor, which has held up progress a little. In the meantime I have managed to migrate the code I had done thus far onto the new PIC and have finally gotten around to incorporating most of the correct scaling factors into the ECU data. Air Temp, Coolant Temp and Timing Advance are still obviously wrong. Also started work on the beginnings of a menu structure as can be seen in the pics.

http://i153.photobucket.com/albums/s222/ac1176/Bloody%20Cars/20150126_183723_zpshuhkknag.jpg~original (http://s153.photobucket.com/user/ac1176/media/Bloody%20Cars/20150126_183723_zpshuhkknag.jpg.html)
http://i153.photobucket.com/albums/s222/ac1176/Bloody%20Cars/20150126_183739_zpsngxlxihg.jpg~original (http://s153.photobucket.com/user/ac1176/media/Bloody%20Cars/20150126_183739_zpsngxlxihg.jpg.html)
http://i153.photobucket.com/albums/s222/ac1176/Bloody%20Cars/20150126_183750_zpsxe24gsjb.jpg~original (http://s153.photobucket.com/user/ac1176/media/Bloody%20Cars/20150126_183750_zpsxe24gsjb.jpg.html)
http://i153.photobucket.com/albums/s222/ac1176/Bloody%20Cars/20150126_183800_zpsoh19dxtk.jpg~original (http://s153.photobucket.com/user/ac1176/media/Bloody%20Cars/20150126_183800_zpsoh19dxtk.jpg.html)
http://i153.photobucket.com/albums/s222/ac1176/Bloody%20Cars/20150126_183808_zpsm5gobiei.jpg~original (http://s153.photobucket.com/user/ac1176/media/Bloody%20Cars/20150126_183808_zpsm5gobiei.jpg.html)

The other potentially useful thing about the new PIC I'm using is that it has USB support, which may open up other interesting avenues in the future with regards to transferring large data logging files to a PC (eg, performance evaluation)

Still whittling away at this one.

Engine ECU interrogation is just about done. Starting to look into some of the other ECUs.

Interesting to note the following regarding the Engine ECU:

ECU status register Hex 02 is mapped differently for the V6 engines. Every site I have found on the net (including the Evoscan (http://www.evoscan.com/) site) indicate that things such as Idle Switch On/Off, Power Steering Pump On/Off, Air Con On/Off etc are held in this register. The correct register is Hex 00. The point mapping appears to be the same though (eg bit 02 is the inhibit switch on/off, bit 80 is the idle switch etc).
Related to the above, items that are supposedly stored in Hex 00 (Air Con Clutch On/Off) must be held in a different location, but I am yet to find out where this resides.
Temperature measurements for the coolant (hex 07) and intake air (hex 3A) cannot be displayed using a simple maths formula as suggested by various sites on the net, as the sensors themselves are extremely non-linear. The only way I have been able to get remotely accurate interpretations of the temp readouts is to manually create a list of data points based on actual measurements made using a separate thermometer, and substituting the values on a one-to-one basis as they come into the scan tool.


I've also made some inroads with communicating with the other ECUs, and have managed to get the Transaxle computer to exchange some data. By trial and error I've managed to find the following:

Hex 01 = Force operation of the pressure control solenoid for 5 seconds
Hex 3C = Transmission status bits:

bit 01 = selector in park
bit 02 = selector in reverse
bit 04 = selector in neutral
bit 08 = selector in drive
bit 10 = selector in 2nd
bit 20 = selector in 1st
bit 40 = overdrive switch on/off
bit 80 = power/econ switch on/off
Hex 3D = other status bits:

bit 01 = idle switch on/off
bit 10 = air con on with transmission in D
Hex 42 = throttle position readout
Hex 45 = transmission oil temperature

There are a couple of others that appear to be related to engine/transmission RPM but I have to work out what they are. Hex 35 appears to show engine RPM when the transmission is in N, but drops to zero when I put the car in D. Transmission input RPM perhaps? Lockup clutch slip RPM?

Interesting excercise and when the project matures I'd would venture into making this DIY diagnostic tool.

My hope is that if I get enough data on the various ECUs to build up a usable service tool that I'll be able to offer some kind of shortform kit - say a pre-programmed CPU and circuit board. We'll see how things progress...

A couple more TCU codes found by winging it:

Hex 3D, bit 04 = kickdown servo switch on/off
Hex 42 = engine RPM
Hex 3E = possibly transmission gear readout? Bit 04 goes active when in manual 1st, or idling in D and giving the accelerator a bit of a press (can feel the car jump into 1st while trying to take off with the park brake applied). Remaining bits in this register could indicate 2nd, 3rd and overdrive.

Will try and find a nice big empty carpark on the weekend to have a cruise around to verify some other registers while keeping an eye on the laptop screen...

In case it is of any interest, I notice that someone in WA is advertising a Mitsubishi dealers scan tool on Gumtree for $170.
http://www.gumtree.com.au/s-ad/clackline/other-automotive/mitsubishi-dealers-scan-tool-genuine-dealer-issue/1070652976

I have no knowledge of or connection with the seller so please take due care if you decide to deal with them.

Thanks for heads up, may investigate further.

A few more:
Hex 35 = Pulse generator A (input shaft RPM)
Hex 32 = Possibly pulse generator B (transfer shaft RPM) - need to doublecheck
Hex 3E = Transmission running gear: bit 08 = AT in 1st, bit 04 = AT in 2nd, bit 02 = AT in 3rd, bit 01 = AT in OD, all bits off = transmission stationary.

I've made an error and listed Hex 42 twice in previous posts (Engine RPM or Throttle Postion). Need to go back and verify which one is which.

A lot of investigative effort to discover the correlation between register contents and the cars instrumentation.
Not many people would take that path but it can end up with a nice/affordable DIY diagnostic tool.

Look forward to the progress reports.

Most of what I'm doing is just checking register contents against the tacho/speedo/shift lever/running gear and comparing with the suggested "normal" values in the service manual for various road conditions. When I see something that matches I can reasonably assume that it is one of the data items listed in the manual. Things like temperature sensors I can confirm with the car stationary by unplugging them and strapping a variable resistor across the connector to simulate rising and falling temperature - as I wind the resistor up and down I can see the register contents change in sympathy. Where I'm going to come unstuck is working out the error codes. Some may be easy to force (eg, unplug a connector on a sensor and wait for the error code to emerge), but others are going to be hard to simulate (eg, is it possible to force the operation of "2nd gear non-synchornous" error without damaging a working transmission?).

Correction to earlier posts: Hex 42 is definitely throttle position.

Hex 36 = appears to be vehicle speed (in multiples of 5kph)

Managed to find the last three service data items for the TCU.

Summarising the service data items:

Hex 32 = Pulse Generator B RPM (transfer shaft RPM, scaling factor to be confirmed, but likely [value] x31.25RPM)
Hex 34 = Engine RPM ([value] x50RPM)
Hex 35 = Pulse Generator A (input shaft RPM, scaling factor TBC, but likely [value] x31.25RPM)
Hex 36 = Vehicle Speed ([value] x5km/h)
Hex 37 = Lockup Clutch Valve (LUCCSV) Duty % (scaling factor TBC, but likely 255/[value] x100)
Hex 3C = Gear Shifter status:

Bit 01 = Shifter in P
Bit 02 = Shifter in R
Bit 04 = Shifter in N
Bit 08 = Shifter in D
Bit 10 = Shifter in 2
Bit 20 = Shifter in 1
Bit 40 = OD switch OFF
Bit 80 = Power/Econ Switch in POWER

Hex 3D = Ancillary item status:

Bit 01 = Idle Switch OFF
Bit 04 = Kickdown Switch ON
Bit 10 = Aircon Switch ON

Hex 3E = Transmission Running Gear:

Bit 01 = AT in Overdrive
Bit 02 = AT in 3rd
Bit 04 = AT in 2nd
Bit 08 = AT in 1st
All bits OFF = AT stationary (no gear selected)

Hex 40 = Pressure Control Solenoid Valve (PCSV) Duty % ( 255/[value] x100)
Hex 42 = Throttle Position Sensor V ([value] x 0.0195)
Hex 45 = Transmission Fluid Temperature (temperature map TBC)
Hex 5A = Lockup Clutch Slip RPM (scaling factor TBC, but likely [value] x31.25RPM)


Actuator tests:

Hex 01 = Force PCSV to operate at 50% duty for 5 seconds.

How is this project going?

Slowly at this stage. Car has been in and out for various repairs, work has been busy, so not much time to spare on this one at the moment.

I am hoping to get back into the swing of things soon. Need to look into finding out fault codes for the TCU, then will probably try tackling the ABS.

SRS I'm cautious about, as while the manual doesn't suggest that there is an option in the MUT to force airbag deployment, that doesn't mean that a particular code request to the SRS could do it.

Good to know You haven't abandoned the project.

Does this site give usefull info on diagnostics data?
http://www.tunerpro.net/downloadBinDefs.htm

@ ac1176 Any progress on refining the DIY diagnostic tool?

I'm probably now at a dead end. I can't extract any further codes from the transmission unit (can't work out how to decipher the error codes, can't work our what the "reset" code is meant to be) and I can't talk with the ABS unit at all. My car doesn't have the active suspension unit, so no idea what is required to talk to that computer. Too cautious to try sending codes to the SRS unit in case it does something stoopit like deploy the airbag.

So that leaves the current tally as engine ECU pretty much covered, and transmission unit done only as far as readouts of realtime data.

Whether that warrants going to the trouble of developing a PCB and final PIC code to download to a chip is up for debate, when a laptop with a terminal program can cover that quite easliy with a bit of decoding on the users' part.

??

Pity,

Maybe someone else has done this experimentation to get that data.
Would be hard to track them down now.
Still maybe a request on those forums that deal with the codes might pay dirt.

I agree though, project as is would not warrant a dedicated test unit.
But getting the data displayed on a laptop would make the effort so far still useful and interesting.
I would need help with that (as most people would!).

Maybe consider finishing the project as "laptop diagnostic".