PowerBroker2/ELMduino

Response not detected

Closed this issue · 28 comments

reflexsa commented

Thanks again for the library.
I seem to have some connectivity between my ELM327 and my Wemos D1 R32. However on the rpm example I receive "Response not detected", followed by 'WARNING: Number of payload chars is less than the number of expected response chars returned by ELM327 - returning 0"

It looks like some of the AT queries function but I'm not sure if I am missing something for the rpm.
I'm not sure if the lack of response is due to not selecting a specific protocol.
Apologies for the formatting of the below, looks fine in editing but seems to have no spacing when previewed for some reason.

Thank you for any assistance.

Sending the following command/query: AT D
	Received char: T
	Received char: D
	Received char: A
	Received char: 8
	Received char: 1
	Received char: _
	Received char: V
	Received char: 0
	Received char: .
	Received char: 1
	Received char: 2
	Received char: \r
	Received char: \n
	Received char: O
	Received char: K
	Received char: \r
	Received char: \n
	Received char: >
Delimiter found.
All chars received: TDA81V0.12OK
Clearing input serial buffer
Sending the following command/query: AT Z
	Received char: A
	Received char: T
	Received char: _
	Received char: Z
	Received char: \r
	Received char: E
	Received char: L
	Received char: M
	Received char: 3
	Received char: 2
	Received char: 7
	Received char: _
	Received char: v
	Received char: 2
	Received char: .
	Received char: 1
	Received char: \r
	Received char: \n
	Received char: >
Delimiter found.
All chars received: ATZELM327v2.1
Clearing input serial buffer
Sending the following command/query: AT E0
	Received char: A
	Received char: T
	Received char: _
	Received char: E
	Received char: 0
	Received char: \r
	Received char: O
	Received char: K
	Received char: \r
	Received char: \n
	Received char: >
Delimiter found.
All chars received: ATE0OK
Clearing input serial buffer
Sending the following command/query: AT S0
	Received char: O
	Received char: K
	Received char: \r
	Received char: \n
	Received char: >
Delimiter found.
All chars received: OK
Clearing input serial buffer
Sending the following command/query: AT AL
	Received char: ?
	Received char: \r
	Received char: \n
	Received char: >
Delimiter found.
All chars received: 
Clearing input serial buffer
Sending the following command/query: AT ST 00
	Received char: ?
	Received char: \r
	Received char: \n
	Received char: >
Delimiter found.
All chars received: 
Clearing input serial buffer
Sending the following command/query: AT SP A0
	Received char: ?
	Received char: \r
	Received char: \n
	Received char: >
Delimiter found.
All chars received: 
Setting protocol via AT TP A%c did not work - trying via AT SP %c
Clearing input serial buffer
Sending the following command/query: AT SP 0
	Received char: O
	Received char: K
	Received char: \r
	Received char: \n
	Received char: >
Delimiter found.
All chars received: OK
Setting protocol via AT SP %c did not work
Connected to ELM327
Service: 1
PID: 12
Normal length query detected
Query string: 010C1
Clearing input serial buffer
Sending the following command/query: 010C1
	Received char: ?
	Received char: \r
	Received char: \n
	Received char: >
