Wrong RPM about elmduino HOT 16 CLOSED

Just changed it... and it works.

Tested it with rpm and kph.
Both fine.

Thanks for your support.

from elmduino.

Everything looks ok except for two things:

• The first query times out (I don't think this should be an issue, but you could set the timeout inbegin() to be >10 sec or so to see if that fixes this)
• Your vehicle seems to be reporting 0RPM for some reason. If the timeout edit above doesn't fix this, the issue might be with the vehicle itself

from elmduino.

Wait, I see now that the RPM should actually be 0. I will need to investigate a little more. It would be helpful if you could add more debug prints, especially in conditionResponse() within the ELMduino.cpp file

from elmduino.

I put some additional debug code in conditionResponce().

if (numExpectedBytes > numPayChars) {
if (debugMode)
Serial.println(
F("WARNING: Number of expected response bytes is greater than the "
"number of payload chars returned by ELM327 - returning 0"));

return 0;

} else if (numExpectedBytes == numPayChars) {
if (debugMode) {
Serial.print("numExpectedBytes == numPayChars Response: ");
Serial.println(response);**
}
return ((response * scaleFactor) + bias);
}

// If there were more payload bytes returned than we expected, test the first
// and last bytes in the returned payload and see which gives us a higher
// value. Sometimes ELM327's return leading zeros and others return trailing
// zeros. The following approach gives us the best chance at determining where
// the real data is. Note that if the payload returns BOTH leading and
// trailing zeros, this will not give accurate results!

uint64_t leadingResponse = 0;
for (uint8_t i = 0; i < numExpectedBytes; i++) {
uint8_t payloadIndex = PAYLOAD_LEN - numPayChars + i;
uint8_t bitsOffset = 4 * (numExpectedBytes - i - 1);

leadingResponse |= (ctoi(payload[payloadIndex]) << bitsOffset);

}
if (debugMode) {
Serial.print("leading Responce: ");
Serial.println(leadingResponse);
}
uint64_t laggingResponse = 0;
for (uint8_t i = 0; i < numExpectedBytes; i++) {
uint8_t payloadIndex = PAYLOAD_LEN - numExpectedBytes + i;
uint8_t bitsOffset = 4 * (numExpectedBytes - i - 1);

laggingResponse |= (ctoi(payload[payloadIndex]) << bitsOffset);

}
if (debugMode) {
Serial.print("lagging Responce: ");
Serial.println(laggingResponse);
}

if (leadingResponse > laggingResponse)
return ((float)leadingResponse * scaleFactor) + bias;
return ((float)laggingResponse * scaleFactor) + bias;

And here is the result as logfile.
Service: 1
PID: 12
Normal length query detected
Query string: 010C1
Clearing input serial buffer
Sending the following command/query: 010C1
Received char: 4
Received char: 1
Received char: 0
Received char: C
Received char: 2
Received char: 2
Received char: B
Received char: 8
Received char: \r
Received char: \r
Received char: >
Delimiter found.
All chars received: 410C22B8
Expected response header: 410C
Single response detected
64-bit response:
responseByte_0: 184
responseByte_1: 34
responseByte_2: 0
responseByte_3: 0
responseByte_4: 0
responseByte_5: 0
responseByte_6: 0
responseByte_7: 0
leading Responce: 3536
lagging Responce: 3536
RPM (Loop): 884
Service: 1
PID: 12
Normal length query detected
Query string: 010C1
Clearing input serial buffer
Sending the following command/query: 010C1
Received char: 4
Received char: 1
Received char: 0
Received char: C
Received char: 2
Received char: 4
Received char: 2
Received char: 0
Received char: \r
Received char: \r
Received char: >
Delimiter found.
All chars received: 410C2420
Expected response header: 410C
Single response detected
64-bit response:
responseByte_0: 32
responseByte_1: 36
responseByte_2: 0
responseByte_3: 0
responseByte_4: 0
responseByte_5: 0
responseByte_6: 0
responseByte_7: 0
leading Responce: 3536
lagging Responce: 3536
RPM (Loop): 884
Service: 1
PID: 12
Normal length query detected
Query string: 010C1
Clearing input serial buffer
Sending the following command/query: 010C1
Received char: 4
Received char: 1
Received char: 0
Received char: C
Received char: 2
Received char: 3
Received char: 1
Received char: 4
Received char: \r
Received char: \r
Received char: >
Delimiter found.
All chars received: 410C2314
Expected response header: 410C
Single response detected
64-bit response:
responseByte_0: 20
responseByte_1: 35
responseByte_2: 0
responseByte_3: 0
responseByte_4: 0
responseByte_5: 0
responseByte_6: 0
responseByte_7: 0
leading Responce: 3536
lagging Responce: 3536
RPM (Loop): 884

The condition numExpectedBytes == numPayChars isn't valid in this example.
No debug info in the log.
No responce to main loop.

leading Responce is equal to lagging Responce.
responce only if they are not equal.
No responce to main loop

In the LOG is an additional \r.
May that is the reason?

from elmduino.

To see more details, I just extend the debug info.
numExpectedBytes
numPayChars

if (debugMode) {
Serial.print("numExpectedBytes: ");
Serial.println(numExpectedBytes);
Serial.print("numPayChars: ");
Serial.println(numPayChars);
}

if (numExpectedBytes > numPayChars) {
if (debugMode)
Serial.println(
F("WARNING: Number of expected response bytes is greater than the "
"number of payload chars returned by ELM327 - returning 0"));

return 0;

} else if (numExpectedBytes == numPayChars) {
if (debugMode) {
Serial.print("numExpectedBytes == numPayChars Response: ");
Serial.println(response);
}
return ((response * scaleFactor) + bias);
}

LOG:
Service: 1
PID: 12
Normal length query detected
Query string: 010C1
Clearing input serial buffer
Sending the following command/query: 010C1
Received char: 4
Received char: 1
Received char: 0
Received char: C
Received char: 1
Received char: 9
Received char: 7
Received char: C
Received char: \r
Received char: \r
Received char: >
Delimiter found.
All chars received: 410C197C
Expected response header: 410C
Single response detected
64-bit response:
responseByte_0: 124
responseByte_1: 25
responseByte_2: 0
responseByte_3: 0
responseByte_4: 0
responseByte_5: 0
responseByte_6: 0
responseByte_7: 0
numExpectedBytes: 2
numPayChars: 4
leading Responce: 3536
lagging Responce: 3536
RPM (Loop): 884
Service: 1
PID: 12
Normal length query detected
Query string: 010C1
Clearing input serial buffer
Sending the following command/query: 010C1
Received char: 4
Received char: 1
Received char: 0
Received char: C
Received char: 1
Received char: 9
Received char: D
Received char: 8
Received char: \r
Received char: \r
Received char: >
Delimiter found.
All chars received: 410C19D8
Expected response header: 410C
Single response detected
64-bit response:
responseByte_0: 216
responseByte_1: 25
responseByte_2: 0
responseByte_3: 0
responseByte_4: 0
responseByte_5: 0
responseByte_6: 0
responseByte_7: 0
numExpectedBytes: 2
numPayChars: 4
leading Responce: 3536
lagging Responce: 3536
RPM (Loop): 884

Hope it will help.

from elmduino.

Please format your code snippets properly, thanks

from elmduino.

Don't know how to format it.
Will try again.

from elmduino.

float ELM327::conditionResponse(const uint8_t &numExpectedBytes, const float &scaleFactor, const float &bias) {
if (numExpectedBytes > 8)
if (debugMode)
Serial.println(
F("WARNING: Number of expected response bytes is greater than 8 - "
"returning 0"));
return 0;
}
if (debugMode) {
Serial.print("numExpectedBytes: ");
Serial.println(numExpectedBytes);
Serial.print("numPayChars: ");
Serial.println(numPayChars);
}

if (numExpectedBytes > numPayChars) {
if (debugMode)
Serial.println(
F("WARNING: Number of expected response bytes is greater than the "
"number of payload chars returned by ELM327 - returning 0"));
return 0;
} else if (numExpectedBytes == numPayChars) {
if (debugMode) {
Serial.print("numExpectedBytes == numPayChars Response: ");
Serial.println(response);
}
return ((response * scaleFactor) + bias);
}

// If there were more payload bytes returned than we expected, test the first
// and last bytes in the returned payload and see which gives us a higher
// value. Sometimes ELM327's return leading zeros and others return trailing
// zeros. The following approach gives us the best chance at determining where
// the real data is. Note that if the payload returns BOTH leading and
// trailing zeros, this will not give accurate results!

uint64_t leadingResponse = 0;
for (uint8_t i = 0; i < numExpectedBytes; i++) {
uint8_t payloadIndex = PAYLOAD_LEN - numPayChars + i;
uint8_t bitsOffset = 4 * (numExpectedBytes - i - 1);
leadingResponse |= (ctoi(payload[payloadIndex]) << bitsOffset);
}
if (debugMode) {
Serial.print("leading Responce: ");
Serial.println(leadingResponse);
}
uint64_t laggingResponse = 0;
for (uint8_t i = 0; i < numExpectedBytes; i++) {
uint8_t payloadIndex = PAYLOAD_LEN - numExpectedBytes + i;
uint8_t bitsOffset = 4 * (numExpectedBytes - i - 1);
laggingResponse |= (ctoi(payload[payloadIndex]) << bitsOffset);
}
if (debugMode) {
Serial.print("lagging Responce: ");
Serial.println(laggingResponse);
}

if (leadingResponse > laggingResponse)
return ((float)leadingResponse * scaleFactor) + bias;
return ((float)laggingResponse * scaleFactor) + bias;
}

