Comments (19)
With this setup i had other library witch work at the same pinrx 16 and tx 17
Do you know which protocol was used by that library? What library was it? If you have something that works, why switch? :)
Did you also try the readerKWP? Fast kwp init and slow kwp init are different, I don't know what you ECU uses to communicate, but you showed 9141-2 init with the slow 5 baud and initKWPSlow not working, might as well try the third and final handshake this library supports.
You can also enable the debug prints by uncommenting this line.
from obd9141.
Hi.
I had 2 libraries one with kwp2000 and other with 9141-2 , both works very slow and intrerrupt my lcd display data. Both use 5-baud.
I tried readKWP , i uncomment ""debug. , you can see upstairs what i capture on serial console.
With 9141-2 i receive 16:17:45.732 -> First read is: 252 , not read from ecu 0x55.
Thanks in advance
from obd9141.
I had 2 libraries one with kwp2000 and other with 9141-2 , both works very slow and intrerrupt my lcd display data. Both use 5-baud.
This library is also synchronous though, so it will also block your main program until the data comes back from the ECU. You will likely have the same experience.
With 9141-2 i receive 16:17:45.732 -> First read is: 252 , not read from ecu 0x55.
Ah, 252 is 0xfc
, that is not the 0x55
that is expected and should be the first byte sent after the handshake. You can try commenting out line 386, and seeing if the other two checks on line 402 and 411 pass.
You could also put print statements in the libraries that are working, to see how their handhake works.
from obd9141.
Thanks for your time.
Must this library work with mc33290 too , right?
I comment the line 386 and nothing happen
15:43:21.733 -> initialization
15:43:21.734 ->
15:43:23.733 -> Before magic 5 baud.
15:43:25.736 -> Before setting port.
15:43:25.736 -> After setting port.
15:43:25.736 -> First read is: 252
15:43:25.769 -> Timeout on read v1.
15:42:31.796 -> Timeout on reading bytes.
15:42:31.893 -> Timeout on reading bytes.
15:42:31.992 -> Timeout on reading bytes.
15:42:31.992 ->
15:42:32.090 -> Timeout on reading bytes.
15:42:32.186 -> Timeout on reading bytes.
15:42:32.283 -> Timeout on reading bytes.
15:42:32.283 ->
from obd9141.
Must this library work with mc33290 too , right?
Certainly, I've used that chip myself with this library.
I comment the line 386 and nothing happen
Looks like just nothing comes back. Tricky! I'd try to record a working handshake with one of the other libraries with a logic analyser, or even just print statements, that way there's something to compare against.
from obd9141.
Hi again. this is what one of library had on serial/debug
07:40:39.979 -> Starting Init
07:40:42.044 -> SYNC Byte: 55
07:40:42.044 -> KEY1: 8 KEY2: 8
07:40:42.076 -> Sending ~KEY2: F7
07:40:42.076 -> Received ~KEY2: F7
07:40:42.108 -> Inverted Address: CC
07:40:42.108 -> Protocol: ISO 9141-2
07:40:42.108 -> 5-baud Init SUCCESS
and sync code is aproximatly the same with your obd9141.cpp
pinMode( txPin, OUTPUT ); // Set the txPin to idle HIGH
delay( 2000 ); // Leave Tx HIGH for 2 seconds before starting the actual init routine
Serial.println( F( "Starting Init" ) );
// Send 0x33 (LSB first) via K-Line to the OBD port (0x33 is address of OBD)
digitalWrite( txPin, LOW ); // start bit
delay( 200 ); // 5 baud means 200ms per bit
digitalWrite( txPin, HIGH ); //11
delay( 400 );
digitalWrite( txPin, LOW ); //00
delay( 400 );
digitalWrite( txPin, HIGH ); //11
delay( 400 );
digitalWrite( txPin, LOW ); //00
delay( 400 );
digitalWrite( txPin, HIGH ); // stop bit
delay( 200 );
mc33290.begin(10400, SERIAL_8N1 , 16 ,17) ; //mc33290 is a hardware serial defined
if( mc33290.available()){
sync =mc33290.read();
//DEBUG
snprintf_P( buffer, BUFLEN, PSTR("SYNC Byte: %2X"), sync );
Serial.println( buffer );
// Continue Init if we got the correct SYNC Byte
if( sync == 0x55 ) {
....}
What is strange if i put a debug in your library in function BEGIN
void OBD9141::begin(OBD_SERIAL_DATA_TYPE & serial_port, uint8_t rx_pin, uint8_t tx_pin){
this->serial = &serial_port;
this->tx_pin = tx_pin;
this->rx_pin = rx_pin;
OBD9141println(tx_pin);
OBD9141println(rx_pin);
OBD9141println(serial_port);
i receive it set port with 0 , but i send from sketch
obd.begin(Serial2, RX_PIN, TX_PIN);
from obd9141.
Thanks for sharing code and prints. I put some backticks (`) in your comment to create code blocks to make it more readable.
OBD9141println(serial_port);
I don't think that print the serial ports' id, I think instead it will try to read a byte from the serial port and print that.
But this one:
mc33290.begin(10400, SERIAL_8N1 , 16 ,17)
that looks like a difference from my library, I don't pass the pin numbers, but it looks like they vary between esp32
and esp32s3
, according to this link, so it could be that you have an esp32s3
style board and are actually opening the serial port on pin 19 and 20 instead of the 16 and 17 you are expecting.
We can certainly pass these pin numbers, I put up a change with 1d07f97 on the issue-45-esp32-serial-port branch, could you give that a go? I obviously can't test this, but if you are indeed on an esp32s3 board, this could fix it.
from obd9141.
Hi and excuse my late answer. I'm not at home and i can verify only after one week because i'm in hollyday. My esp32 is a wroomer 32 u with 32 pinds i't must doesn't matter witch pins used tge serial port because i configured in sketch at the begin line on other pins.and it mjst work. The problem is from other parts, and we will see. Thanks and keep in touch.
from obd9141.
Hi. I arrived at home and i tested the new version of your library.
Doesnt't work the same error:
16:30:05.200 -> initialization
16:30:05.200 ->
16:30:05.559 -> Before magic 5 baud.
16:30:07.357 -> Before setting port.
16:30:07.357 -> After setting port.
16:30:07.357 -> First read is: 0
16:30:07.389 -> Timeout on read v1.
16:30:07.485 -> Timeout on reading bytes.
16:30:07.584 -> Timeout on reading bytes.
How can we see if the serial2 is correct init?
from obd9141.
How can we see if the serial2 is correct init?
Not sure if there's any way... :/
Start by putting a print here to print the pin numbers that are being set, that also confirms the ESP_ARDUINO_VERSION_MAJOR
define is actually set and we are going into that initialisation.
from obd9141.
YES, enter in that ESP_ARDUINO_VERSION_MAJOR
from obd9141.
Hmm, well, the ECU is clearly not talking back. The first read isn't even 252
anymore like it was before. The hardware is the exact same as in this comment? Because this is really weird.
If you have a second arduino & transceiver chip, you can try to listen in on the communication performed on the K-line by just hooking up the Rx and opening a serial port at 10400 baud, that way you should be able to see what the other library sends on the bus and what this one sends. It also allows ruling out eletrical issues.
from obd9141.
Yes it is exactly the same. If i upliad thst library over yours in my esp32 it works..
I will try with an arduino megs these days , first with your library, second as listen, but i don't know exactly how. Between another arduino what transceiver or how make connection. Thanks again.
from obd9141.
HI again. I made teste and tests..... reader_esp32 not work, i receive first byte every time 0.
I tried readerKWPSlow because i have like (1941) other file witch works.
I modified delay times in InitTmplm but not works, received first byte 0.
bool OBD9141::initImpl(bool check_v1_v2){
use_kwp_ = false;
// this function performs the ISO9141 5-baud 'slow' init.
this->set_port(false); // disable the port.
this->kline(true);
delay(350);
// delay(OBD9141_INIT_IDLE_BUS_BEFORE); // no traffic on bus for 3 seconds.
OBD9141println("Before magic 5 baud.");
// next, send the startup 5 baud init..
this->kline(false); delay(200); // start
this->kline(true); delay(200); // first two bits
this->kline(false); delay(600); // second pair
this->kline(true); delay(200); // third pair
this->kline(false); delay(600); // last pair
//this->kline(true); delay(200); // stop bit
// this last 200 ms delay could also be put in the setTimeout below.
// But the spec says we have a stop bit.
STRANGE what is next:
I put only some degub in begin function and set_port like this (marked with //added) , i think it they make some delay:
void OBD9141::begin(OBD_SERIAL_DATA_TYPE & serial_port, uint8_t rx_pin, uint8_t tx_pin){
this->serial = &serial_port;
this->tx_pin = tx_pin;
this->rx_pin = rx_pin;
OBD9141println("1");//added
// Enable the pullup on the Rx Pin, this is not changed by set_port.
pinMode(this->rx_pin, INPUT);
digitalWrite(this->rx_pin, HIGH);
this->set_port(true); // prevents calling this->serial->end() before start.
use_kwp_ = false;
OBD9141println("2");//added
}
void OBD9141::set_port(bool enabled){
if (enabled){
OBD9141println("3"); //added
// Work around the incorrect pinmode configuration in Due.
#ifdef ARDUINO_SAM_DUE
g_APinDescription[this->rx_pin].pPort -> PIO_PDR = g_APinDescription[this->rx_pin].ulPin;
g_APinDescription[this->tx_pin].pPort -> PIO_PDR = g_APinDescription[this->tx_pin].ulPin;
#endif
this->serial->begin(OBD9141_KLINE_BAUD);
} else {
this->serial->end();
OBD9141println("4");//added
#ifdef ARDUINO_SAM_DUE
g_APinDescription[this->rx_pin].pPort -> PIO_PER = g_APinDescription[this->rx_pin].ulPin;
g_APinDescription[this->tx_pin].pPort -> PIO_PER = g_APinDescription[this->tx_pin].ulPin;
#endif
pinMode(this->tx_pin, OUTPUT);
digitalWrite(this->tx_pin, HIGH);
}
}
AND , AND i received this.....what is ok for KWP
17:16:19.124 -> Before magic 5 baud.
17:16:20.932 -> Before setting port.
17:16:20.932 -> 3
17:16:20.932 -> After setting port.
17:16:21.193 -> First read is: 85
17:16:21.225 -> read v1: 239
17:16:21.225 -> read v2: 143
17:16:21.225 -> v1: 239
17:16:21.225 -> v2: 143
17:16:21.290 -> init_success:0
Init return false because remaining last part of initTmpl where after this next line nothing happen, i put a debug again and....not go from this line
// these two should be identical according to the spec.
OBD9141println("CCCC0"); //added - HERE STOPED AND first byte is 0. STRANGEGEGEGEGEGEGEGEGEGEGEGEGEG
//here never arrived
if (check_v1_v2) {
if (v1 != v2){
return false;
}
}
17:26:20.798 -> Before magic 5 baud.
17:26:22.603 -> Before setting port.
17:26:22.603 -> 3
17:26:22.603 -> After setting port.
17:26:22.603 -> First read is: 0
17:26:22.603 -> init_success:0
from obd9141.
Hmm, looks like you're on the right track, things are coming back now.
In initKWPSlow
we actually disable the v1 == v2
check here, since you get a v2
of 143, and that corresponds to the comment there, I think things are working.
Try just disabling this check by setting check_v1_v2 = false
.
from obd9141.
it is setted to false, not enter in that check, after that check is a problem, if i put a debug (print) funtion ....the program stopped
from obd9141.
Well, if the program suddenly stops if you put a print statement somewhere... I think there are other problems in your program / setup. Not much I can do to help with that though.
from obd9141.
It is not from the sketch, it is something inside the library.. If you see first post from yesterday, something is strange. These OBD9141println("") added in OBD9141.begin and OBD9141.set_port add some delay and like i said with them added in the code i can receive good response with KWPSlow.
from obd9141.
OBD9141println("") added in OBD9141.begin and OBD9141.set_port add some delay
What happens if you replace that with a delay(10)
or something? It sounds like a timing issue to me, not like something is fundamentally wrong with the library.
from obd9141.
Related Issues (20)
- missing Serial1 declaration
- KWP Slow init with v1 != v2 HOT 4
- ESP32 support HOT 7
- problem 'serial_port' was not declared in this scope HOT 14
- For ESP32 HOT 3
- k-line speed study HOT 18
- How to make it work.... HOT 20
- How can I know if I'm doing everything right? HOT 5
- A special kind of communication with the ECU HOT 6
- ESP32 Serial1 crash... HOT 2
- KWP71 Compatibility HOT 2
- Unable to initialize obd.init() HOT 5
- The example for esp32 does not work. HOT 3
- PIDS HOT 8
- None of the examples is working HOT 3
- mitisuibishi MUT 2 (kline 5 baud init) HOT 1
- Usage with MCP2025 HOT 2
- LiquidCrystal_I2C problem. HOT 1
- sharing of your OBD9141 project HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from obd9141.