The Top DSM Community on the Web

For 1990-1999 Mitsubishi Eclipse, Eagle Talon, Plymouth Laser, and Galant VR-4 Owners. Log in to remove most ads.

Please Support RTM Racing
Please Support ExtremePSI

General Thinking of Building a Very Basic 1G OBD1 Diagnostic Scan Tool

This site may earn a commission from merchant
affiliate links, including eBay, Amazon, and others.

This site may earn a commission from merchant affiliate links, including eBay, Amazon, and others.

XC92

Proven Member
1,570
357
Jul 22, 2020
Queens, New_York
Yes, I realize that several already exist and are very mature, reliable and respected, but they're for tuners, of which I'm not one nor likely to become one any time soon. Way above my current pay grade and my stock 1G DSM. Plus they're kind of pricey.

Rather, I'm looking to build a fairly basic and cheap OBD1 scan tool, initially to read one of the dozen or so OBD1 codes that a 1G ECU can put out so I don't have to do the buzzer/analog multimeter/LED thing, and perhaps eventually to read ECU engine codes, but that would be a ways off.

The initial, OBD1 version would likely be built around a mini Arduino board, with an LED display and some buttons. Very basic stuff. It would literally just output any codes put out by the ECU, and store them so you could toggle between them if there was more than one.

Although it's been a few years, I have a decent amount of Arduino and programming experience so I don't need any help there. I'm thinking some pullup (or pushup) resistors to read the codes from one of the analog ports, some basic C++ code to process and output them, and some soldering on a small circuit board to connect all the components, and maybe a small enclosure to house it all. I'm confident that I can do all of this.

What I need to know is what specific kind of connector I need to buy that plugs into a 1G DSM's diagnostic port, ideally already wired so I don't have to crimp every pin that 1G DSMs use. But if I have to do that, I'm sure I can handle that too. I have some crimping tools and would just need to know what kinds of wire-end crimping connectors to get. MOLEX, perhaps?

That would be Version 1. Pretty basic stuff.

Version 2 would read and display all the data coming from the ECU, e.g. RPM, O2 level, coolant temp, etc. That would be a whole other thing and a lot more involved, and much further down the line. I'm not even sure that an Arduino could handle all the data streams in real time, and I might have to go with a Raspberry Pi, with which I also have some experience but more on the software than hardware side.

What I'd need to know there is how to actually read all those other pins, which I assume put out all this other data. Is it proprietary to whoever currently owns the DSM ECU firmware, be it Chrysler, Mitsubishi or whoever, and to ECMLink and any other companies that may have reverse engineered it? Or is it public domain and legally available for download, and if so where?

And no, I'm not looking to compete with these companies as I don't have the auto and tuning expertise to do that, nor any interest in doing it (so he says, I'm sure you're thinking!). I just like to tinker with electronics and thought it would be a fun project, especially Version 2 if I ever got to it (let alone Version 3, which would output the data to a phone, tablet or laptop app and which I'll probably never get to as I've never written an app and have no idea how to).

Also, if I did get around to doing this, I'd post the schematics, design and code so that anyone else with the ability and inclination could build one as well for $10-$20. Version 1 that is. I'm guessing that I'm not the only one interested in such a tool.
 
Last edited:
You've already got your work cut out for you! See: https://mitsuduino.blogspot.com/2013/06/on-board-diagnostic-between-mitsubishi.html There are four posts there worth going through.
Seems like it. I get that people who've put in a lot of work on such things and/or are doing it for commercial reasons don't want to share certain information that took them some doing to obtain. I just wish they'd just say so instead of remaining silent. Plus, the more basic stuff I asked about isn't proprietary, like, literally what kind of connector the diagnostic port uses. And, it's an over 30 year old platform and most things should be open source by now. But, if people are doing the "I paid my dues and so should you" thing, so be it. It's not THAT important to me.
 
Thanks. At this point I just need to find an OBD1 connector to plug into the OBD1 port in my Talon, preferably pre-wired. Do you know of any US-based sources? I'd rather not buy such a small part from Japan, with the shipping costs.

Although for only reading OBD1 codes I could probably jerry-rig my own connector since it only needs 2 pins IIRC and I have a number of standard connector types I could use to connect it to any code reader I built. Reading ECU codes is pretty far down my list of to-do's at this point, though.
 
Thanks. Your links are very helpful.
 
I mean, unless you're just doing it for the challenge, you're reinventing the wheel.

As @Jane Hacker alluded to, MMCD does what you want (and more) and it's free if you have the hardware to make it run (a Palm/computer of some sort and a cable): http://explodingcoder.com/blog/content/mmcd-datalogger-project