from elmduino.

to format arduino code, just type three back ticks "```c++", then a new line and paste all your code. At the end, put a newline then three more back ticks.

Here's an example, except I replace backticks with another character so github doesn't format it so you can read it!

'''c++
your code here
many lines of c++ code
'''

for your logs
'''log
log output
log output
'''

from elmduino.

Got it.

float ELM327::conditionResponse(const uint8_t &numExpectedBytes,
                                const float &scaleFactor, const float &bias) {
  if (numExpectedBytes > 8) {
    if (debugMode)
      Serial.println(
          F("WARNING: Number of expected response bytes is greater than 8 - "
            "returning 0"));
    return 0;
  }
  if (debugMode) {
    Serial.print("numExpectedBytes: ");
    Serial.println(numExpectedBytes);
    Serial.print("numPayChars: ");
    Serial.println(numPayChars);
  }

  if (numExpectedBytes > numPayChars) {
    if (debugMode)
      Serial.println(
          F("WARNING: Number of expected response bytes is greater than the "
            "number of payload chars returned by ELM327 - returning 0"));
    return 0;
  } else if (numExpectedBytes == numPayChars) {
    if (debugMode) {
      Serial.print("numExpectedBytes == numPayChars Response: ");
      Serial.println(response);
    }
    return ((response * scaleFactor) + bias);
  }

  // If there were more payload bytes returned than we expected, test the first
  // and last bytes in the returned payload and see which gives us a higher
  // value. Sometimes ELM327's return leading zeros and others return trailing
  // zeros. The following approach gives us the best chance at determining where
  // the real data is. Note that if the payload returns BOTH leading and
  // trailing zeros, this will not give accurate results!

  uint64_t leadingResponse = 0;
  for (uint8_t i = 0; i < numExpectedBytes; i++) {
    uint8_t payloadIndex = PAYLOAD_LEN - numPayChars + i;
    uint8_t bitsOffset = 4 * (numExpectedBytes - i - 1);

    leadingResponse |= (ctoi(payload[payloadIndex]) << bitsOffset);
  }
  if (debugMode) {
    Serial.print("leading Responce: ");
    Serial.println(leadingResponse);
  }
  uint64_t laggingResponse = 0;
  for (uint8_t i = 0; i < numExpectedBytes; i++) {
    uint8_t payloadIndex = PAYLOAD_LEN - numExpectedBytes + i;
    uint8_t bitsOffset = 4 * (numExpectedBytes - i - 1);

    laggingResponse |= (ctoi(payload[payloadIndex]) << bitsOffset);
  }
  if (debugMode) {
    Serial.print("lagging Responce: ");
    Serial.println(laggingResponse);
  }

  if (leadingResponse > laggingResponse)
    return ((float)leadingResponse * scaleFactor) + bias;
  return ((float)laggingResponse * scaleFactor) + bias;
}

