Adding ALDL scanner support to MPGuino

[toc]

Ahh, but I was, in my loops, I was checking 30000 times for serial.available, and where there was, it was reading the data and sending that out (hence there was none).

I plan to test this circuit, I think:
http://mmcdlogger.sourceforge.net/ecu-rs232.jpg

So, make it RS232, and then take that to either TTL for arduino, or keep it RS232 and get the Laptop listening for data.

I couldn't get it working with just the wires direct to the arduino and those different baud rates - using this cable, I suspect request / response is needed, if no data stream is found.

If so, no problem, the code can adapt to that.

[meelis11]

Here is MMCD opensource code
Unofficial MMCd Project Site

Maybe it is possible to use its logic and some code to make that data to some useful values in MPGuino.

I am also interested because I have Mitsubishi Eclipse with 4G63 engine - I have succesfully made data cable (simpler version - only some resistors and diode, no MAX chip)

cable schematic (used laptop to ECU schematic)
Make a datalogger cable | Galant VR-4 > How To and Info Archive | GalantVR-4.org Mitsubishi Galant VR4 Forum

I did manage to get data on laptop, using TMO Datalogger.
http://enos.itcollege.ee/~jylenomm/T...0tmologger.zip


Meelis

[dcb]

These are some goold aldl technical links. I think it isn't "standard" uart so the port cannot read it right.
Reading GM's 160 baud ALDL Data Stream with a Standard PC Serial Port
ALDL

I like the idea of using an interrupt, would suggest doing like the guino injector interrupt handling:

int 0 and 1 tied to the input signal just like guino, except maybe with 10k resistor

int 0 is falling interrupt, notes time since last falling interrupt and last rising interrupt, resets timer counter, send the bit out the uart port as a 0 or 1 (or stage the bits to be packed/sent in the main loop)
if the signal was mostly hi, then that indicates a 0, else a 1, baud independant implementation.

int 1 is rising interrupt, notes current timer counter.



hook it up to a laptop and decypher the bitstream in something easier like java for proto-prototype on a laptop

[toc]

I've put together a circuit I believe works.

The baud rate is proving difficult though, I have proven 160-baud is not correct, 8192 baud is incorrect as well.
But, 1920 and 1953 both give replies.

I've been testing with RPM today, and can get varied results from both 1920-baud and 1953-baud, the data seems mostly correct when using both of the baud rates (as I'm taking the byte returned and reading it's hex value and then taking that to read out RPM).

I'm going to need to find something a bit more reliable to measure, something, that perhaps is more accurately measured, to see which of the above two baud rates are correct. Admittedly they are very similar, so the data could be identical at both 1953 baud and 1920 baud.

The list here is where I've tried RPM and battery voltage - http://mmcdlogger.sourceforge.net/#Protocol

I'm looking for something I can test using the readings via the ALDL interface, and, independently - RPM is too hard to gauge accuracy - I had 2125 and 2180 - something that is hard to read on the RPM gauge. On the other hand, both of those numbers could have been perfectly correct, even at the different baud rates. I'd like to test and confirm it. Any ideas?

[toc]

I'm now trying to figure out why this is happening:

RPM: Resultat 0: 39Dat 1: 1A1A|RPM Val: 812
RPM: Resultat 0: 39Dat 1: 1A1A|RPM Val: 812

Less than 5 seconds later:

RPM: Resultat 0: B9Dat 1: DBDB|RPM Val: 6843
RPM: Resultat 0: 39Dat 1: 5B5B|RPM Val: 2843

The both results are taken 50ms apart, I don't see how the car has gone from 6000 RPM to 2000 RPM in a mere 50ms. The similarities in the data are also hard to ignore.

I think it's some sort of interference.

Battery Voltage seems stable, 13 - 14 is the readings I get - they are steady - But I think 12V should be there. Either way, it's not 113, so it is believable.

I guess I could test the far more simpler circuit with the 10k resistor from data to ground, and MAX232 to take it from RS232 to TTL!

Any ideas what is up with RPM?

[dcb]

I'm still stymied by the baud rate selections. It would seem a tricky thing to get right using a serial port. Have you looked at the signal with a scope (or a soundcard scope with a voltage divider on the line in?) Soundcard Scope

Are you getting valid checksums consistently?

[toc]

I'm not doing anything other than read and use the data!

The baud rate is 1920. The code on Source Forge for mmcd shows it as 1920, despite the webpage claiming 1953 - I checked with 1953 anyway.

Perhaps my breadboard, 2 x MAX232 chips, 12 capacitors, resistors, or the chopped cabling is noisy.

Another issue is the arduino might not have finished receiving when i've called Serial.read (tho I do insist on either 2 bytes or 100ms).

So, there's still some elimination room there which I hope to tackle after work tomorrow maybe.

I haven't done anything with any form of oscilloscope.
I've simply got the MAX232 circuit facing the ALDL port, then another MAX232 taking it to TTL levels, then the arduino processing the data, then a USB -> TTL adapter to the serial monitor.

It is almost certainly, the circuit, or the ECU, or the timing of the arduino, affecting the data I am getting, the coincidence in the data (i.e. a "5A" value instead of "1A").

Below is another example too I guess:
RPM: Resultat 0: 39Dat 1: DBDB|RPM Val: 6843
RPM: Resultat 0: 39Dat 1: 1B1B|RPM Val: 843

I can only assume (though cannot explain) that '39' is the HEX of the query I sent (0x21).
DB is bad response, 1B is the correct response.
(The doubling up is actually done in code here, the second DB was my initial output to result, before I decided to push out the DAT value from within the function).
The above is the same 0x21 asked twice.

