com.github.pires.obd.exceptions.NonNumericResponseException: Error reading response

[dpnova]

This is on a subaru 2004 outback. I found the protocol by using torque as auto didnt seem to select the right one.

The data I'm getting back looks like hex data (with the OK code at the start).

com.github.pires.obd.exceptions.NonNumericResponseException: Error reading response: :OK84F110410C0C1AF883F1187F01

I'm happy to debug/dev/fix as required, it's just I'm new to OBD so I'm not sure where to start.

Cheers!

[pires]

What command originated this response?

[diegomalone]

I have experienced the same error message in some responses with colon in the middle of the data, and in my case it is a bad OBD2 adapter. In the same vehicle, one adapter reads the hex value and the other the hex value with some colons. If it is just one case that it occours, I suggest to override the performCalculations method and remove all the colons of the response.

[dpnova]

It was Engine RPM I believe. On Jan 2, 2017 9:56 PM, "Paulo Pires" <notifications@github.com> wrote: What command originated this response? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#125 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAOCNx0ggrTocD0SEIJWcRjknnoPLQhXks5rOOXUgaJpZM4LYqaj> .

[dpnova]

aI guess my confusion stems from the fact that there's an assertion about being numeric data. I guess this means I should convert the hex data to something first.

In the case of the above emssage I would do something like

read success: "OK" convert from hex to a long/int/something: "84F110410C0C1AF883F1187F01"

I guess I'm wondering if the hex data is actually fixed width with multiple values or something?

[pires]

Engine RPM is just a single value between 0 and 16,383.75, so 2 bytes.

[pires]

More info https://en.wikipedia.org/wiki/OBD-II_PIDs#Mode_01. Look for RPM.

[dpnova]

Ah great thanks, now I'm starting to join the dots.

…

On Jan 3, 2017 10:19 PM, "Paulo Pires" ***@***.***> wrote: More info https://en.wikipedia.org/wiki/OBD-II_PIDs#Mode_01. Look for *RPM*. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#125 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAOCN6TtjW_aND8PUsKz5DO3jfQiDWVMks5rOjzXgaJpZM4LYqaj> .

[dpnova]

Weird. This was the data I was getting before: BUSINIT:OK84F110410C0C04E283F1187F01

I added something to remove the ":OK" - but now I'm not being send the OK anymore. Strange.

I'm being sent the same data over and over again in response to my engine rpm command though: 84F110410C0C4C2A83F1187F01

This is resulting in the RPM: 1040 - this is incorrect and doesn't change when the rpm changes. I get similar issues with speed, it sits at 16 while the car is stationary.

This is the protocol that toque uses so I'm a little at a loss...

[dpnova]

01-07 15:34:17.527 32248-32248/dpn.carby.carby I/obd1: BUSINIT:OK84F110410C0C1CFA83F1187F01
01-07 15:34:17.528 32248-32248/dpn.carby.carby I/obd2: 84F110410C0C1CFA83F1187F01
01-07 15:34:17.528 32248-32248/dpn.carby.carby D/btutil: RPM: 1040
01-07 15:34:17.722 32248-32248/dpn.carby.carby I/obd1: 84F110410C0C230183F1187F01
01-07 15:34:17.723 32248-32248/dpn.carby.carby I/obd2: 84F110410C0C230183F1187F01
01-07 15:34:17.723 32248-32248/dpn.carby.carby D/btutil: RPM: 1040
01-07 15:34:17.920 32248-32248/dpn.carby.carby I/obd1: 84F110410C0C17F583F1187F01
01-07 15:34:17.928 32248-32248/dpn.carby.carby I/obd2: 84F110410C0C17F583F1187F01

With this diff:

--- a/src/main/java/com/github/pires/obd/commands/ObdCommand.java
+++ b/Users/dpn/AndroidStudioProjects/Carby/app/src/main/java/com/github/pires/obd/commands/ObdCommand.java
@@ -12,6 +12,8 @@
  */
 package com.github.pires.obd.commands;

+import android.util.Log;
+
 import com.github.pires.obd.exceptions.*;

 import java.io.IOException;
@@ -153,6 +155,7 @@ public abstract class ObdCommand {
     private static Pattern WHITESPACE_PATTERN = Pattern.compile("\\s");
     private static Pattern BUSINIT_PATTERN = Pattern.compile("(BUS INIT)|(BUSINIT)|(\\.)");
     private static Pattern SEARCHING_PATTERN = Pattern.compile("SEARCHING");
+    private static Pattern OK_PATTERN = Pattern.compile(":OK");
     private static Pattern DIGITS_LETTERS_PATTERN = Pattern.compile("([0-9A-F])+");

     protected String replaceAll(Pattern pattern, String input, String replacement) {
@@ -167,8 +170,11 @@ public abstract class ObdCommand {
      * <p>fillBuffer.</p>
      */
     protected void fillBuffer() {
+        Log.i("obd1", rawData);
         rawData = removeAll(WHITESPACE_PATTERN, rawData); //removes all [ \t\n\x0B\f\r]
         rawData = removeAll(BUSINIT_PATTERN, rawData);
+        rawData = removeAll(OK_PATTERN, rawData);
+        Log.i("obd2", rawData);

[dpnova]

--- a/src/main/java/com/github/pires/obd/commands/engine/RPMCommand.java
+++ b/Users/dpn/AndroidStudioProjects/Carby/app/src/main/java/com/github/pires/obd/commands/engine/RPMCommand.java
@@ -12,6 +12,8 @@
  */
 package com.github.pires.obd.commands.engine;

+import android.util.Log;
+
 import com.github.pires.obd.commands.ObdCommand;
 import com.github.pires.obd.enums.AvailableCommandNames;

@@ -43,6 +45,7 @@ public class RPMCommand extends ObdCommand {
     @Override
     protected void performCalculations() {
         // ignore first two bytes [41 0C] of the response((A*256)+B)/4
+        Log.i("perform", Integer.toString((buffer.get(5) * 256 + buffer.get(6)) / 4));
         rpm = (buffer.get(2) * 256 + buffer.get(3)) / 4;
     }

With this diff I can log the correct engine RPM commands.

This raises the question, what are the first 5 bytes for in this case? Have I missed something here or is subaru just being weird?

[dpnova]

I think my approach will be to create a patch that allows setting a byte offset either statically on the parent ObdCommand or allow it to be passed into the ctor. Maybe both. Thoughts?

[pires]

Moving things around seems like a workaround and not a proper fix. I haven't been involved with OBD for a while now, so I can't say for sure but this seems like a protocol issue.

[dpnova]

I fond that stripping the preceding byte pattern fixes the issue mostly (still figuring out some things like VIN etc though)

I'm happy to contribute back to the lib, I'll sort tests etc first.