Service: 1
PID: 12
Normal length query detected
Query string: 010C1
Clearing input serial buffer
Sending the following command/query: 010C1
Received char: 4
Received char: 1
Received char: 0
Received char: C
Received char: 1
Received char: 9
Received char: 7
Received char: C
Received char: \r
Received char: \r
Received char: >
Delimiter found.
All chars received: 410C197C
Expected response header: 410C
Single response detected
64-bit response:
responseByte_0: 124
responseByte_1: 25
responseByte_2: 0
responseByte_3: 0
responseByte_4: 0
responseByte_5: 0
responseByte_6: 0
responseByte_7: 0
numExpectedBytes: 2
numPayChars: 4
leading Responce: 3536
lagging Responce: 3536
RPM (Loop): 884
Service: 1
PID: 12
Normal length query detected
Query string: 010C1
Clearing input serial buffer
Sending the following command/query: 010C1
Received char: 4
Received char: 1
Received char: 0
Received char: C
Received char: 1
Received char: 9
Received char: D
Received char: 8
Received char: \r
Received char: \r
Received char: >
Delimiter found.
All chars received: 410C19D8
Expected response header: 410C
Single response detected
64-bit response:
responseByte_0: 216
responseByte_1: 25
responseByte_2: 0
responseByte_3: 0
responseByte_4: 0
responseByte_5: 0
responseByte_6: 0
responseByte_7: 0
numExpectedBytes: 2
numPayChars: 4
leading Responce: 3536
lagging Responce: 3536
RPM (Loop): 884