There's also TunerPro, which is extremely capable: https://www.google.com/url?sa=t&sou...IoAHoECBEQAQ&usg=AOvVaw1LR-fe1L2CEGYnl9fDpGO6

You'll spend a shitload less time and money if you use one of the cheaper solutions out there, and it will be arguably much more capable than what you're talking about building. Again, not knocking you, just stating the facts.

Most people use the expensive off the shelf tuning/logging solutions because they don't have the knowledge to mess with bin files and dick with code. But, it sounds like with your skills that won't be an issue. If I were you I'd look into TunerPro.

Regarding the plug, just Google for Mitsubishi OBD1 connector. You can retrofit basically anything you find. Also, there's an in-depth how-to on making a logging cable in the TunerPro link I posted above. If the parts listed can still be found, that would serve as a good guide to construct your own cable.

Yo, your page is awesome. A lot of great material hiding in there. Thanks for sharing!
 
I mean, unless you're just doing it for the challenge, you're reinventing the wheel.

MMCD does what you want (and more) and it's free if you have the hardware to make it run (a Palm/computer of some sort and a cable): http://explodingcoder.com/blog/content/mmcd-datalogger-project

There's also TunerPro, which is extremely capable: https://www.google.com/url?sa=t&sou...IoAHoECBEQAQ&usg=AOvVaw1LR-fe1L2CEGYnl9fDpGO6

You'll spend a shitload less time and money if you use one of the cheaper solutions out there, and it will be arguably much more capable than what you're talking about building. Again, not knocking you, just stating the facts.

Most people use the expensive off the shelf tuning/logging solutions because they don't have the knowledge to mess with bin files and dick with code. But, it sounds like with your skills that won't be an issue. If I were you I'd look into TunerPro.

Regarding the plug, just Google for Mitsubishi OBD1 connector. You can retrofit basically anything you find. Also, there's an in-depth how-to on making a logging cable in the TunerPro link I posted above. If the parts listed can still be found, that would serve as a good guide to construct your own cable.
Thanks. The initial version would be just to reads OBD1 codes and would be pretty simple to build and code. I could probably do it in an day, and most of that would be spent come back up to speed on how to do it.

It's just a matter of figuring out the duty cycle (which is known) and then reading the determining if a pulse is short or long, and translating it into a 2 digit number and displaying it on a 2-digit LED display.

I already have all the parts I'd need, except for the connector. It would run off of either the car battery or a 9V. Really simply stuff and while, yes, I see it as a fun challenge, it's not really that big a deal.

A proper ECU reader, though, is a whole other matter. I'm sure I could do that too, but if it's already been done that why bother, other than building the circuit board that connects to the laptop, tablet or phone.

But no point in rewriting the software if it already exists and can be installed on any of today's most common OS platforms, namely MacOS, iOS, Android, Windows or Linux.

Do you know what the above two apps run on? I actually still have my old Palm Pilot and cradle, a bunch of serial cables, and even a tiny keyboard. But I'd just as soon use a tablet or phone, preferably with a Blutooth link, and Android as that's what I have. Do either of these support that?

But for now I just want to build a basic code reader. I'll look into connectors.
 
Do you know what the above two apps run on? I actually still have my old Palm Pilot and cradle, a bunch of serial cables, and even a tiny keyboard. But I'd just as soon use a tablet or phone, preferably with a Blutooth link, and Android as that's what I have. Do either of these support that?
I've personally ran MMCD on a palm IIIc hooked directly to the OBD1 port via a cable. You can also use a USB serial adapter, although getting the right combination of software to get it all to work at this point in time may be a chore. I know it can be done with a computer as well using a serial/usb adapter, but you'd likely be looking as using an emulator and VM running a legacy OS to get that shit to work (or at least, that's the route I'd go).

IIRC, I used an old logger cable hooked to my laptop to get TunerPro to work. I mainly just used it for some limited data logging and troubleshooting. It was pretty straight forward since the software isn't ancient.

I'm sure you could get either app to work on almost any device. That being said, you'd need to research whatever device/app combo you wanted to use and pair them the right software and drivers. Whatever combo you choose to use will be unique, obviously, which will require a tailored solution to make everything work properly.
 
I've personally ran MMCD on a palm IIIc hooked directly to the OBD1 port via a cable. You can also use a USB serial adapter, although getting the right combination of software to get it all to work at this point in time may be a chore. I know it can be done with a computer as well using a serial/usb adapter, but you'd likely be looking as using an emulator and VM running a legacy OS to get that shit to work (or at least, that's the route I'd go).