I did start looking at binary for what DB and 1B are - they appear very similar - which is where I thought electrical noise (a 1 being inadvertantly picked up), or, for example, the full data hadn't been received to make a 1B so DB resulted.. somehow...

The simpler circuit (i.e. remove the MAX232 facing the car, use just diode and resistor), might help - it might not.

Tomorrow...

[dcb]

mkay, made some progress at 160 baud. The code isn't quite ready for 1892 however (never synchs up). Might need to get more specific with the baud rates (or possibly the outbound uart code is piggy or the new arduino timer code is and has to be neutered again).

here is an arduino script that uses an aldl signal tied to pin2 and pin3 and converts it to a byte stream @57600 baud. two bytes per aldl character to preserve the synch character

PHP Code:

//aldl to serial adapter
//converts 9 bit aldl stream to integers over serial port.
extern volatile unsigned long timer0_overflow_count;

volatile byte lastbit=255; //positive is a one, negative is a zero, 0 is already processed
volatile long falllength = 0;
volatile long riselength = 0;

void falling(){ 
  riselength= timer0_overflow_count;
  timer0_overflow_count=0;
  lastbit= falllength>riselength?1:0;
}

void rising(){
  falllength = timer0_overflow_count;
  timer0_overflow_count=0;
}

void setup(){                    // run once, when the sketch starts
  attachInterrupt(0, falling,FALLING );
  attachInterrupt(1, rising,RISING );
  Serial.begin(57600);
}


byte synched = 0;
int onecount=0;
int bf=0;
byte bp=8;

void loop(){
  byte lb=255;
  while (lb == 255){
//    cli();
    lb=lastbit;
//    sei();
  }
//  cli();
  lastbit=255;
//  sei();
  
  if(synched==0){
    if(lb==0){
      if(onecount>=9){
        synched=1;
        Serial.print((char)1);//repeat the synch sequence for the client
        Serial.print((char)255);
      }else
        onecount=0;
    }else
      onecount++;
  }
  
  if(synched==1){//ok, we are synched
    bf=bf|lb << bp;
    bp--;
    if(bp ==255){//we have 9 bits worth, send it over the port
       Serial.print((char)(bf>255?1:0));
       Serial.print((char)(bf));
       bf=0;
       bp=8;
    }   

  }
} 


Here is the arduino test script (I run it on a second arduino and run its pin 13 to the aldluino's pins 2 and 3), ground pin 12 and reset to simulate 8192-ish baud

PHP Code:

//test script for aldluino
#define sigpin 13
#define baudpin 12

/*   from http://www.techedge.com.au/vehicle/aldl160/aldl160b.htm
 T0-T1 = B = 0.5 mSec.
 T1-T3 = C = 4.75 mSec.
 T3-T4 = E = 1.0 mSec.
 T0-T4 = total = 6.25 mSec 
*/
int low0=500;
int high0=5750;
int low1=5250;
int high1=1000;


void setup(){ 
  pinMode(baudpin,INPUT);
  digitalWrite(baudpin,HIGH);
  if(digitalRead(baudpin)==LOW){//set up 8192
    low0=10;
    high0=112;
    low1=103;
    high1=19;
  }
  pinMode(13,OUTPUT);
  cli();
}


void sendch(int ch){//send out the msb 9 'bits'
    for(int p=8;p>=0;p--){
      int b=ch&1<<p;
      digitalWrite(sigpin,LOW);
      long d = b==0?low0:low1;
      delayMicroseconds(d);
      digitalWrite(sigpin,HIGH);
      d = b==0?high0:high1;
      delayMicroseconds(d);
    }  
}




void loop(){
//cycle through sending 511 (synch), then an ascending odd number followed by a descending even
  sendch(511);
  for(int x = 1;x <=255; x+=2){
    sendch(x);
    sendch(255-x);
  }
} 


Here is a bit of java to read the serial data and print it in hex format

PHP Code:

import gnu.io.CommPortIdentifier;
import gnu.io.SerialPort;
import java.io.InputStream;
import java.io.OutputStream;
public class Serial {
    static InputStream input;
    static OutputStream output;
    public static void main(String[] args) throws Exception {
        CommPortIdentifier portId = CommPortIdentifier
            .getPortIdentifier("COM6");
        SerialPort port = (SerialPort) portId.open("serial madness", 4000);
        input = port.getInputStream();
        output = port.getOutputStream();
        port.setSerialPortParams(57600,
                SerialPort.DATABITS_8, SerialPort.STOPBITS_1,
                SerialPort.PARITY_NONE);
        int i=0;
        while (true) {
            i=input.read();
            while(i == -1)
                i=input.read();
            System.out.print(Integer.toHexString(i));
            i=input.read();
            while(i == -1)
                i=input.read();
            System.out.println(Integer.toHexString(i));
        }

    }
} 


Here is a little bit of output from the java program, you can see the synch character 1ff here generated from the test arduino through the aldluino

0f9
06
0fb
04
0fd
02
0ff
00
1ff
01
0fe
03
0fc
05
0fa
07
0f8

Test circuit is trying to simulate this
http://ecomodder.com/forum/showthrea...tml#post196642

[toc]

Ahh, I've got to request the data I think.
I think the 1920 baud is called MUT ?
It certainly doesn't seem to send the data without asking for it.

ALDL in the reference here appears to be not be targetted at DSM types (i.e. Mitsubishi, Hyundai, perhaps Kia).

[dcb]

mkay, 160 and 8192 are very different protocols, just figuring that out now. Do you have any doc/links on 1920?
Can you grab a couple bytes worth of data using a scope?