Delimiter found.
All chars received: 
Expected response header: 410C
Response not detected
WARNING: Number of payload chars is less than the number of expected response chars returned by ELM327 - returning 0
RPM: 0`
jimwhitelaw commented

Note that any time you get a "?" response it means the ELM327 did not understand the command sent. This can happen even with documented AT commands as some clones don't implement the full command set.

When setting protocol to Auto, the ELM327 does not do the protocol search immediately, rather it does so on the first PID query to the ECU. The protocol search can take some time, so you need to account for that or it will time out. If you're using myELM327.begin(), this will be done for you, otherwise you can copy the code into your own program.

ELMduino/src/ELMduino.cpp

Lines 104 to 138 in e81f308

// Automatic searching for protocol requires setting the protocol to AUTO and then
// sending an OBD command to initiate the protocol search. The OBD command "0100"
// requests a list of supported PIDs 0x00 - 0x20 and is guaranteed to work
if ((String)protocol == "0")
{
// Tell the ELM327 to do an auto protocol search. If a valid protocol is found, it will be saved to memory.
// Some ELM clones may not have memory enabled and thus will perform the search every time.
sprintf(command, SET_PROTOCOL_TO_AUTO_H_SAVE, protocol);
if (sendCommand_Blocking(command) == ELM_SUCCESS)
{
if (strstr(payload, RESPONSE_OK) != NULL)
{
// Protocol search can take a comparatively long time. Temporarily set
// the timeout value to 30 seconds, then restore the previous value.
uint16_t prevTimeout = timeout_ms;
timeout_ms = 30000;
int8_t state = sendCommand_Blocking("0100");
if (state == ELM_SUCCESS)
{
timeout_ms = prevTimeout;
connected = true;
return connected;
}
else if (state == ELM_BUFFER_OVERFLOW)
{
while (elm_port->available())
elm_port->read();
}
timeout_ms = prevTimeout;
}
}
}

  • 👍1
reflexsa commented

Thanks for the reply, so I assume I would add this to the 'void setup()'?
I plan to use protocol #6 as my vehicle seems to not be too happy when on automatic mode:
myELM327.initializeELM(6,500);

jimwhitelaw commented

Yes, that should work. If you specify the protocol in initializeELM()) then the protocol search is not needed.

reflexsa commented

For some reason if I add that it seems that the ESP gets stuck in basically a bootloop. I'm not sure if it is just the placement of the initialize function. I suspect it should maybe move between the ELM port connect and before the myELM327.begin. I'm using the ESP_Bluetooth_Serial example to start with so the setup looks as follows:

void setup()
{
#if LED_BUILTIN
  pinMode(LED_BUILTIN, OUTPUT);
  digitalWrite(LED_BUILTIN, LOW);
#endif
  myELM327.initializeELM(6,500); //set protocol and data timeout
  DEBUG_PORT.begin(115200);
  SerialBT.setPin("1234");
  ELM_PORT.begin("ArduHUD", true);
  
  if (!ELM_PORT.connect("OBDII"))
  {
    DEBUG_PORT.println("Couldn't connect to OBD scanner - Phase 1");
    while(1);
  }

  if (!myELM327.begin(ELM_PORT, true, 2000)) //,ISO_15765_11_BIT_500_KBAUD can add instead of auto initialize?
  {
    Serial.println("Couldn't connect to OBD scanner - Phase 2");
    while (1);
  }

  Serial.println("Connected to ELM327");
}
PowerBroker2 commented

I would not call initializeELM() directly, but set all parameters in begin() instead.

  • 👍1
reflexsa commented

Sadly I'm still a bit stuck. Seem to just get this response after the initial AT items. I tried setting the protocol in 3 ways. Leaving it as auto and then tried these:
if (!myELM327.begin(ELM_PORT, true, 2000,6))
And
if (!myELM327.begin(ELM_PORT, true, 2000,ISO_15765_11_BIT_500_KBAUD))

It could be that I'm changing that in the wrong place. If I am assuming correctly it looks like I can talk to the adapter but not to the vehicle. It does work in torque so I'm guessing it's just a setting or something

Connected to ELM327
Service: 1
PID: 12
Normal length query detected
Query string: 010C1
Clearing input serial buffer
Sending the following command/query: 010C1
	Received char: ?
	Received char: \r
	Received char: \n
	Received char: >
Delimiter found.
All chars received: 
Expected response header: 410C
Response not detected
WARNING: Number of payload chars is less than the number of expected response chars returned by ELM327 - returning 0
RPM: 0
PowerBroker2 commented

"NO DATA" means your ELM can't talk to the car for that particular PID. "?", however, means the ELM doesn't recognize the PID request. Not sure why it wouldn't recognize 010C1, considering it's an often used and standard PID...

reflexsa commented

Thank you. I may mess around in Torque to see if I can find out what request it is using for RPM for example. I did not set up anything special in the app so I assumed it was using fairly standard PIDs. Sorry that the testing and responses take so long, I suspect we are in rather different time zones and I only have an hour or so in the evenings to experiment

jimwhitelaw commented

@reflexsa It's easier to help if you can post as much data as possible. The full sketch and the serial debug output.

reflexsa commented

Is the serial debug output basically what is in the serial monitor when the debug option is 'true' in the . begin function?

reflexsa commented

Below is the sketch which is the "ESP32_Bluetooth_Serial" example using the pincode. For the protocol I have tried changing:
if (!myELM327.begin(ELM_PORT, true, 2000))
to
if (!myELM327.begin(ELM_PORT, true, 2000,6))
to
if (!myELM327.begin(ELM_PORT, true, 2000,ISO_15765_11_BIT_500_KBAUD))
to
if (!myELM327.begin(ELM_PORT, true, 2000,'6'))

#include "BluetoothSerial.h"
#include "ELMduino.h"


BluetoothSerial SerialBT;
#define ELM_PORT   SerialBT
#define DEBUG_PORT Serial


ELM327 myELM327;


uint32_t rpm = 0;


void setup()
{
#if LED_BUILTIN
  pinMode(LED_BUILTIN, OUTPUT);
  digitalWrite(LED_BUILTIN, LOW);
#endif

  DEBUG_PORT.begin(115200);
  SerialBT.setPin("1234");
  ELM_PORT.begin("ArduHUD", true);
  
  if (!ELM_PORT.connect("OBDII"))
  {
    DEBUG_PORT.println("Couldn't connect to OBD scanner - Phase 1");
    while(1);
  }

  if (!myELM327.begin(ELM_PORT, true, 2000))
  {
    Serial.println("Couldn't connect to OBD scanner - Phase 2");
    while (1);
  }

  Serial.println("Connected to ELM327");
}


void loop()
{
  float tempRPM = myELM327.rpm();

  if (myELM327.nb_rx_state == ELM_SUCCESS)
  {
    rpm = (uint32_t)tempRPM;
    Serial.print("RPM: "); Serial.println(rpm);
  }
  else if (myELM327.nb_rx_state != ELM_GETTING_MSG)
    myELM327.printError();
}

The output in the serial monitor is the below (once it begins asking for PID12 it will just keep repeating the same section that I posted above).

ets Jul 29 2019 12:21:46

rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:1
load:0x3fff0030,len:1184
load:0x40078000,len:13260
load:0x40080400,len:3028
entry 0x400805e4
Clearing input serial buffer
Sending the following command/query: AT D
	Received char: T
	Received char: D
	Received char: A
	Received char: 8
	Received char: 1
	Received char: _
	Received char: V
	Received char: 0
	Received char: .
	Received char: 1
	Received char: 2
	Received char: \r
	Received char: \n
	Received char: O
	Received char: K
	Received char: \r
	Received char: \n
	Received char: >
Delimiter found.
All chars received: TDA81V0.12OK
Clearing input serial buffer
Sending the following command/query: AT Z
	Received char: A
	Received char: T
	Received char: _
	Received char: Z
	Received char: \r
	Received char: E
	Received char: L
	Received char: M
	Received char: 3
	Received char: 2
	Received char: 7
	Received char: _
	Received char: v
	Received char: 2
	Received char: .
	Received char: 1
	Received char: \r
	Received char: \n
	Received char: >
Delimiter found.
All chars received: ATZELM327v2.1
Clearing input serial buffer
Sending the following command/query: AT E0
	Received char: A
	Received char: T
	Received char: _
	Received char: E
	Received char: 0
	Received char: \r
	Received char: O
	Received char: K
	Received char: \r
	Received char: \n
	Received char: >
Delimiter found.
All chars received: ATE0OK
Clearing input serial buffer
Sending the following command/query: AT S0
	Received char: O
	Received char: K
	Received char: \r
	Received char: \n
	Received char: >
Delimiter found.
All chars received: OK
Clearing input serial buffer
Sending the following command/query: AT AL
	Received char: ?
	Received char: \r
	Received char: \n
	Received char: >
Delimiter found.
All chars received: 
Clearing input serial buffer
Sending the following command/query: AT ST 00
	Received char: ?
	Received char: \r
	Received char: \n
	Received char: >
Delimiter found.
All chars received: 
Clearing input serial buffer
Sending the following command/query: AT SP A0
	Received char: ?
	Received char: \r
	Received char: \n
	Received char: >
Delimiter found.
All chars received: 
Setting protocol via AT TP A%c did not work - trying via AT SP %c
Clearing input serial buffer
Sending the following command/query: AT SP 0
	Received char: O
	Received char: K
	Received char: \r
	Received char: \n
	Received char: >
Delimiter found.
All chars received: OK
Setting protocol via AT SP %c did not work
Connected to ELM327
Service: 1
PID: 12
Normal length query detected
Query string: 010C1
Clearing input serial buffer
Sending the following command/query: 010C1
	Received char: ?
	Received char: \r
	Received char: \n
	Received char: >
Delimiter found.
All chars received: 
Expected response header: 410C
Response not detected
WARNING: Number of payload chars is less than the number of expected response chars returned by ELM327 - returning 0
RPM: 0
Service: 1
PID: 12
Normal length query detected
Query string: 010C1
Clearing input serial buffer
Sending the following command/query: 010C1
	Received char: ?
	Received char: \r
	Received char: \n
	Received char: >
Delimiter found.
All chars received: 
Expected response header: 410C
Response not detected
WARNING: Number of payload chars is less than the number of expected response chars returned by ELM327 - returning 0
RPM: 0
jimwhitelaw commented 
Sending the following command/query: AT SP 0
	Received char: O
	Received char: K
	Received char: \r
	Received char: \n
	Received char: >
Delimiter found.
All chars received: OK
Setting protocol via AT SP %c did not work

Looks like it's still trying to set Auto protocol search and then times out on the next call ("010C1"). If the specific protocol is being set properly in your begin() method, then we should see:

Sending the following command/query: AT SP A0
reflexsa commented

Ideally I should use protocol ID 6. With the above I just left the default code which I assumed would try the auto search. I'm not sure why it would not send SP A0 and is for some reason sending SP 0.

I'm not sure if I am getting closer or further away at this point using '6' for the protocol:

Clearing input serial buffer
Sending the following command/query: AT TP A6
	Received char: ?
	Received char: \r
	Received char: \n
	Received char: >
Delimiter found.
All chars received: 
Setting protocol via AT TP A%c did not work - trying via AT SP %c
Clearing input serial buffer
Sending the following command/query: AT SP 6
	Received char: O
	Received char: K
	Received char: \r
	Received char: \n
	Received char: >
Delimiter found.
All chars received: OK
Setting protocol via AT SP %c did not work
PowerBroker2 commented

Thanks to @jimwhitelaw this should be fixed in #242. Can you retest with the main branch?

reflexsa commented

Thank you both. I will hopefully retest in an hour or so

reflexsa commented

This is the new output:

Clearing input serial buffer
Sending the following command/query: AT TP A6
	Received char: ?
	Received char: \r
	Received char: \n
	Received char: >
Delimiter found.
All chars received: 
Setting protocol via AT TP A%c did not work - trying via AT SP %c
Clearing input serial buffer
Sending the following command/query: AT SP 6
	Received char: O
	Received char: K
	Received char: \r
	Received char: \n
	Received char: >
Delimiter found.
All chars received: OK
Connected to ELM327
Service: 1
PID: 12
Normal length query detected
Query string: 010C1
Clearing input serial buffer
Sending the following command/query: 010C1
	Received char: ?
	Received char: \r
	Received char: \n
	Received char: >
Delimiter found.
All chars received: 
Expected response header: 410C
Response not detected
WARNING: Number of payload chars is less than the number of expected response chars returned by ELM327 - returning 0
RPM: 0
reflexsa commented

I also wanted to ask. I see the query for RPM is being sent as '010C1'. What is the 1 at the end for?

jimwhitelaw commented

The 1 at the end is telling the ELM327 that we expect only one response for this query. This can speed up some queries because the ELM doesn’t have to wait for possible additional responses.

  • 👍1
reflexsa commented

Is it easily possible to remove this 1 from the query? I would just like to test if that is what is causing my issue. I have been browsing through the cpp file but I'm not exactly sure where is the best place to change this.
I suspect my adapter's firmware may not support requesting a single response but I will check the firmware tonight as it looks like this was only introduced in v1.3

PowerBroker2 commented

You can use the ESP32 test sketch to input AT commands and PID queries manually for testing purposes like this.

  • 👍1
reflexsa commented

Ok I think I have some progress to report. I tried out the ESP32 test sketch and had the following responses. I have noticed that my adapter is not the 'PIC' kind so maybe doesn't support all the functions. I have ordered what I hope is a PIC based version but will see when it arrives. In the meantime please see the 'serial output' below. It looks like if I query with '010C' I get a response but when using '010C1' it does not (just included from where I set the protocl):

>AT SP 6
OK

>010C
410C0000
410C0000

>010F
410F40

>01011
?

>010B
410B64

>010C1
?

>010C
410C0000
410C0000

>010C
410C0D70
410C0D78

>010C
410C0D74
410C0D74

>010C
410C0D74
410C0D58
jimwhitelaw commented

Yes, it looks like some progress and I agree that what you're seeing is probably related to the specific adapter you're using. It seems a bit unusual that some queries return a single response and most return two responses. In any case, as you've discovered, appending the 1 is not understood by the adapter. If you wanted to permanently stop sending the suffix 1 for your queries, you'd want to modify this code in the formatQuery() method to set query[6-8] all to '\0', although I think a different adapter is a better option:

ELMduino/src/ELMduino.cpp

Lines 230 to 245 in 464ecaa

if (num_responses > 0xF)
{
query[6] = ((num_responses >> 4) & 0xF) + '0';
query[7] = (num_responses & 0xF) + '0';
query[8] = '\0';
upper(query, 8);
}
else
{
query[6] = (num_responses & 0xF) + '0';
query[7] = '\0';
query[8] = '\0';
upper(query, 7);
}

reflexsa commented

Thank you both for the help so far. I'm hoping the other adapter will also happen to work on auto protocol as well just to make things more convenient. Will report back in the next day or two

PowerBroker2 commented

I added a specifyNumResponses boolean flag to the main class. If you set it to false and then run the queries, you should have success without having to edit the lib files.

Can you test the main branch code and let me know if it fixes things for you?

  • 👍1
reflexsa commented

Ok I have bad news and bad news.
So I tested using the main branch and ESP_Bluetooth_Serial sketch changing the flag using the following:
myELM327.specifyNumResponses = false;

This resulted in the below output. Strangely, the "C" in the query has become a "<". I'm not sure if that is because of the way I set the flag. The second unfortunate thing was the new adapter I ordered turned out to have the exact same hardware even though it was advertised otherwise. I will order a different one and hope for the best...

Service: 1
PID: 12
Normal length query detected
Query string: 010<
Clearing input serial buffer
Sending the following command/query: 010<
	Received char: ?
	Received char: \r
	Received char: \n
	Received char: >
Delimiter found.
All chars received: 
Expected response header: 410<
Response not detected
WARNING: Number of payload chars is less than the number of expected response chars returned by ELM327 - returning
jimwhitelaw commented

I found the issue with the “<“ char and submitted a fix (#244). Please update your main branch and retest. Thx

  • 👍1
reflexsa commented

Thank you! It looks like we have had success! For reference the adapter that was giving the hassles shows up as a version v2.1 in Torque with some notes of it being a cheap clone. I still plan to get a better adapter but glad this one can work especially for initial prototyping.

Please see the output below, rpm looks correct:

Service: 1
PID: 12
Normal length query detected
Query string: 010C
Clearing input serial buffer
Sending the following command/query: 010C
	Received char: 4
	Received char: 1
	Received char: 0
	Received char: C
	Received char: 0
	Received char: D
	Received char: 9
	Received char: 6
	Received char: \r
	Received char: \n
	Received char: 4
	Received char: 1
	Received char: 0
	Received char: C
	Received char: 0
	Received char: D
	Received char: 8
	Received char: C
	Received char: \r
	Received char: \n
	Received char: \r
	Received char: \n
	Received char: >
Delimiter found.
All chars received: 410C0D96410C0D8C
Expected response header: 410C
Double response detected
64-bit response: 
	responseByte_0: 150
	responseByte_1: 13
	responseByte_2: 0
	responseByte_3: 0
	responseByte_4: 0
	responseByte_5: 0
	responseByte_6: 0
	responseByte_7: 0
RPM: 869
  • 🎉1
PowerBroker2 commented

Fixed in version 3.3.0

  • 👍1