IIRC, I used an old logger cable hooked to my laptop to get TunerPro to work. I mainly just used it for some limited data logging and troubleshooting. It was pretty straight forward since the software isn't ancient.

I'm sure you could get either app to work on almost any device. That being said, you'd need to research whatever device/app combo you wanted to use and pair them the right software and drivers. Whatever combo you choose to use will be unique, obviously, which will require a tailored solution to make everything work properly.
It sounds like taking a time machine to 2003 or something. But then DSMs predate that by 15 years, their core technology even more than that. But I'll figure it out, having this all work on something a wee bit more recent than a Palm Pilot. For starters data logging makes so much more sense on a more recent platform where data storage is effectively unlimited, in case I need to capture an extended data stream for diagnostic purposes.

But, again, for now, just OBD1 code reading. Vastly simpler.
 
Last edited:
Seems to me the following goals alone make such a project worth while:
  1. FOSS (free open source software)
    • Let the community mix and remix to their needs
    • Much, much more
  2. Eliminate "adapter hell",
    • native USB (FTDI)
    • Bluetooth
    • *hint* both *hint*
    • etc.
  3. Eliminate "OS lock"
    • use language & frameworks that easily port to any OS
    • no more emulation
A proper ECU reader, though, is a whole other matter.
I suppose you mean sending, receiving, and decoding bytes over serial? Honestly shouldn't be much more difficult than decoding "heartbeat mode". Actually, it *probably* is easier. MEGA 2560 have extra serial ports and you can hook to them, and set whatever baud rate the ECU is using. "Heartbeat mode" you'd have to use timers and keep track of everything... Though honestly it'd be cool to see both. 🤷‍♀️
 
There a several circuits for interfacing to the diagnostic port on a 1G that boil down to active (requiring external power) and passive. The MMCD page describes on such active interface using a MAX232 chip to interface with typical Serial port and a couple of transistors to do the level shifting to match the ECU's unipolar signaling @1952 bps.

There is an example of a passive interface based on one of the schematics I circulated years ago. There is another to account for the differences between DTE and DCE in RS232.


and a interesting hybrid USB based interface using the passive level shifting.


The actual protocol is basic command - response.
Fault codes are bit mapped in memory. The Protocol itself is old and predates the ECU's using MH6111. As such it has typical issues with byte order on 16 bit values.

The DSM ECU uses Motorola big-endian byte order and it looks like the earlier ECUs might have used little-endian byte order.

To meet your first goal you would send command 0x38 to get the high byte of the active faults and command 0x39 to get the low byte. The commands for the stored faults are 0x3B and 0x3C. What you receive back will consist of two bytes, the first an echo of the command (because the serial line is simplex) followed by the one byte response. from the ECU.

The fault bitmap is:
FaultHi
0x80 TDC
0x40 CAS
0x20 ECT
0x10 ISC
0x08 TPS
0x04 IAT
0x02 MAF
0x01 O2

FaultLow
0x80 IGNITION
0x40 COIL
0x20 EGRT
0x10 FP
0x08 INJ
0x04 KS
0x02 BARO
0x01 VSS

Not all of these are used on a DSM.
If you look at the Error Codes returned for these faults you see some of the artifacts mentioned in the general order of the reported codes.

O2 is 11
MAF is 12
IAT is 13
TPS is 14
ISC is 15
ECT is 21
CAS is 22
TDC is 23
VSS is 24
BARO is 25
KS is 31
INJ is 41
FP is 42
EGRT is 43
COIL is 44
IG is 36

I guess I should add that sending 0xCA as a command will clear the fault codes on 91-94 ECUs.
 
Counting pulses from the DLC without actually talking to the ECU should be pretty easy with an Arduino on one of the GPIO pins. The electrical interface could be a simple as a voltage divider to drop the 12v ECU pulses down to your GPIO voltage.

You need to deal with the 4 cases.
Nothing on pin 1 - turned off or dead
Solid 12v on pin 1 - really dead
Heartbeat on pin 1 - fat, dumb, and happy
Fault codes on pin 1 - something's up

You can't really assume you caught the start of a code. You'll need to sync up on the long space that leads up to the first digit or the longer space between repeats of the list of codes.

There are lots of Arduino examples and techniques for reading digital pulses so you should be able to find something you can reuse.

If you plan on moving to datalogging this work would be disposable and working on reading the codes via the DLC protocol would be the route to go.
 
Yeah I'll have to figure out how to read all that reliably. Don't error codes repeat themselves though? That would make this much easier. The final device should be not much bigger than a 9V battery. Plug it in, turn the key, wait a few seconds, get the codes, you're done.

