Closed ham8962 closed 1 year ago
Thank you, I'm glad you like the library! Firstly, your code isn't formatted correctly. Secondly, from what I can tell, your code isn't structured properly. See the multiple pids example
Thank you for your quick response. I received your answer just before falling asleep. (I didn't know there were multi-turn examples and ended up going to bed while contemplating other people's questions. It's 6 a.m. in Korea now, haha.) As soon as I wake up, I will try running the multi-turn request example you provided. I will share the results afterwards. Thank you sincerely.
I apologize for the delayed response. Thanks to the example you provided, I successfully solved my problem.
19:31:27.901 -> Normal length query detected 19:31:27.901 -> Query string: 010D1 19:31:27.948 -> Clearing input serial buffer 19:31:27.948 -> Sending the following command/query: 010D1 19:31:27.948 -> Received char: 0 19:31:27.948 -> Received char: 1 19:31:27.948 -> Received char: 0 19:31:27.948 -> Received char: D 19:31:27.948 -> Received char: 1 19:31:27.948 -> Received char: \r 19:31:27.948 -> Received char: 4 19:31:27.948 -> Received char: 1 19:31:27.948 -> Received char: 19:31:27.948 -> Received char: 0 19:31:27.948 -> Received char: D 19:31:27.995 -> Received char: 19:31:27.995 -> Received char: 3 19:31:27.995 -> Received char: 2 19:31:27.995 -> Received char: _ 19:31:27.995 -> Received char: \r 19:31:27.995 -> Received char: \r 19:31:27.995 -> Received char: > 19:31:27.995 -> Delimiter found. 19:31:27.995 -> All chars received: 010D1410D32 19:31:27.995 -> Expected response header: 410D 19:31:27.995 -> Single response detected 19:31:27.995 -> 64-bit response: 19:31:27.995 -> responseByte_0: 50 19:31:27.995 -> responseByte_1: 0 19:31:27.995 -> responseByte_2: 0 19:31:27.995 -> responseByte_3: 0 19:31:27.995 -> responseByte_4: 0 19:31:27.995 -> responseByte_5: 0 19:31:27.995 -> responseByte_6: 0 19:31:27.995 -> responseByte7: 0 19:31:27.995 -> mph: 31.07 19:31:27.995 -> Service: 1 19:31:27.995 -> PID: 12 19:31:27.995 -> Normal length query detected 19:31:27.995 -> Query string: 010C1 19:31:27.995 -> Clearing input serial buffer 19:31:27.995 -> Sending the following command/query: 010C1 19:31:28.042 -> Received char: 0 19:31:28.042 -> Received char: 1 19:31:28.042 -> Received char: 0 19:31:28.042 -> Received char: C 19:31:28.042 -> Received char: 1 19:31:28.042 -> Received char: \r 19:31:28.042 -> Received char: 4 19:31:28.042 -> Received char: 1 19:31:28.042 -> Received char: 19:31:28.042 -> Received char: 0 19:31:28.042 -> Received char: C 19:31:28.042 -> Received char: 19:31:28.042 -> Received char: 1 19:31:28.042 -> Received char: 7 19:31:28.042 -> Received char: 19:31:28.089 -> Received char: 9 19:31:28.089 -> Received char: 8 19:31:28.089 -> Received char: _ 19:31:28.089 -> Received char: \r 19:31:28.089 -> Received char: \r 19:31:28.089 -> Received char: > 19:31:28.089 -> Delimiter found. 19:31:28.089 -> All chars received: 010C1410C1798 19:31:28.089 -> Expected response header: 410C 19:31:28.089 -> Single response detected 19:31:28.089 -> 64-bit response: 19:31:28.089 -> responseByte_0: 152 19:31:28.089 -> responseByte_1: 23 19:31:28.089 -> responseByte_2: 0 19:31:28.089 -> responseByte_3: 0 19:31:28.089 -> responseByte_4: 0 19:31:28.089 -> responseByte_5: 0 19:31:28.089 -> responseByte_6: 0 19:31:28.089 -> responseByte_7: 0 19:31:28.089 -> rpm: 1510.00 19:31:28.089 -> Service: 1 19:31:28.089 -> PID: 13
One question I have is regarding the similarity between my initial incorrect code and some successful multi-PID implementations by other users. whether it's implemented or not Is it because of the difference in library versions? Code posted by a user with the nickname neces0325 on page 4 of closed (sorry for the poor cause analysis since it's a beginner) (https://github.com/PowerBroker2/ELMduino/issues/53)
And is there a method that requires odometer? I refer to the official document of wikipidia odometer pid When requested PID by the Serial Bluetooth Terminal application, NODATA was output as a result. If there is an odometer method, should I add Switch - CASE to the example of the module you gave me? In the conditional statement outputting RPM, insert speed into the obd_state variable In the conditional statement outputting SPEED, insert the odometer into the obd_state variable In the conditional statement outputting ODOMETER, insert the rpm into the obd_state variable, like this way.
The next step is to receive rpm, speed, and odometer data in the new esp32 with the esp-now protocol
Then, I will use a hotspot to access the java server I created and store three pieces of data in DataBase(MariaDB). That's the whole point of the project I'm planning Please let me know if you have any advice or tips. (Thank you for your library production and advice)
One question I have is regarding the similarity between my initial incorrect code and some successful multi-PID implementations by other users. whether it's implemented or not Is it because of the difference in library versions?
Yes, there was a large version update (I forget exactly when) that converted the PID query functions from synchronous to asynchronous and that changed the behavior/structure of the multi-PID example.
And is there a method that requires odometer? I refer to the official document of wikipidia odometer pid When requested PID by the Serial Bluetooth Terminal application, NODATA was output as a result. If there is an odometer method, should I add Switch - CASE to the example of the module you gave me? In the conditional statement outputting RPM, insert speed into the obd_state variable In the conditional statement outputting SPEED, insert the odometer into the obd_state variable In the conditional statement outputting ODOMETER, insert the rpm into the obd_state variable, like this way.
That sounds correct to me - sounds like a cool project - I hope you can get it working!
Thank you for answering to my question!! I was waiting for your reply.(really thank you)
I'll try and find the odometer pid and share the results with you. Thank you for praising my project initiative. If you have any technical advice on my project, please let me know.
No problem, I don't have any advice at the moment, but if you have questions or come up against roadblocks, the Arduino forum is really helpful if you post your entire code (in tags) along with a full description of your issue.
@ham8962 If you have interest work together. I want save and show data on Rasperry PI with MQTT Protokoll. https://github.com/DerKleinePunk/ODB-ESP32-Reader
@DerKleinePunk Thank you! @PowerBroker2 I received a "No DATA" response when requesting the Odometer PID through a Serial Terminal application on my phone Does it means that the Odometer data is not available for my car?
Regarding alternative methods, one idea I think is using a GPS module to track and record the distance traveled during each driving cycle
Is this a good method?
"NO DATA" means your car doesn't support that pid. You could use a GPS module. Depending on how accurate you want the odometer function to be, you might consider using a Pixhawk controller to get more accurate displacement than a GPS module by itself.
@PowerBroker2 Thank you!
@PowerBroker2
Can you please explain what meen with Pixhawk controller. My Internet Search show Drone Controller.
I am using your library with great appreciation (truly, thank you). However, as a beginner, I'm currently facing some difficulties.
My setup consists of an ESP32, ELM327, and a 2018 Hyundai Kona. The code I'm using is as follows: `#include "BluetoothSerial.h"
include "ELMduino.h"
/*
if !defined(CONFIG_BT_SPP_ENABLED)
error Serial Bluetooth not available or not enabled. It is only available for the ESP32 chip.
endif
*/ BluetoothSerial SerialBT; ELM327 myELM327;
uint32_t rpm = 0; char CONVERTED_RPM[32]; char CONVERTED_KPH[32]; char CONVERTED_ENGINETEMP[32]; char CONVERTED_INTAKETEMP[32];
/ String MACadd = "AA:BB:CC:11:22:33"; uint8_t address[6] = {0xAA, 0xBB, 0xCC, 0x11, 0x22, 0x33}; //uint8_t address[6] = {0x00, 0x1D, 0xA5, 0x02, 0xC3, 0x22}; / String name = "OBDII"; const char *pin = "1234"; //<- standard pin would be provided by default bool connected;
void setup() { Serial.begin(115200); //SerialBT.setPin(pin); SerialBT.begin("ESP32-test", true); myELM327.begin(SerialBT, true, 2000); //SerialBT.setPin(pin); Serial.println("The device started in master mode, make sure remote BT device is on!");
// connect(address) is fast (upto 10 secs max), connect(name) is slow (upto 30 secs max) as it needs // to resolve name to address first, but it allows to connect to different devices with the same name. // Set CoreDebugLevel to Info to view devices bluetooth address and device names connected = SerialBT.connect(name); //connected = SerialBT.connect(address);
if(connected) { Serial.println("Connected Succesfully!"); } else { while(!SerialBT.connected(10000)) { Serial.println("Failed to connect. Make sure remote device is available and in range, then restart app."); } } // disconnect() may take upto 10 secs max / if (SerialBT.disconnect()) { Serial.println("Disconnected Succesfully!"); } / // this would reconnect to the name(will use address, if resolved) or address used with connect(name/address). //SerialBT.connect(); }
void loop() {
float tempRPM = myELM327.rpm();
if (myELM327.nb_rx_state == ELM_SUCCESS) { rpm = (uint32_t)tempRPM; sprintf(CONVERTED_RPM, "%d", rpm); Serial.print("RPM: "); Serial.println(CONVERTED_RPM); } else if (myELM327.nb_rx_state != ELM_GETTING_MSG){ myELM327.printError(); }
int32_t kph = myELM327.kph(); if (myELM327.nb_rx_state == ELM_SUCCESS) { sprintf(CONVERTED_KPH, "%d", myELM327.kph()); Serial.print("Km/h: "); Serial.println(CONVERTED_KPH); } else if (myELM327.nb_rx_state != ELM_GETTING_MSG){ myELM327.printError(); }
delay(500); }`
(rewrite the loop)
`void loop() {
float tempRPM = myELM327.rpm();
if (myELM327.nb_rx_state == ELM_SUCCESS) { rpm = (uint32_t)tempRPM; sprintf(CONVERTED_RPM, "%d", rpm); Serial.print("RPM: "); Serial.println(CONVERTED_RPM); } else if (myELM327.nb_rx_state != ELM_GETTING_MSG){ myELM327.printError(); }
int32_t kph = myELM327.kph(); if (myELM327.nb_rx_state == ELM_SUCCESS) { sprintf(CONVERTED_KPH, "%d", myELM327.kph()); Serial.print("Km/h: "); Serial.println(CONVERTED_KPH); } else if (myELM327.nb_rx_state != ELM_GETTING_MSG){ myELM327.printError(); }
delay(500); }`
The output on the serial monitor is: 04:40:23.289 -> Service: 1 04:40:23.289 -> PID: 12 04:40:23.289 -> Normal length query detected 04:40:23.289 -> Query string: 010C1 04:40:23.289 -> Clearing input serial buffer 04:40:23.336 -> Sending the following command/query: 010C1 04:40:23.808 -> Received char: 0 04:40:24.321 -> Received char: 1 04:40:24.790 -> Received char: 0 04:40:25.304 -> Received char: C 04:40:25.815 -> Received char: 1 04:40:26.329 -> Received char: \r 04:40:26.796 -> Received char: 4 04:40:27.310 -> Received char: 1 04:40:27.825 -> Received char: 04:40:28.295 -> Received char: 0 04:40:28.811 -> Received char: C 04:40:29.324 -> Received char: 04:40:29.792 -> Received char: 1 04:40:30.305 -> Received char: 6 04:40:30.817 -> Received char: 04:40:31.331 -> Received char: 0 04:40:31.796 -> Received char: A 04:40:32.310 -> Received char: 04:40:32.821 -> Received char: \r 04:40:33.333 -> Received char: \r 04:40:33.799 -> Received char: > 04:40:33.799 -> Delimiter found. 04:40:33.799 -> All chars received: 010C1410C160A 04:40:33.799 -> Expected response header: 410C 04:40:33.799 -> Single response detected 04:40:33.846 -> 64-bit response: 04:40:33.846 -> responseByte_0: 10 04:40:33.846 -> responseByte_1: 22 04:40:33.846 -> responseByte_2: 0 04:40:33.846 -> responseByte_3: 0 04:40:33.846 -> responseByte_4: 0 04:40:33.846 -> responseByte_5: 0 04:40:33.846 -> responseByte_6: 0 04:40:33.846 -> responseByte7: 0 04:40:33.846 -> Service: 1 04:40:33.846 -> PID: 13 04:40:33.846 -> Normal length query detected 04:40:33.846 -> Query string: 010D1 04:40:33.846 -> Clearing input serial buffer 04:40:33.846 -> Sending the following command/query: 010D1 04:40:33.846 -> RPM: 1410 04:40:33.846 -> Km/h: 0 04:40:34.359 -> Received char: 0 04:40:34.824 -> Received char: 1 04:40:35.337 -> Received char: 0 04:40:35.834 -> Received char: D 04:40:36.346 -> Received char: 1 04:40:36.860 -> Received char: \r 04:40:37.330 -> Received char: 4 04:40:37.858 -> Received char: 1 04:40:38.364 -> Received char: 04:40:38.833 -> Received char: 0 04:40:39.345 -> Received char: D 04:40:39.858 -> Received char: 04:40:40.325 -> Received char: 0 04:40:40.838 -> Received char: 0 04:40:41.358 -> Received char: 04:40:41.826 -> Received char: \r 04:40:42.339 -> Received char: \r 04:40:42.852 -> Received char: > 04:40:42.852 -> Delimiter found. 04:40:42.852 -> All chars received: 010D1410D00 04:40:42.852 -> Expected response header: 410D 04:40:42.852 -> Single response detected 04:40:42.852 -> 64-bit response: 04:40:42.852 -> responseByte_0: 0 04:40:42.852 -> responseByte_1: 0 04:40:42.852 -> responseByte_2: 0 04:40:42.852 -> responseByte_3: 0 04:40:42.852 -> responseByte_4: 0 04:40:42.852 -> responseByte_5: 0 04:40:42.852 -> responseByte_6: 0 04:40:42.852 -> responseByte7: 0 04:40:42.852 -> Service: 1 04:40:42.852 -> PID: 13 04:40:42.852 -> Normal length query detected 04:40:42.852 -> Query string: 010D1 04:40:42.899 -> Clearing input serial buffer 04:40:42.899 -> Sending the following command/query: 010D1 04:40:42.899 -> RPM: 0 04:40:42.899 -> Km/h: 0 04:40:43.367 -> Received char: 0 04:40:43.880 -> Received char: 1 04:40:44.395 -> Received char: 0 04:40:44.863 -> Received char: D 04:40:45.377 -> Received char: 1 04:40:45.850 -> Received char: \r 04:40:46.368 -> Received char: 4 04:40:46.884 -> Received char: 1 04:40:47.351 -> Received char: 04:40:47.864 -> Received char: 0 04:40:48.377 -> Received char: D 04:40:48.889 -> Received char: 04:40:49.355 -> Received char: 0 04:40:49.870 -> Received char: 0 04:40:50.385 -> Received char: 04:40:50.855 -> Received char: \r 04:40:51.369 -> Received char: \r 04:40:51.885 -> Received char: > 04:40:51.885 -> Delimiter found. 04:40:51.885 -> All chars received: 010D1410D00 04:40:51.885 -> Expected response header: 410D 04:40:51.885 -> Single response detected 04:40:51.885 -> 64-bit response: 04:40:51.885 -> responseByte_0: 0 04:40:51.885 -> responseByte_1: 0 04:40:51.885 -> responseByte_2: 0 04:40:51.885 -> responseByte_3: 0 04:40:51.885 -> responseByte_4: 0 04:40:51.885 -> responseByte_5: 0 04:40:51.885 -> responseByte_6: 0 04:40:51.885 -> responseByte7: 0 04:40:51.885 -> Service: 1 04:40:51.885 -> PID: 13 04:40:51.885 -> Normal length query detected 04:40:51.885 -> Query string: 010D1 04:40:51.885 -> Clearing input serial buffer 04:40:51.932 -> Sending the following command/query: 010D1 04:40:51.932 -> RPM: 0 04:40:51.932 -> Km/h: 0 04:40:52.400 -> Received char: 0 04:40:52.913 -> Received char: 1 04:40:53.383 -> Received char: 0 04:40:53.895 -> Received char: D 04:40:54.408 -> Received char: 1 04:40:54.923 -> Received char: \r 04:40:55.389 -> Received char: 4 04:40:55.905 -> Received char: 1 04:40:56.419 -> Received char: 04:40:56.886 -> Received char: 0 04:40:57.400 -> Received char: D 04:40:57.915 -> Received char: 04:40:58.383 -> Received char: 0 04:40:58.900 -> Received char: 0 04:40:59.415 -> Received char: 04:40:59.885 -> Received char: \r 04:41:00.397 -> Received char: \r 04:41:00.911 -> Received char: > 04:41:00.911 -> Delimiter found. 04:41:00.911 -> All chars received: 010D1410D00 04:41:00.911 -> Expected response header: 410D 04:41:00.911 -> Single response detected 04:41:00.911 -> 64-bit response: 04:41:00.911 -> responseByte_0: 0 04:41:00.911 -> responseByte_1: 0 04:41:00.911 -> responseByte_2: 0 04:41:00.911 -> responseByte_3: 0 04:41:00.911 -> responseByte_4: 0 04:41:00.911 -> responseByte_5: 0 04:41:00.911 -> responseByte_6: 0 04:41:00.911 -> responseByte7: 0 04:41:00.911 -> Service: 1 04:41:00.911 -> PID: 13 04:41:00.911 -> Normal length query detected 04:41:00.958 -> Query string: 010D1 04:41:00.958 -> Clearing input serial buffer 04:41:00.958 -> Sending the following command/query: 010D1 04:41:00.958 -> RPM: 0 04:41:00.958 -> Km/h: 0 04:41:01.427 -> Received char: 0 04:41:01.942 -> Received char: 1 04:41:02.454 -> Received char: 0 04:41:02.923 -> Received char: D 04:41:03.436 -> Received char: 1 04:41:03.951 -> Received char: \r 04:41:04.418 -> Received char: 4 04:41:04.931 -> Received char: 1 04:41:05.444 -> Received char: 04:41:05.917 -> Received char: 0 04:41:06.431 -> Received char: D 04:41:06.949 -> Received char: 04:41:07.418 -> Received char: 0 04:41:07.931 -> Received char: 0 04:41:08.449 -> Received char: 04:41:08.915 -> Received char: \r 04:41:09.431 -> Received char: \r 04:41:09.944 -> Received char: > 04:41:09.944 -> Delimiter found. 04:41:09.944 -> All chars received: 010D1410D00 04:41:09.944 -> Expected response header: 410D 04:41:09.944 -> Single response detected 04:41:09.944 -> 64-bit response: 04:41:09.944 -> responseByte_0: 0 04:41:09.944 -> responseByte_1: 0 04:41:09.944 -> responseByte_2: 0 04:41:09.944 -> responseByte_3: 0 04:41:09.944 -> responseByte_4: 0 04:41:09.944 -> responseByte_5: 0 04:41:09.944 -> responseByte_6: 0 04:41:09.944 -> responseByte_7: 0 04:41:09.944 -> Service: 1 04:41:09.944 -> PID: 13 04:41:09.944 -> Normal length query detected 04:41:09.990 -> Query string: 010D1 04:41:09.990 -> Clearing input serial buffer 04:41:09.990 -> Sending the following command/query: 010D1 04:41:09.990 -> RPM: 0 04:41:09.990 -> Km/h: 0
Although I understand that the km/h should read 0 since the vehicle is stationary, I don't understand why the PID 010D keeps repeating. Is this an issue with the ELM327?
I would appreciate it if you could explain the cause and provide a solution. Once again, thank you for creating this library and for your diligent responses.
(I am a student from Korea. Please excuse any awkwardness in my English expressions.)