Setting Protocol not working correctly
Closed this issue · 6 comments
Hello everyone,
First of all thank you for the amazing library you have created, it helped me a lot so far with my project.
Lately I came upon a problem and I don't know if anyone else has something similar but it looks weird.
The equipment I use is the following:
Arduino MKR1010, a veepeak obd scanner and an HC05 module, on top of that also a screen and a gps shield but I don't think is relevant.
I noticed the problem when I allowed the debugging, and in the serial monitor I saw that when it runs the AT commands in the start up everything works good until it sends the 0100 PID, as it can be seen in the log, then the message "Setting protocol via AT TP A%c did not work - trying via AT SP %c " appears. Is this the expected behavior? Seems weird to me that it sends for the 0100 PID even though it seems that a protocol set up is expected.
Then the following command is the AT SP 0, and it seems that the scanner still carries a payload from the previous command so then the error "STOPPED" appears. The same happens both while I am using a simulator or a car.
Log:
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: \r
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: 1
Received char: .
Received char: 5
Received char: \r
Received char: \r
Received char: >
Delimiter found.
All chars received: ATZELM327v1.5
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: \r
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: \r
Received char: >
Delimiter found.
All chars received: OK
Clearing input serial buffer
Sending the following command/query: AT AL
Received char: O
Received char: K
Received char: \r
Received char: \r
Received char: >
Delimiter found.
All chars received: OK
Clearing input serial buffer
Sending the following command/query: AT ST 00
Received char: O
Received char: K
Received char: \r
Received char: \r
Received char: >
Delimiter found.
All chars received: OK
Clearing input serial buffer
Sending the following command/query: AT SP A0
Received char: O
Received char: K
Received char: \r
Received char: \r
Received char: >
Delimiter found.
All chars received: OK
Clearing input serial buffer
Sending the following command/query: 0100
Received char: S
Received char: E
Received char: A
Received char: R
Received char: C
Received char: H
Received char: I
Received char: N
Received char: G
Received char: .
Received char: .
Received char: .
Received char: \r
Received char: 4
Received char: 1
Received char: 0
Received char: 0
Received char: 9
Received char: 8
Received char: 1
Received char: A
Received char: 8
Received char: 0
Received char: 0
Received char: 3
Received char: \r
Received char: 4
Received char: 1
Received char: 0
Received char: 0
Received char: B
Received char: E
Received char: 1
Received char: F
Received char: A
Received char: 8
Received char: 1
Received char: 3
Received char: \r
Received char: 4
Received char: 1
Received char: 0
Received char: 0
Received char: 9
OBD receive buffer overflow (> 40 bytes)
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: 8
Received char: 0
Received char: 0
Received char: 3
Received char: \r
Received char: 4
Received char: 1
Received char: 0
Received char: 0
Received char: 9
Received char: 8
Received char: 1
Received char: A
Received char: 8
Received char: 0
Received char: 1
Received char: 3
Received char: \r
Received char: S
Received char: T
Received char: O
Received char: P
Received char: P
Received char: E
Received char: D
Received char: \r
Received char: \r
Received char: >
Delimiter found.
All chars received: 80034100981A8013STOPPED
ELM responded with error "STOPPED"
Setting protocol via AT SP %c did not work
I am new to this, so please if you need more information let me know.
Can you post your code (formatted with markdown)?
Hello,
Actually is regardless the code, below is the Multiple PIDs example, and I am getting the same output as I posted above.
I am getting later the data I need but I just found it weird, and I was wondering if it is happening just to me or if it is a bug.
#include "ELMduino.h"
#define ELM_PORT Serial1
const bool DEBUG = true;
const int TIMEOUT = 2000;
const bool HALT_ON_FAIL = false;
ELM327 myELM327;
typedef enum { ENG_RPM, SPEED } obd_pid_states;
obd_pid_states obd_state = ENG_RPM;
float rpm = 0;
float mph = 0;
void setup() {
Serial.begin(115200);
ELM_PORT.begin(38400);
Serial.println("Attempting to connect to ELM327...");
if (!myELM327.begin(ELM_PORT, DEBUG, TIMEOUT)) {
Serial.println("Couldn't connect to OBD scanner");
if (HALT_ON_FAIL)
while (1);
}
Serial.println("Connected to ELM327");
}
void loop() {
switch (obd_state) {
case ENG_RPM: {
rpm = myELM327.rpm();
if (myELM327.nb_rx_state == ELM_SUCCESS) {
Serial.print("rpm: ");
Serial.println(rpm);
obd_state = SPEED;
} else if (myELM327.nb_rx_state != ELM_GETTING_MSG) {
myELM327.printError();
obd_state = SPEED;
}
break;
}
case SPEED: {
mph = myELM327.mph();
if (myELM327.nb_rx_state == ELM_SUCCESS) {
Serial.print("mph: ");
Serial.println(mph);
obd_state = ENG_RPM;
} else if (myELM327.nb_rx_state != ELM_GETTING_MSG) {
myELM327.printError();
obd_state = ENG_RPM;
}
break;
}
}
}
What’s happening is that when the 0100 command is sent to initiate the protocol search, you’re getting responses back from multiple cpus in the system. This would be “normal” for some systems, but it seems like the library isn’t currently handling that scenario. So either the response handling needs a change or maybe a different command should be sent. 0100 is used as that is what is demonstrated in the ELM327 docs.
Check out the changes I made to master - let me know if it fixes your issue. Basically, when you send the 0100 command, the lib test's to see if there is overflow. If so, it flushes the input buffer before moving on.
Hello,
I will test it tomorrow that I will have the car again and I will let you know :)
Sorry for the delay, I tested it yesterday and it worked like a charm!