Talking to the ECU would be a whole other thing and I'm not going to take that on for some time. I assume that, done right, it's sorta kinda like OBD1, but with less data because there are fewer sensors than on an OBD2 car. Sort of a OBD1.5? But some sort of BT/WiFi wireless link to the readout/logging device would be nice. I've programmed both using Arduinos, as well as RF24+. BT probably makes the most sense for all sorts of reasons. As for working with machine code, wow, that takes me back. C would have been so much nicer, but alas.
 
As for working with machine code, wow, that takes me back. C would have been so much nicer, but alas.

Unless you're going to be patching the ECU software I don't see where you would be writing any low level software in assembler or hex editing machine code. MMCD is Palm C code, I assume Tuner-Pro was done in Visual something, TMO's Logger was also likely done in Visual Studio way back when, and the client for DSMLink is Java. It really wouldn't matter if you wrote this in Python as most processors aren't going to be working hard to keep up with a less than 2k bps stream.

Go knock it out so you can say you've done it. All the clues are here.
 
I meant reading the ECU code, not overwriting it. That's way above my pay grade and as others have said could destroy the engine. Not even thinking of doing that, strictly one-way communication and data reading/logging.
 
Got ya. There were many brain puzzles involved in first figuring the processor out and then disassembling the code to reverse engineer the source. Still a bit of code in there that isn't well understood. I'm more into forgetting how it works now than unraveling new parts.

There isn't anything much you can change via the DLC interface.
About the worst you can do is turn off an injector or try an saturate the CPU with commands but it's real time code with a watchdog timer so when it's overloaded the key stuff keeps running and the outer loops just don't get run.
 
I bought one of those souped-up ESP32's a few years back but never got around to playing with it. I have though used a regular ESP32 to build a WiFi-enabled weather station on a MEGA32 platform, using it to update a MySQL DB running on a nearby Raspberry Pi 2+. So I'm versed in many of the underlying technologies, just a bit rusty and in need of getting back up to speed. But what I have in mind for the OBD1 scan tool is way way way simpler. Just need to read some codes to help diagnose a high idle issue. Although, a tool that read sensor outputs would be even more helpful. Still, I'd rather ease into this than take on anything too complex right away.

Btw I assume you know that ESP32s are microcontrollers in their own right and don't necessarily need a host microcontroller like the Arduino?
 
Btw I assume you know that ESP32s are microcontrollers in their own right and don't necessarily need a host microcontroller like the Arduino?
Yup, but this is the first time I've looked at them so I have no practice coding for them. Though I know you can still use the Arduino SDK with them. As for your design, a transistor hooked to a digital pin? Then a tight loop polling the level and decode from there, or using an input capture interrupt to track level changes that way?

It should also be noted that I too am a software developer first, and have no formal education with hardware. LOL As such anyone with HW experience able to be reviewers are most welcome. :thumb:
 
It's been a few years but since the OBD1 code pins put out digital signals, either 0V or 5v for 0 or 1, IIRC you just need a pullup or pushdown resistor, or maybe not even that since 5V is an Arduino's native internal voltage (although some can work at 3.3V and many take a 9V power input and reduce it to 5V). So it MIGHT just be a direct connection requiring no additional components other than the connecting wires. As for how to read the inputs, I think you'd just set up a polling loop. Although Arduinos do have interrupts so perhaps that would work too. It's been a few years so I'd have to think about it, but either way it should be pretty simple to put together and code.

I have more of a SW than HW background too, but in college I did take a course in digital electronics, which was really fun actually, and have a little electronics experience. But mostly I taught myself how to do this, and Arduinos are really good platforms for a coder to learn about electronics, both analog and digital. And the ESP32 is basically an Arduino-like microcontroller with onboard WiFi & BT, making it even simpler. For a simple OBD1 scan tool you can get by with just one of the Minis or Nanos, around the size of half a stick of flat gum, mounted on a small blank circuit board using a DIP, a 2 digit LED display, some wiring, and a connector for the cable to the OBD1 port. Not sure if car power would suffice. Most likely it would. Is there a 5V pin on the OBD1 port?
 
Support Vendors who Support the DSM Community
Boosted Fabrication ECM Tuning ExtremePSI Fuel Injector Clinic Innovation Products Jacks Transmissions JNZ Tuning Kiggly Racing Morrison Fabrications MyMitsubishiStore.com RixRacing RockAuto RTM Racing STM Tuned

Latest posts

Build Thread Updates

Vendor Updates

Latest Classifieds

Back
Top