Comments (9)
UPDATE: Solved the problem now it works without a problem.
Great news! 🎉
can you suggest how can I receive without sending any request just keep receiving the frames.
Normally, the OBD9141 protocol doesn't support that. As far as I know the ECU is always the slave, and you have to actively request information and then listen for the response. I've not heard of any ECU that proactively sends information.
If this answers your question, please close this issue. :)
from obd9141.
Thanks for your reply.
I didn't clarify it enough for you.
I know that the ISO9141 protocol doesn't support that.I don't mean to connect the arduino to the ECU and wait for it to send something since it will not send anything.
what I meant is to connect a diagnostic tool to the ECU to let it talk and connect the arduino to see the communication between the DiagTool and the ECU (just like the Scope or the logic analyzer)
so is that possible. the arduino will be only listening without interfering with the communication
from obd9141.
so is that possible. the arduino will be only listening without interfering with the communication
Yeah, should be possible. Not sure if you need this library for that... it may help with the parsing though.
Just enable the serial port with the right baud rate as set_port(true) would do. Then you can just read bytes from the serial port and those will be the bytes going over the kline. Depending on the timing of your particular vehicle you can probably just do a readBytes
on the serial port with an appropriate timeout, the standard request method has the read code here.
In short; set up the Rx line and serial port (see begin). Then use readBytes
on the serial port to read whatever goes over the bus.
from obd9141.
Hi @iwanders @jwdsoft,
Thanks for posting this discussion. I am following the readerKWP script to test KWP2000 fast with my ECU simulator. I am following the script as it is, but it gets me init_success=false. so I tried....
-sending request message as C1 33 F1 81
-checking buffer[4] = 0xC1 instead of buff[3] which is by default defined in script. and it reads 0xC1 and I get init_success=true and able to read RPM value. Thats good. BUT...............
when I add other PIDs to read like 0x0C and 0x0D, I don't get any other. Should I send different request message for every ECU every time? or missing something in here....?
In getPID my message is uint8_t message[5] = {0xC1, 0x33, 0xF1, mode, pid};
Please suggest~ Thanks.
from obd9141.
I don't think you're guaranteed to have 0xC1
in the message, in these examples, the start is 0xc2
, but that is not anywhere in the response?
from obd9141.
@iwanders I tried 0xC2 but it didn't work. Let me brief you, what I am trying.....
In initKWP()
, I am trying to send request message as uint8_t message[4] = {0xC1, 0x33, 0xF1, 0x81};
and then checking the buffer[4] == 0xC1
if if(this->requestKWP(&message, 4) == 7)
In requestKWP(void* request, uint8_t request_len)
I am reading the request_len and add checksum as buf[request_len] = this->checksum(&buf, request_len);
. The buf gives me buf: 193 51 241 129
and checksum is 102
and buffer[0] is 128, later while calculating const uint8_t msg_len = (this->buffer[0]) & 0b111111;
which gives '0' and seems the problem continues from here since the msg_len comes '0'.
Intensely, if I set the msg_len = 4 ("message length") it works for reading ECU only for RPM as my getPID(uint8_t pid, uint8_t mode, uint8_t return_length)
is defined as:
bool OBD9141::getPID(uint8_t pid, uint8_t mode, uint8_t return_length){
uint8_t message[5] = {0xC1, 0x33, 0xF1, mode, pid};
// header of request is 5 long, first three are always constant.
bool res = this->request(&message, 5, return_length+5);
// checksum is already checked, verify the PID.
if (this->buffer[4] != pid){
return false;
} return res;
}
Please correct me. Thanks.
from obd9141.
The buf gives me buf: 193 51 241 129 and checksum is 102 and buffer[0] is 128, later while calculating const uint8_t msg_len = (this->buffer[0]) & 0b111111; which gives '0' and seems the problem continues from here since the msg_len comes '0'.
But... 193 51 241 129
is 'C1', '33', 'F1', '81'
, so the exact request that was sent? It looks like the echo of the request itself? Curiously, only the request method has the logic to read the echo?
So; you may need to read the length + 1
bytes to account for the echo occuring on your serial port. Though I'm not fully sure why request
has handling for the echo and requestKWP
doesn't.
from obd9141.
Hi @iwanders yes, that the exact request that was sent. I just logged it to confirm what requesting is actually sending.
well, please have a look on my log below and suggest, what I am missing....
This is when I am considering const uint8_t remainder = msg_len + 2 + 1;
(getting msg_len from buffer[0] & 0b111111)
Looping
Before 25 ms / 25 ms startup.
Enable port.
Request Message: 193 51 241 129 -----> C1 33 F1 81 (Request)
requestKWP() starts.....
request_len: 4
CheckSum: 102
REQ: 193 51 241 129 ----> C1 33 F1 81 (Request)
buffer[0]:128
msg_len:0
Rem: 3
ret_len: 4
RSP: 128 241 16 3 0 ---> 80 F1 10 3 0 (Response)
init_success:0
This is when I consider const uint8_t remainder = 4 + 2 + 1;
(forcibly set msg_len=4)
Looping
Before 25 ms / 25 ms startup.
Enable port.
Request Message: 193 51 241 129 ----> C1 33 F1 81 (Request)
requestKWP function starts.....
request_len: 4
CheckSum: 102
REQ: 193 51 241 129 ---> C1 33 F1 81 (Request)
buffer[0]:128
msg_len:0
Rem: 7
ret_len: 8
RSP: 128 241 16 3 193 234 143 190 0 ----> 80 F1 10 3 C1 EA 8F BE 0 (Response)
buffer[4]=0xC1 OK...
init_success:1
even though, in both the cases the buffer[0] comes same 128, but while reading msg_len from buffer[0], it gives '0'.
from obd9141.
Hmm, so the request you are sending is the start communication request; this one. But then for your system it returns more bytes than the expected 6 from here
Searching for that 80 F1 10 3 C1 EA 8F BE 0
sequence, I find: this txt file.
Which implies that the length is the 4th bytes buffer[3]
for this response? Which is very different from the implementation followed in my library.
If we look at that url carefully, it's a txt from this wiki; perhaps Suzuki Diagnostic System requests aren't the same as KWP even though the physical bus is the same?
That entire project could be of great help to you, given that it looks like you are dealing with this particular flavour?
from obd9141.
Related Issues (20)
- 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
- esp32 with OBD9141 not work HOT 19
- 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
- OBDII fault code names HOT 1
- initKWP not completing initialization HOT 3
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.