-
Notifications
You must be signed in to change notification settings - Fork 115
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Help with Volkswagen MEB (ID.3, Skoda Enyaq etc.) needed #207
Comments
The important info is here: Clearing input serial buffer The ? response indicates that the ELM device did not understand the command. See p.39 of the ELM327 datasheet for details on setting headers. As a guess, all the examples use spaces between the header bytes, so maybe try sending AT SH 17 FC 00 7B and see if that works. |
Nope, Result is the same
in the project where I found the PIDs they fire additional AT commands before set the header. Can this make a different in accepting the header?
|
If you know that the above sequence of AT commands is working with carscanner then perhaps try sending those first. From the output you've provided, I'm not convinced that the protocol has been successfully detected. The last AT command you send with an OK response is "AT TP A7". That tells the ELM to try protocol 7 and fall back to an auto search if that doesn't work. After that, the next command you send should trigger the protocol detection. The ELM327 datasheet (p.29) recommends sending "0100" command to trigger the protocol detection. You should get back a response that starts with "SEARCHING..." followed by some additional bytes indicating which PIDs are supported in that mode. If you use the "AT SP 7" command as above, you won't have to go through the detection part, but it also won't search for any other protocol if 7 is not correct. All OBDII compliant systems are required to support command "0100" so it's a good test to see if you've actually got a valid connection from ELM to ECU before proceeding with other queries. |
I changed my loop that it plays out the AT command sequence I mentioned one by one. Also I set ATH1 to see what headers maybe come in. I try then to get the PIDs for SoC and Temp without setting a header. After that all I jump into a test console, where I can manueall send commands from serial terminal over to ELM. In Log you can see that the AT commands are all accepted and confirmed by ELM. Also if I send some commannd manually like 0140 I get a response 18 DA F1 0A 03 7F 40 11 AA AA AA AA. (ignore the echo I get from Terminal, have to find a way to switch of in PIO) The Header and PID I have found in evDash project. What I meant with Carscanner was, that SoC and Temp get shown there as values, without knowledge of magic behind there. What I wanted to tell was that the ELM should be okay if other software can communicate. This is the link to ID.3 specific code in evDash: https://github.com/nickn17/evDash/blob/master/src/CarVWID3.cpp code:
Log:
|
I found another big list of PIDs. If you search on this page for „BMS Temperatur Pack Gesamt“ - how this record can be used in ElmDuino the proper way to get a value? https://www.goingelectric.de/forum/viewtopic.php?p=1758362&sid=f3168951a5a627b2930c870df144f35a#p1758362 This is the record My interpretation would be |
I googled a bit around: could it be that UDS need a specific handling which is not supported yet by ELMDuino? I have seen some descriptions that the session have to be changed from OBD2 to UDS by fire a command like 0x1003 or so |
I don’t know much about UDS, but since it operates at a layer “above” CAN, it should be possible to use ELMduino to implement the sending and receiving of UDS data. You would need to implement the command formation and data parsing yourself for the PIDS you are interested in. The good news is you have successfully established communication with your ECU and move forward. Also, I note that your switch/case in your loop isn’t working quite the way it should. After each successful response, you should set the next cmd state and then break. As it is, all of the commands are run without respect to the cmd state, immediately after each other. That works for the blocking commands, but is going to cause problems on the processPIDS() commands as there’s no waiting for a response before the next command is sent. Have a close look at the multiple PIDs example program for the correct pattern. |
many thanks for the hint with the break. Copy/paste of one piece of code multiplies the proplem :) I get at least a response on 1003 command. I'll check tomorrow where to go from there
|
Hello, I try since a few days reading the Battery Temperature out of my Enyac. The ELM init works fine and I have a connection. Unfortunately I get not set the appropriate header and the PIDs doesnt respond as well. Maybe someone else has already "hacked" an ID.3 with ELMDuino and is able to give me a hint
I found the header and PIDs in this project under BMS https://github.com/nickn17/evDash/blob/master/src/CarVWID3.cpp
The Header I try to set with
with this response:
My whole loop, where you can see that I try with different approaches (processPid and queryPid) but nothing comes back at all
The log with also initialization shown
The text was updated successfully, but these errors were encountered: