jrelder
Jr. Member
Karma: +0/-0
 Offline
Posts: 36
|
 |
« on: May 22, 2017, 03:36:25 PM »
|
|
|
Hi, First off I have a VW Passat B5 2000 reg. I'm currently trying to make a k-line ECU display for my car and I'm starting with the arduino code from here: http://grauonline.de/wordpress/?p=74Now I believe my 5 baud unit works correctly because I get a response from the ECU of 3 bytes in length. However, the values of the response are incorrect, I expect to receive 0x55 0x01 0x8A (according to the arduino code from the above link and my own use of his windows .exe k-line software on my own car). However when trying to read the Dashboard I get 0x00 0x00 0x00 and when reading the Engine I get 0x00 0x00 0x55. Vagcom and the windows .exe software from the link above both confirm my car uses the KW1281 protocol. Can anyone tell me where I'm going wrong? I've read other threads which talk about sending a byte to choose ISO or KW and also which say the ECU just responds with one sync byte of 0x55. Which is the correct information? Thanks, James |
|
|
|
|
Logged
|
|
|
|
nihalot
Full Member
Karma: +41/-3
Offline
Posts: 117
|
|
« Reply #1 on: May 23, 2017, 02:14:24 AM »
|
|
|
What baud rate have you tried? 9600? Or 10400? On edc15, the timing is also very critical. https://www.blafusel.de/obd/obd2_kw1281.htmlI have taken a few logs of mpps doing a read of the ecu, if you want I could post those here... |
|
|
|
|
Logged
|
www.tangentmotorsport.commultimap/LC/rolling antilag for MG1/MED17/EDC17/MED9/EDC15 contact for reverse engineering services of any ECU/TCU
|
|
|
jrelder
Jr. Member
Karma: +0/-0
Offline
Posts: 36
|
|
« Reply #2 on: May 23, 2017, 04:12:00 AM »
|
|
|
What baud rate have you tried? 9600? Or 10400? On edc15, the timing is also very critical. https://www.blafusel.de/obd/obd2_kw1281.htmlI have taken a few logs of mpps doing a read of the ecu, if you want I could post those here... I have tried both 9600 and 10400 with the same result for both. As for timing I realise this, but the code I am using was made and tested by the creator on a B5 and judging by the fact I get exactly three response bytes ( no more or no less ) I think the timing is fine. I was wondering whether I should be using 8N1 or 7O1 for the 10400 communication? Also how important is the 510ohm resistor between the k-line and 12v, because I am using 540ohm? Thanks for that, the logs may well be helpful if you wouldn't mind. But I have examined the logs of the pc based KW1281 software from the link in my first post and I can see that it does the 5 baud init then tried 9600 baud, gets an incorrect response and then redoes the 5 baud unit and tries 10400 baud and gets the correct response. So from this I know several things: - I need 5 baud unit
- Then I need to immediately switch to 10400 baud
- Then I should receive 0x55 0x01 0x8A
But this is exactly the process I am trying... |
|
|
|
|
Logged
|
|
|
|
nihalot
Full Member
Karma: +41/-3
Offline
Posts: 117
|
|
« Reply #3 on: May 23, 2017, 12:55:21 PM »
|
|
|
Its 8N1 for both baud rates
On the edc15's I've tested, if the respone is 0x55 0x6B 0x8F(corresponds to kwp20xx), then the baud rate is 10400. For kwp1281, always 9600.
So 5 baud
Switch to 9600
Response after ~300ms 0x55 0x01 0x8a
How are you interfacing arduino with k-line? I ran into a lot of problems with the schematics i found on google, so its better to hack an old kkl cable or use something like the L9637d
|
|
|
|
|
Logged
|
www.tangentmotorsport.commultimap/LC/rolling antilag for MG1/MED17/EDC17/MED9/EDC15 contact for reverse engineering services of any ECU/TCU
|
|
|
jrelder
Jr. Member
Karma: +0/-0
Offline
Posts: 36
|
|
« Reply #4 on: May 23, 2017, 04:19:26 PM »
|
|
|
Thanks for the info, I'll leave it at 8N1.
My car definitely uses the KW1281 protocol (verified by VAGCOM and another diagnostic software), but from the PC diagnostic software I have used I have found that I get an incorrect response at 9600 baud but the correct response at 10400. This also coincides with all the information I have read online about the baud being 10400.
I'm thinking maybe I should put a 300ms delay before trying to read the ECU response in my code. Because the code that I started with doesn't have a delay here and although the writer said it worked with their 97 B5, maybe this is where my issue is. Although, I am receiving 3 bytes though...
I'm actually using an L9637 with a 540ohm resistor between K-Line and 12v and TX - TX / RX - RX (this confused me at first but the datasheet cryptically says: TX - Input for K as output).
|
|
|
|
|
Logged
|
|
|
|
nihalot
Full Member
Karma: +41/-3
Offline
Posts: 117
|
|
« Reply #5 on: May 23, 2017, 07:57:59 PM »
|
|
|
Kw1281 is always 9600 baud as far as i know.
Can you show me a source stating otherwise?
After slow init with your PC tool, what response do you get?
Be more specific, logs would definitely help...
|
|
|
|
|
Logged
|
www.tangentmotorsport.commultimap/LC/rolling antilag for MG1/MED17/EDC17/MED9/EDC15 contact for reverse engineering services of any ECU/TCU
|
|
|
jrelder
Jr. Member
Karma: +0/-0
Offline
Posts: 36
|
|
« Reply #6 on: May 23, 2017, 08:11:40 PM »
|
|
|
Well this site says that although it can be 4800, 9600 or 10400, it was 10,400 baud in practice for his VW ECU: https://www.blafusel.de/obd/obd2_kw1281.html. I have also seen other sources which say it is 10400 baud at least for VW. I will post the exact log tomorrow once I get to a pc but the pc tool basically goes as follows: Slow init (5 baud) Try 9600 Response from ECU of 3 bytes Byte values are incorrect Slow init again Try 10400 Response from ECU of 3 bytes Byte values are correct Read sensor values etc |
|
|
|
|
Logged
|
|
|
|
nihalot
Full Member
Karma: +41/-3
Offline
Posts: 117
|
|
« Reply #7 on: May 23, 2017, 08:19:06 PM »
|
|
|
hmm. I would like to take a look at your ecu flash file. If you can post here?
regards
|
|
|
|
|
Logged
|
www.tangentmotorsport.commultimap/LC/rolling antilag for MG1/MED17/EDC17/MED9/EDC15 contact for reverse engineering services of any ECU/TCU
|
|
|
jrelder
Jr. Member
Karma: +0/-0
Offline
Posts: 36
|
|
« Reply #8 on: May 30, 2017, 08:10:48 AM »
|
|
|
Sorry for the late reply. I don't have my ECU flash file as I haven't flashed my ECU before, but I have the cable and so I can try and get a dump of the ECU firmware. As for the log files, the log from the PC based diagnostic tool on which the Arduino code is based is: readlabelfiles
readlabelfile 8D0907558B.lbl
group0,0: Basic, Function
labelfiles 1
connecting (com=1 blk=100 bit=-1 byte=8000)
trying baud 9600
sendinit 1
send5baud 1
sending bits 0 1 0 0 0 0 0 0 0 1
receiving
received, blockcounter=0:
0000 : 95 81 CA : ...
trying baud 10400
sendinit 1
send5baud 1
sending bits 0 1 0 0 0 0 0 0 0 1
receiving
received, blockcounter=0:
0000 : 55 01 8A : U..
readconnectblocks
receiving
received, blockcounter=1:
0000 : 0F 01 F6 38 44 30 39 30 : ...8D090
0008 : 36 30 31 38 52 20 20 03 : 6018R .
sending 03 02 09 03
receiving
received, blockcounter=3:
0000 : 17 03 F6 31 2E 38 4C 20 : ...1.8L
0008 : 52 34 2F 35 56 20 4D 4F : R4/5V MO
0010 : 54 52 20 47 30 31 20 03 : TR G01 .
sending 03 04 09 03
receiving
received, blockcounter=5:
0000 : 07 05 F6 30 30 30 34 03 : ...0004.
sending 03 06 09 03
receiving
received, blockcounter=7:
0000 : 08 07 F6 00 1F 42 00 1C : .....B..
0008 : 03 : .
sending 03 08 09 03
receiving
received, blockcounter=9:
0000 : 03 09 09 03 : ....
blockwait 100 ms
readsensors group 1
sending 04 0A 29 01 03
receiving
received, blockcounter=11:
0000 : 0F 0B E7 01 C8 00 05 0A : ........
0008 : C2 14 64 80 10 FF B3 03 : ..d.....
type 1 () a=200 b=0
type 5 () a=10 b=194
type 20 () a=100 b=128
type 16 () a=255 b=179
closing
closed As you can see, it attempts 9600 and gets a wrong response of 95 81 CA, and then attempts 10400 and gets a correct response of 55 01 8A. |
|
|
|
|
Logged
|
|
|
|
jrelder
Jr. Member
Karma: +0/-0
Offline
Posts: 36
|
|
« Reply #9 on: May 30, 2017, 02:48:44 PM »
|
|
|
Just an update, after reading this page: http://kaikretzberg.de/?p=1250#engine-id-01The author states that "Selecting 14400 Baud will cause in 0x00 and 0xFF packets which is apparently wrong." i.e. too high a baud can give 0x00/0xFF values. So I am now thinking that maybe the Arduino is not using an 'exact' or close enough baud of 10400, due to the fact it is emulating the serial port rather than using a hardware serial. So therefore maybe the baud is just a bit too high and giving me these 0x00 values as a result. I am going to try and use the implementation of NewSoftwareSerial provided by the original author of the k-line code (and confirmed as working on his B5), as opposed to the standard Arduino SoftwareSerial library, in the hope that perhaps it will provide a closer baud to 10400. I will hopefully be able to test it tomorrow and confirm whether this fixes my problem. |
|
|
|
« Last Edit: May 30, 2017, 02:50:15 PM by jrelder »
|
Logged
|
|
|
|
|
nyet
|
|
« Reply #10 on: May 30, 2017, 02:50:37 PM »
|
|
|
So I am now thinking that maybe the Arduino is not using an 'exact' or close enough baud of 10400, due to the fact it is emulating the serial port rather than using a hardware serial.
That seems extremely likely. Not usual for serial software bitbanging. Especially since 10400 is an oddball rate. |
|
|
|
|
Logged
|
ME7.1 tuning guideECUx PlotME7Sum checksumTrim heatmap toolPlease do not ask me for tunes. I'm here to help people make their own. Do not PM me technical questions! Please, ask all questions on the forums! Doing so will ensure the next person with the same issue gets the opportunity to learn from your ex
|
|
|
jrelder
Jr. Member
Karma: +0/-0
Offline
Posts: 36
|
|
« Reply #11 on: May 30, 2017, 04:09:47 PM »
|
|
|
That seems extremely likely. Not usual for serial software bitbanging. Especially since 10400 is an oddball rate.
Well the arduino SerialSoftware library doesn't exactly bitbang in the basic sense of the word. Instead it calculates all sorts of timing parameters based upon the clock speed of the Arduino variant and the desired baud rate. But obviously it still isn't as exact as hardware serial. Anyway seeing as the original code author has their version of the previous NewSoftwareSerial library working with the B5, I'm hopeful. Although I'm sure I tried their version before without success. |
|
|
|
« Last Edit: May 30, 2017, 04:12:49 PM by jrelder »
|
Logged
|
|
|
|
jrelder
Jr. Member
Karma: +0/-0
Offline
Posts: 36
|
|
« Reply #12 on: May 31, 2017, 06:39:45 AM »
|
|
|
Okay so just an update. I couldn't get the author' verion of the NewSoftwareSerial library working at all. However I did manage to get the hardware serial on the Arduino to work. To do so I had to move the Serial.begin(10400) command to after the 5-baud init, as it seems the hardware serial doesn't like the pin mode being changed after the Serial.begin command.
This isn't ideal because I am worrying I would miss the ECU response due to the time taken to begin the functionality of the serial port, hence why I was trying to initialise the serial prior to the 5-baud init, so that it was ready to receive immediately after the 5-baud init is complete.
Strange I can't get the original author's implementation to work and I have to resort to the hardware serial instead of using the software serial. Anyway I'm one step closer to my goal and in actual fact I will be using an ARM micro controller and not an Arduino for my ECU display. I just wanted to verify the code and hardware on the arduino first as that is what the original author of the code had used.
|
|
|
|
|
Logged
|
|
|
|
nihalot
Full Member
Karma: +41/-3
Offline
Posts: 117
|
|
« Reply #13 on: May 31, 2017, 07:46:39 AM »
|
|
|
Okay so just an update. I couldn't get the author' verion of the NewSoftwareSerial library working at all. However I did manage to get the hardware serial on the Arduino to work. To do so I had to move the Serial.begin(10400) command to after the 5-baud init, as it seems the hardware serial doesn't like the pin mode being changed after the Serial.begin command.
This isn't ideal because I am worrying I would miss the ECU response due to the time taken to begin the functionality of the serial port, hence why I was trying to initialise the serial prior to the 5-baud init, so that it was ready to receive immediately after the 5-baud init is complete.
Strange I can't get the original author's implementation to work and I have to resort to the hardware serial instead of using the software serial. Anyway I'm one step closer to my goal and in actual fact I will be using an ARM micro controller and not an Arduino for my ECU display. I just wanted to verify the code and hardware on the arduino first as that is what the original author of the code had used.
You must do a Serial.end() before 5 baud init and a Serial.begin(10400) after 5 baud init. The ecu waits 300ms before replying. I doubt it takes longer than 300ms to initialise the serial port |
|
|
|
« Last Edit: May 31, 2017, 08:02:11 AM by nihalot »
|
Logged
|
www.tangentmotorsport.commultimap/LC/rolling antilag for MG1/MED17/EDC17/MED9/EDC15 contact for reverse engineering services of any ECU/TCU
|
|
|
jrelder
Jr. Member
Karma: +0/-0
Offline
Posts: 36
|
|
« Reply #14 on: May 31, 2017, 04:24:26 PM »
|
|
|
You must do a Serial.end() before 5 baud init and a Serial.begin(10400) after 5 baud init.
The ecu waits 300ms before replying. I doubt it takes longer than 300ms to initialise the serial port
Thanks for the info. I read in one place the ECU waits 300ms but in all the other websites I saw there was no mention of this. So I assumed it didn't wait. Anyway, I didn't require a Serial.end() as the 5-baud init changes the pin mode which I'm guessing somewhere in the library ensures the Serial.end() is called. I have now moved on to using my STM32 board and it works perfectly. Luckily I got my spare ECU today so I can do testing on the bench without having to go to the car all the time. Thanks for all your help! |
|
|
|
|
Logged
|
|
|
|
|
