Adding ALDL scanner support to MPGuino

[toc]

Just a quick update:
I used the far more simplified circuit, noted here:
Make a datalogger cable | Galant VR-4 > How To and Info Archive | GalantVR-4.org Mitsubishi Galant VR4 Forum

The Laptop version is what I used, not the palm version.

Then, took the RS232 and converted to TTL using the MAX232 (refer to the datasheet, it's very easy).

Then, connected to the arduino, then used the information on MMCD's page (1920 baud, 0x21 for RPM).

RPM values were very consistent and correct.

This tells me that for DSM / Mitsubishi 4G63 / Hyundai G4CP engines, that ALDL works correctly when the circuit for the interface is done correctly.

I can now proceed and take the request / responses and try and push that into the MPGuino code.

I'm waiting on an LCD display to start putting it together, but will start hacking out the code soon.

I can't get reliable readings from speed though!
I queried speed using the value noted online in a few places, and seemingly used by Evoscan (another Mitsubishi data logging / tune up tool).

The responses for speed varied wildly, see below:

Speed: Result: Dat 0: 2FDat 1: 00|Speed: 0
Speed: Result: Dat 0: 2FDat 1: 7777|Speed: 238
Speed: Result: Dat 0: 2FDat 1: D6D6|Speed: 428
Speed: Result: Dat 0: 2FDat 1: 9F9F|Speed: 318
Speed: Result: Dat 0: 2FDat 1: 2B2B|Speed: 86
Speed: Result: Dat 0: 2FDat 1: 7C7C|Speed: 248
Speed: Result: Dat 0: 2FDat 1: DDDD|Speed: 442
Speed: Result: Dat 0: 2FDat 1: ADAD|Speed: 346
Speed: Result: Dat 0: 2FDat 1: CCCC|Speed: 408
Speed: Result: Dat 0: 2FDat 1: 3333|Speed: 102
Speed: Result: Dat 0: 2FDat 1: 1313|Speed: 38
Speed: Result: Dat 0: 2FDat 1: 3232|Speed: 100
Speed: Result: Dat 0: 2FDat 1: CECE|Speed: 412
Speed: Result: Dat 0: 2FDat 1: C8C8|Speed: 400
Speed: Result: Dat 0: 2FDat 1: E6E6|Speed: 460
Speed: Result: Dat 0: 2FDat 1: A8A8|Speed: 336
Speed: Result: Dat 0: 2FDat 1: C3C3|Speed: 390
Speed: Result: Dat 0: 2FDat 1: 2C2C|Speed: 88
Speed: Result: Dat 0: 2FDat 1: 3737|Speed: 110
Speed: Result: Dat 0: 2FDat 1: 5A5A|Speed: 180
Speed: Result: Dat 0: 2FDat 1: 2929|Speed: 82
Speed: Result: Dat 0: 2FDat 1: 2D2D|Speed: 90
Speed: Result: Dat 0: 2FDat 1: 3636|Speed: 108
Speed: Result: Dat 0: 2FDat 1: 3C3C|Speed: 120
Speed: Result: Dat 0: 2FDat 1: 6C6C|Speed: 216
Speed: Result: Dat 0: 2FDat 1: 1E1E|Speed: 60
Speed: Result: Dat 0: 2FDat 1: 7C7C|Speed: 248
Speed: Result: Dat 0: 2FDat 1: 2222|Speed: 68
Speed: Result: Dat 0: 2FDat 1: 1111|Speed: 34
Speed: Result: Dat 0: 2FDat 1: 4B4B|Speed: 150
Speed: Result: Dat 0: 2FDat 1: 8989|Speed: 274
Speed: Result: Dat 0: 2FDat 1: 8686|Speed: 268
Speed: Result: Dat 0: 2FDat 1: 44|Speed: 8
Speed: Result: Dat 0: 2FDat 1: 1B1B|Speed: 54
Speed: Result: Dat 0: 2FDat 1: 66|Speed: 12
Speed: Result: Dat 0: 2FDat 1: 2424|Speed: 72
Speed: Result: Dat 0: 2FDat 1: BABA|Speed: 372
Speed: Result: Dat 0: 2FDat 1: 33|Speed: 6
Speed: Result: Dat 0: 2FDat 1: DEDE|Speed: 444
Speed: Result: Dat 0: 2FDat 1: 8686|Speed: 268
Speed: Result: Dat 0: 2FDat 1: E0E0|Speed: 448
Speed: Result: Dat 0: 2FDat 1: 88|Speed: 16
Speed: Result: Dat 0: 2FDat 1: B1B1|Speed: 354
Speed: Result: Dat 0: 2FDat 1: 2B2B|Speed: 86
Speed: Result: Dat 0: 2FDat 1: 2828|Speed: 80
Speed: Result: Dat 0: 2FDat 1: 9090|Speed: 288
Speed: Result: Dat 0: 2FDat 1: F3F3|Speed: 486
Speed: Result: Dat 0: 2FDat 1: DD|Speed: 26
Speed: Result: Dat 0: 2FDat 1: 2B2B|Speed: 86
Speed: Result: Dat 0: 2FDat 1: EDED|Speed: 474
Speed: Result: Dat 0: 2FDat 1: 5454|Speed: 168
Speed: Result: Dat 0: 2FDat 1: C3C3|Speed: 390
Speed: Result: Dat 0: 2FDat 1: 3C3C|Speed: 120
Speed: Result: Dat 0: 2FDat 1: E0E0|Speed: 448
Speed: Result: Dat 0: 2FDat 1: 6767|Speed: 206
Speed: Result: Dat 0: 2FDat 1: 9F9F|Speed: 318
Speed: Result: Dat 0: 2FDat 1: B4B4|Speed: 360
Speed: Result: Dat 0: 2FDat 1: D6D6|Speed: 428
Speed: Result: Dat 0: 2FDat 1: 1F1F|Speed: 62
Speed: Result: Dat 0: 2FDat 1: 3D3D|Speed: 122
Speed: Result: Dat 0: 2FDat 1: F9F9|Speed: 498
Speed: Result: Dat 0: 2FDat 1: 1E1E|Speed: 60

- My little car couldn't ever achieve speeds of 498km/hr, and if it did, I certainly wasn't being an eco driver - maybe the calculation is wrong.

This gives me solid confirmation that the circuit works tho, this is great.
If it wasn't the circuit that fixed it, it would have been the 10ms delay after the data was requested.

[toc]

There is another random thought here that ought to be tested prior to implementation, that is timing.

Current MPGuino code relies on direct reading of the Injectors and VSS - this is all fine and dandy, does what the ECU does.

When you are using a diagnostic setup, such as ALDL, OBD-II, or the Mitsubishi request / response protocol, the timing of the VSS pulses for example, are just not there (at least I don't think so.. hmm.. maybe that is what my Speed reading above is?) - back to where I was going - when MPGuino is getting the data directly, it has no issue - the current fuel consumption data is being provided to it for it to calculate and display.

When it has to take steps to ask for this information, the delay added would affect the accuracy of the data.

I think of it like this (I'm yet to test, but keen to see what comments appear (i.e. dcb - looking at you!), if the data is requested, and then you open wide throttle, the next update could be many ms away, so use of the MPGuino might ot be suitable for that purpose?

I will try and get some testing done tomorrow to find how long each request roughly takes (I'll remove the 10ms delay and make the code very efficient), and see how many responses to my requests are possible - this would all be without any calculation workload - which would delay updates further.

Are the delays going to be a problem at all??

The data stream for other cars (i.e. 160-baud and 8192-baud appears to be a stream from posts, so even this is delayed by the ECU's choice of when to send the data and in what order).

Am I wrong?

[dcb]

Originally Posted by toc

...
Are the delays going to be a problem at all??
...

It will have an affect on accuracy as the resolution isn't great. Obd II solutions have the same issues, accuracy is limited by how many readings per second you can extract from the cpu (baud/packet size). Over time it should sorta average out, though not entirely, as driving style can affect the readings a bit. I don't have a swag though. But you have "easy" access to other sensors and such.

[FalconFour]

Holy crap, so uhm, apparently I don't have a subscription to this thread for some reason. Hence why I've been MIA here... didn't even know the idea was still active! Wait, yes I do, why haven't I been getting 'em? Ugh. Weird.

Excuse me while I catch up... :P

edit: Hmm, wow, a lot of progress made here, it seems. However, I'm getting a little bit of "protocol error" here myself, in a literary sense. I haven't yet seen anyone share what type of OBD system they're using to test these different baud rates. Even different variations of OBD use different baud rates and different protocols, or not even OBD at all (proprietary diagnostic connectors used in import cars, far as I understand). For example, here is the OBD/ALDL connector on my car:

(10k resistor between "ground" and "diagnostic" = getting 160 baud data on "data"; shorting "ground" and "diagnostic" = flashing error codes using SES light, engine running in timing mode)

Anyone got pictures of their connectors? Or think this is relevant? I just don't think we'll get very far with one guy testing the other guy's code on totally different systems...

[toc]

Ahh, that is why you adapt.

OBDuino for example allows for the ISO and CAN type setup.

My setup will be MUT so it's a fair bit of rewriting and reworking but it's doable - I've got things myside down pretty clear now with exception of speed measurements which must be averaged to be usable - but I have a different calculation I will try there.

If I had things easier, I would have just gone straight to the injector cable - but I want to use the diagnostics instead for different measurements.

It works, you do however need the knowledge to adapt it to differing cars (perhaps, differing variations could all be merged, but the code would expand too much - it wouldn't fit on an Arduino).

e.g I could take OBDuino and add support for MUT to it, but the end result would be fat and full of code not being used.

[toc]

I've tried again to use "Pin 11" of the ALDL connector to form some sort of speed input on it.

On the arduino I have been using this:

#include <LiquidCrystal.h>

int pinTachoInHz = 2; // D2 for Tacho Input - Measuring the Hz
long TachoInHz = 0; // declare this as a byte if the count is always less than 255
// so you don't have to disable interrupts when using in loop
long intTachoInHz_Millis = 0;
long prevTacho;
long readingMillis = 0;
long prevMillis;
float vssPulsesPerKM = 4750.0;

LiquidCrystal lcd(12, 11, 7, 6, 5, 4);

void setup() {
// Configure serial output
//Serial.begin(9600);

//Configure pin modes

lcd.begin(20, 4);

pinMode(pinTachoInHz, INPUT);
digitalWrite(pinTachoInHz, HIGH); // Turn on pullup resistor
attachInterrupt(0, count, RISING); // call count when pin 2 goes high

}

void loop(){
analogWrite(3, 55);
analogWrite(8, 200);
float curSpeed = 0;
long tachDiff = 0;
float dataMillis = 0;
lcd.setCursor(0, 0);
lcd.print("Sensor: ");
long tachoCount = TachoInHz; // get a snapshot of the count
readingMillis = millis();
dataMillis = readingMillis-prevMillis;
tachDiff = tachoCount-prevTacho;
float dataTacho = (tachDiff / dataMillis) * 1000;
lcd.print(tachoCount);
lcd.setCursor(0, 1);
lcd.print("Speed: ");
curSpeed = (dataTacho * 60) / vssPulsesPerKM;
lcd.print(curSpeed);
lcd.print("KM/hr");
prevTacho = tachoCount;
prevMillis = readingMillis;
lcd.setCursor(0, 2);
lcd.print("ODO: ");
float odo = tachoCount / vssPulsesPerKM;
lcd.print(odo);
lcd.print("KM");
lcd.setCursor(0, 3);
lcd.print(dataTacho);
lcd.print(" ");
lcd.print(dataTacho / vssPulsesPerKM);
delay(300);
lcd.clear();
// count the ms between each update, divide by the total ms (i.e. ms2 - ms1)
// Then, times 1000 to get pulses per second.
// divide by 4750
//times by 3600 and viola that should be very close.

// Else, look into Timer2 as another option.
}

// this needs to be fixed up!

void count(){
TachoInHz++;
}

Unfortunately, I'm still seeing inaccurate results.

I had another thought of using PulseIn to time the lengths of the pulses, this might give me something proportional to speed to work with.

Pin 11 of the ALDL connector is apparently, an output of vehicle speed (so the speedo cable goes to the ECU, the ECU puts out a 5V signal proportionate to the speed - and this should get faster as the vehicle is faster is my understanding).

Is there a better way to read that signal with minimal errors?

As you can see, 4750 is what I believe the number of pulses in a km are - but even that could be wrong if there are pulses missing for example - I know something is wrong, as the odo count is out - I drove 2KM according to the car ODO, this did not replicate to the odo count.

[oldskool]

Hi Toc,

I'm Rizal and I'm from Malaysia. I'm so interested about your project on communication between arduino and Mitsubishi ecu. I have read your post from beginning but until now i still can not connect to my 4g91 ecu.

For your information, i have successfully connect to my ecu using Plam (MMCd)

Can you help me how are you doing this. Maybe some electrical circuit and arduino source code may help.

[toc]

I ended up building something similar to this circuit to get communicating:
http://mmcdlogger.sourceforge.net/ecu-rs232.jpg

Then in Arduino, the program was similar to:
Serial.begin(1920);

With these:
wireless.print("Battery: Result:");
temp_val = fetch_data(0x14);
temp_real_val = temp_val * 0.0733;
wireless.print(temp_val, HEX);
wireless.print("|Bat Val: ");
wireless.println(temp_real_val);

wireless.println("Testing at 1920bps");
wireless.print("RPM: Result:");
temp_val = fetch_data(0x21);
temp_real_val = temp_val * 31.25;

The fetch data function:


int fetch_data(byte cmd) {
int dat[3];
int temp;
int i;
Serial.write(cmd);
starttime = millis();
while ((Serial.available()<2) && ( (millis() - starttime) < MAX_WAIT_TIME) ) {
//do nothing
}
if (Serial.available()<2) {
wireless.print("Error - 2 Bytes not found - We did get:");
wireless.println(Serial.read(), HEX);
Serial.flush();
} else {
i = 0;
delay(10);
while (Serial.available() > 0) {

temp = Serial.read();
wireless.print("Dat ");
wireless.print(i);
wireless.print(": ");
wireless.print(temp, HEX);
dat[i] = temp;
i++;
//dat[0] should be the cmd we sent
//dat[1] should be the result of the cmd.
}
Serial.flush();
return dat[1];
}

}


You can find a full list here;
MUT Requests - EvoEcu

I never did finish testing for adequate programming though I do know I was receiving correct data for RPMs and Battery Voltage and some other parameters - but I ended up selling the Hyundai so never finished it off.

Now I'm trying to do it with a Nissan (Damned lack of OBDII support!!!)

[oldskool]

Hi.. Toc,

Thanks a lot for sharing the source code... really appreciate it.. I will run the source code and give the feedback once it can connect.

[oldskool]

Dear Toc,

I have tried your source code and get so many incorrect response from the ecu. May i know what is the value for MAX_WAIT_TIME

Thanks