Please see the sections below, I can provide diagnostic applications and cables for the MEMS 2J ECU, as well as ECU modification to allow remapping
This cable suits all cars with the MEMS 2J ECU
I am now selling these directly from the website, secure payment taken via stripe.com
I post using Royal Mail with tracking, I will send you the tracking link once the postage has been arranged.
The most up to date application is here for Windows/Linux
Web/agent application
This is also a web based application that works in Windows/Max/Linux computers or laptops
Web application
If you need a Windows driver for a 16-pin FTDI based cable then you can download it here:
FTDI driver
The Android app works with MEMS 2J ECUs while using an appropriate cable.
The cables are full size USB so you will likely need to buy an "OTG" adaptor that fits between your device and the USB cable.
Android app in the Google Play store
PLCC-44 Socket
Modified 2J ECU with additional board to allow OBD remapping
Use this to work out MAP sensor scaling values needed when fitting a different MAP sensor to an ECU.
This could be used to allow the stock ECU to work on a boosted (turbo/supercharged) engine.
The ECU circuitry on the input pin causes a voltage drop, this is accounted for by the multiplier setting.
The voltage drop multiplier is set for MPI Mini (2J) ECUs by default.
MEMS 2J Mini MPI: 0.896
MEMS 3: 0.833
TD5: 0.907
ECU sensor voltage drop multiplier:
Known kPa values vs voltage:
kPa at 0v:
kPa at 5v:
Values for ECU maps:
Multiply:
Divide:
Add (offset):
Known ECU map values:
Multiply:
Divide:
Add (offset):
kPa at voltage:
kPa at 0v:
kPa at 5v:
In case you are a programmer or would like more info about communication with the ECUs for diagnostics, here it is
5-baud wake up or fast-init (25ms break followed by 25ms non-break)
Only some cables allow breaks to be used properly - FTDI chips always work
Then use 10400 Baud rate, 8 bits, 1 stop bit, NO parity
K-line communication over a single wire
You literally get your own transmissions as echos because it is K-line
Uses KWP-2000
Normal packets structure is - [format] [dest] [source] [length of data bytes] [data bytes ...] [checksum]
The checksum is a SUM of all data bytes and the length byte, then cropped to 1 byte in case it has spilled over 255 (AND it with 0xFF)
After doing fast or slow init, send bytes to the ECU: 0x81, 0x13, 0xF7, 0x81, 0x0C - this is a one-off packet just to init/get in, no length byte sent
ECU should reply 0x03, 0xC1, 0xD5, 0x8F, 0x28 - again this is a one-off packet
After that it is just KWP2000