Troubles reading OBD-data

[ludvigiternio]

Hi!

I have modified the software to handle different PIDs for use in vehicles with custom OBD. Inputting the given commands works for reading data from the emulator, but whenever I read from the car I only recieve "NO DATA" on the buffer. Using a different device works, so I know that the commands are correct and that the port in the car is not broken. This is the code for initializing:

Code: Select all

bool COBD::init(std::vector<std::string> init_commands) {
  delay(1000);
  char buffer[64];
  bool success = false;

  // Serial.printf("STARTING INITIALIZATION\n");

  for (auto c : init_commands) {
    c.append("\r");
    Serial.printf("cmd: %s\n", c.c_str());
    link->sendCommand(c.c_str(), buffer, sizeof(buffer), OBD_TIMEOUT_SHORT);
    Serial.printf("Answer to cmd: %s\nis buffer: \n %s\n", c.c_str(), buffer);
  }

  return success;
}

Giving me this print:

Code: Select all

cmd: ATZ
Answer to cmd: ATZ
is buffer: 
>ELM327 v1.5
cmd: ATE0
Answer to cmd: ATE0
is buffer: 
>OK
cmd: ATAL
Answer to cmd: ATAL
is buffer: 
>?
cmd: ATCP18
Answer to cmd: ATCP18
is buffer: 
>ERROR
cmd: ATFCSD300000
Answer to cmd: ATFCSD300000
is buffer: 
>?
cmd: ATFCSM1
Answer to cmd: ATFCSM1
is buffer: 
>?
cmd: ATSP6
Answer to cmd: ATSP6
is buffer: 
>OK
cmd: ATSH7E4
Answer to cmd: ATSH7E4
is buffer: 
>OK
cmd: ATCRA7EC
Answer to cmd: ATCRA7EC
is buffer: 
>?
cmd: ATFCSH7E4
Answer to cmd: ATFCSH7E4
is buffer: 
>?
cmd: 10C0
Answer to cmd: 10C0
is buffer: 
>NO DATA

We have previously tested that it is sufficient to use commands ATZ and ATSP6 for valid responses with another device.

For data collection, this is the code:

Code: Select all

  for (auto pid_string : pids) {
    auto pid = std::stol(pid_string, 0, 16);
    char buffer[64]{};
    char buffertest[64]{};
    char* data = 0; //
    sprintf(buffer, "%04X\r", pid);
    link->send(buffer);
    idleTasks();
    int ret = link->receive(buffer, sizeof(buffer), OBD_TIMEOUT_SHORT);
    Serial.printf("PID: %s, ", pid_string.c_str());
    Serial.printf("Buffer:\n%s\n", buffer);
  }

giving this output:

Code: Select all

PID: 222003, Buffer:
>O DATA
PID: 222004, Buffer:
>O DATA
PID: 223042, Buffer:
>O DATA
PID: 222002, Buffer:
>O DATA
PID: 229003, Buffer:
>O DATA

I am currently at a bit of a loss here, so any help understanding why this doesn't work would be appreciated. As previously mentioned, everything works on the emulator.

[extremerotary]

From my experience, not all of the ELM327 AT commands were implemented in the firmware that was flashed to the chip. This is why you're getting some question marks back. I've had the same issue myself.
From the looks of it, you just want to set a header so you can request manufacturer-specific data. I have also modified the library to accomplish this. For example, in the readPID function, you'll note that it was previously hardcoded to search for "41" and when found, process the response. Well, it's actually the dataMode + 0x40 (where dataMode is 99% of the time going to be 1), so if you're checking custom PIDs and setting dataMode to, say 9, then the "success" indication in the response will actually be "49" instead of "41". Hopefully you have gone through all of those required modifications to request/read data from custom PIDs. All of that said, my suggestion would be to reduce your initialization commands. I would do:
ATZ //reset
ATE0 //echo off
ATH1 //enable headers
ATSH7E4 // set header to 7E4

Leave the protocols and stuff alone; let them be "auto". Then do readPID(0x10C0, value). You can verify communication with the vehicle after you've initialized the chip and sent it the AT commands by testing a standard PID first. Just set the dataMode back to 1 and then readPID(PID_RPM, value).

Hope that helps!

[ludvigiternio]

Thank you for the reply!

Interesting about the AT commands, I'll stick to the basic ones in the future.

As you noted I had to modify the code in order to handle custom PIDs, but I'm not even getting to that stage since I receive "NO DATA" on the buffer.

I am not sure I understand how much freedom manufacturers have regarding PIDs, will they always give a response on 0x10C0? My impression was that they could pick and choose what PIDs they used. Is there a list of standard PIDs that also need to be implemented?