from elmduino.

I'll have to look into this a little more, but I think I see your particular issue:

Change:

• if (numExpectedBytes > numPayChars) { to if (numExpectedBytes > (numPayChars / 2)) {
• } else if (numExpectedBytes == numPayChars) { to } else if (numExpectedBytes == (numPayChars / 2)) {

I'm still wondering why the "leading/lagging" part of the code wasn't giving you 0 rpm, but the above updates should cause the else if to evaluate true and skip the "leading/lagging" portion

from elmduino.

@PowerBroker2
Understand than right there ist an Bug ? Why do not change the Code ?

from elmduino.

I'm encountering the same issue and I'm about to test the fix proposed above, but in the mean time, can someone help me understand why the value 884 is reported when this bug manifests? What's going on here? This might be more of a general programming question; I'm just not following what is happening that the same value is being returned regardless of the response from the ECU.

from elmduino.

Each response char from the ELM327 is a nibble since the response format of the ELM327 is in hex. The code tries to test and see if you have more, less, or exactly the expected number of bytes received from the ELM327. However, we need to convert the number of hex nibbles to number of bytes by dividing by two for a valid comparison. This is where the main bug is and the above edits should fix it. There may be another bug causing the 884 issue, but I'll have to investigate more to figure it out.

from elmduino.

I found the issue and fixed it. Try 3.1.0

from elmduino.

Thanks for the explanation and the fix. I will give it a go shortly.

from elmduino.