please refer
http://mmcdlogger.sourceforge.net/
I have made one( the first circuit, not the second ) and test on my magna tr 2.6,
intending to get the some parameter.
but something confusing me.
when i send through rs232 data to aldl interface,
whatever number i sent, whatever number i get.
for example, i sent 0x06(timing angle ), I received 0x06.
in order to find why, I research the max233 package.
sent throug rs-232 pin 3, to max232 pin4( rs232 in)
pin3( ttl output), pin3 connected to pin2(ttl in ), then pin 5 rs232 out,
exactly will send across 2n2222a , then to pin19, pin20 output, connect to pin1,
then in the end, output pin 18, to rs232 pin2( receive ).
It seems exactly whatever sent, what ever get.
So there must be some skill to use this circuit, time interval for send and receive?
Is someone have experience for this.
TR, only have one data line, for both input and output.

my frequency for sent data is one second

you actually built one from scratch

being christmas they may be away may not pick up your post for a while........ hang in there
there maybe some one in the forum ...equal to the knowlage and skill you have
and answers you seek.... possibly from a member from austrailia wide

I just did an advanced search in the whole forum and came up with a blank

only mutt ll and obd1 diagnostics tools

your unit may not diagnose a TR 2.6 ..even though it says it should work in pre OBD2s

he is only making an assumption it will ...he only varifies it works on his galant
and put in a disclaimer just to cover himself


All following info has been verified on my Mitsubishi Galant E33A (4G63 SOHC), but it should apply on other pre-OBDII ECUs as well. There's absolutely NO WARRANTY on info and software, you can use it at your own risk.

i guess you would have to research what is different in the galant set up .or compare a real OBD1 unit

now i see why we can only find solid info on the Mutt II and OBD1 diagnostic for this model


best contact the author ...what do you think ????

I note the stuff you have seems to be of US origin. The following comments are meant to assist you.
1. The mitsubishi stuff seems to be different to OBD based designs. It is not clear whether there are some "USA Specifics" which come into play here. The US market and regulations are different to the Australian market and regulations. For example, it is not impossible that the 'American design rules' go so far as to specify the data formats to allow US based technicians to use their normal 'general motors type' equipment on all car designs.
2. I have looked at the possibility of designing and building a scanner for a magna but the main hurdle is to get the fundamental design data on the sequencing of data from the various units. One needs to be able to identify the bit stream and to block it off correctly.
The problem you have seems to be an inability to separate the two sets of data; ie between address and data content.
Its a bit like the people who write software for the 'windows' environment. The main problem is not to write code for the application, but to integrate it into the operating system. I think your problem is along this line; BUT I may be wrong.
3. you refer to the TR magna, and I thought this model can be diagnosed with a LED test lamp. Again, I may be wrong.
4. The hardware use in these things, I thought, was based on the Philips I2C bus and not the 3 wire bus, and again, I'm not sure what bus structure is used in OBD although I thought I2C.
5. The MAX233 is only a driver; not a register or anything like that. It will only buffer/isolate the data from the processor.
6. I've seen the type of stuff in the web reference you give. It looks SO good its almost believable. Have a look at the multi colour graphs. This sort of stuff takes a man-year to get right.
7. AND by the way, have you got an oscilloscope?

hope this helps.

1. in this thread
http://www.aussiemagna.com/forums/showthread.php?t=44121
they also discuss about the same thing.
If you study the ALDL interface in Magna 92 tr 2.6,
this circuit seems obviously it should be able to apply.

2. My original intention.
I IGN on, and use voltmeter to connect pin 1 and 12, got error code 31( knock sensor ).
I doubt that it may be not the knock sensor fault, but the timing angle(the other choice, timing gun is quite expensive ).
So i followed the instruction and made the circuit.
Furthermore, I want to get more other data from ECU.

3. for:
only mutt ll and obd1 diagnostics tools
re:
mutt11 should be expensive, and also too old to find somewhere to buy.
does odb1 apply? most document say it is a mitisubishi protocol, not international obd protocol.

4 for:
The problem you have seems to be an inability to separate the two sets of data; ie between address and data content.

re: you are right, I also confuse how it separate the procedure of sending and receiving when only use the same data line channel.
But how does MUT II works? there must be some right ways.

5. for:
you refer to the TR magna, and I thought this model can be diagnosed with a LED test lamp. Again, I may be wrong.

re: you means getting the error code, there is no problem, I have done it, refer the above 1.
what I want to fix is to getting the running sensor data etc, not just errorcode.

6. for:
The hardware use in these things, I thought, was based on the Philips I2C bus and not the 3 wire bus, and again, I'm not sure what bus structure is used in OBD although I thought I2C.

re: in terms of my knowledge, I2C technology should be deveoped later than 1992. May be I am wrong.

7. for:
The MAX233 is only a driver; not a register or anything like that. It will only buffer/isolate the data from the processor.

re: you are right, no buffer, but if max233 does nothing, just waiting, if ECU send back some data, the receiving should be no problem.

8. for:
AND by the way, have you got an oscilloscope?

re: I have not oscilloscope. If I have, it should be easier to find why?

9. Now it seems that, whatever number it send, whatever number it should receiver.
Because when RS232 use the same bus to send data to ECU.
Also RS232 receiving detect the same data,
So receiving what it send is not a matter of problem.
The only thing is that, when the ECU send back data, should receive the data.
So it seems that the ECU does not send back data( or does not detect the data sent from RS232 ).
But I have followed the instruction -- connected the pin 10 and pin 12

Mike,
I cant add a lot more;
The i2c bus was originally announced in around the early 1980's. It is a 2 wire bus where the state of the bus lines are toggled in such a way as to allow a device to become bus master. The timing is critical and a cro is needed to check if all is OK.
The thread you refer to confirms in my mind, how hard it can be to make sense of this stuff, where the people solving the problem are doing it on their kitchen sink. That thread just went blank in 2007 and it was obviously too hard to resolve the questions. If I am wrong, I suggest you contact the guys who contributed to the thread.
All manufacturers now LOVE the idea of microprocessor controls. They can do whatever they like to force you into using their knowledge base at a fee. This increasingly complex field of engine diagnostics fits right into the business plan and to reverse engineer this stuff takes a lot of hard yakka. I was reading some blogs from guys who have original japanese Toyota Prius cars; and one of them had the actual factory test set to diagnose motor conditions. The whole thing was done in japanese and was almost impossible for him to decipher the output readings. Without the test set it is impossible to diagnose a prius that wont start.
for what its worth.