It's possible to sniff the codes with a Y-splitter! At least the standard OBDII codes were sniff-able, albeit the data rates are slow. All I need now is a DS-II
I've bit the bullet and bought a DS-II, which is the same as the Toyota Intelligent Tester. Hopefully it will be here in 2 weeks.
DS-II arrived. I can control the windows from the device. Looks like I can't control the immo, though :-(
The following is some basic data sent to and from, and what triggered it. Now detecting Comms check Roof DTC Roof activity select Quarter windows down Quarter windows up Main windows down Main Windows up Windows down Windows up Display Roof ECU ID (It's 800) Windows up
Using some reasoning, I believe these are the following codes for "Windows down" Now it's time for hex maths and breakdowns! Let's start with 83 BC F0 30 03 01 63 0x83 is the the format byte. 0xBC looks to be the target, and 0xF0 looks to be the source. Thus, the 3 value header should be. 83 F0 BC 0x30 is the length of the proceeding values. 0x30 is 48 in decimal. We can work out 30 by counting the number of bytes (6 possible values) and multiplying it by 8... therefore 48. 0x03 is the service identification byte. 01x is the data payload 0x63 is a checksum byte. This is calculated as follows: 0x83+0xBC+0xF0+0x30+0x03+0x01 == 611 (decimal). 611 mod 256 == 99 decimal == 0x63 Now onto the other two! 83 F0 BC 70 03 01 A3 & 83 F0 BC C1 E9 8F 68 can be broken down a bit more. These are actually the same message. 0xF0 is the target. 0xBC is the sender. 0x70 is the length. 0x70 == 112 decimal. If we add up the proceeding bytes after 0x70 (and ignore the header of the proceeding 83 F0 BC), we get 14 values. 14 * 8 == 112. Thus these two lines can be represented as follows: 83 F0 BC 70 03 01 A3 C1 E9 8F 68. 0x03 is, again, the service id byte. 0x01 0xA3 0xC1 0xE9 0x8F is the payload data. 0x68 should be the checksum. I am unsure how this checksum is made, as adding the 11 byte sequences mod 256 gives me different numbers. From the "now detecting" phase of the data transmission, I can assume 0xF0 is the DS-II and 0xBC is the roof ECU.
All sounds pretty reasonable really! Inject some strings and see what happens. Nothing to lose. Very good work.
The checksums looks to be on a per packet basis, even if the packets span multiple lines. This makes sense, and assuming that the checksum spanned over both packets was silly on my part. 0x83+0xF0+0xBC+0x70+0x03+0x01 == 675 decimal. mod 256 == 163 decimal == 0xA3 -- packet checksummed ok. 0x83+0xF0+0xBC+0xC1+0xE9+0x8F == 1128 decimal. mod 256 == 104 decimal == 0x68 -- packet checksummed ok. I've tried using to no avail. It returned NO DATA from the ELM327. This may be because of a time out, I'm not too sure. I may try AT SH means Set Header, so both commands span two lines when talking to the ELM.
From reading the ELM327 data sheet, NO DATA could be because the chipset has timed out (default timeout is 200ms). Looking at the Copen's protocol specs, I should really bump this up to 5000ms (5 seconds). This looks to be the physical initialisation packet for ECU comms with the roof. It is repeated multiple times on different sections (Windows up, down, etc) 0x81 is the format byte that puts the ECU into init mode. 0xBC is the target 0xF0 is the source 0x81 is the startCommunication Request Service Id (format byte repeated) 0xAE is the checksum, which is correct. With 0x81 as the init mode format byte, I think we can rule out any packets with 0x83.
This looks to be the response packet from the ECU after init. From reading up on the KWP2000 / ISO specs, 0x83 -- response from ECU stating that there are 3 bytes of data in this packet 0xF0 -- Target (Scanner) 0xBC -- Source (Roof ECU) 0xC1 -- StartCommunications response service ID 0xE9 & 0x8F look to be the vehicle key bytes. These appear to be the wrong way around, as they should be 8F E9 according to the ISO spec. 0x68 is the checksum
These look to related to the passenger window up button being engaged. I tried again today to get the windows to go down, with no joy. Tomorrow I'm going to try: The reason I wanna send 80 BC F0 81 AE is because it looks like the ELM327 alters the 80 to be 81 based on the number of data bytes - in this case 1. I'm still a bit miffed, as a simple replay of commands should work in lowering the windows
You would have thought so! But life dunna always work like that for me very often :-(( But persistence, faith and intelligence get results.
Maybe it's talking over different pins. I'd be interested in seeing if the DS-II can still lower the windows with all the pins except 4,5, 7 and 16 removed. I'll try with a different ELM scanner, to see if that makes a difference to the recorded data.
In all honesty what you are doing is beyond my field of expertise. My typical game is hacking milages, immo data and radio codes, which is all straight forward hex and soldering warfare. Making cars run that don't, solving vehicle faults. Programming keys etc. Then when it comes to CAN, VAN and K-line stuff, I check to make sure we have data in and out with a scope, and no shorts etc. Then that's enough to prove to myself those data lines work. I have never played with packet sniffing and injection like this! So you're on your own as much as I would love to be able to help!
Going back to the Windows Down command stream, I have worked out the following. 81 BC F0 81 AE -- Init stream telling the roof to accept commands (second x81) 83 F0 BC C1 E9 8F 68 -- Roof responding with "Ok, I understand" (xC1) 83 BC F0 30 03 01 63 -- Lower windows command from DS-II 83 F0 BC 70 03 01 A3 -- Lower windows ack from ECU 81 BC F0 82 AF -- Finalise stream from DS-II (x82) 81 F0 BC C2 EF -- Finalise ack from ECU (xC2) The following are service IDs, as per ISO / KWP In KWP2000, the communication must keep active through a data exchange of request/response type or through testerPresent service. It looks like 82 BC F0 3E 01 6D is the testerPresent (x3E) command for the Copen. The response back should be 81 F0 BC 7E AB (x7E) If the timeout is reached, you have to re-init again via 81 BC F0 81 AE (this explains why we see this 3 times, once per click of the "Windows down" button the the DS-II).
Sure I know very little about this as well - I'm learning as I'm going along, which was a huge point of doing this... Keeps me out of the pub
It looks like the ELM327 is setting the header incorrectly (incorrectly being against my wishes). On the plus side, it inserts the checksum automagically, so I don't need to compute it. To get around this, I'm gonna try ATWM 81 BC F0 81 -- Sets the wakeup message (ELM327 inserts the checksum) ATSH 83 BC F0 -- Sets the header. Since the ELM327 will always insert the number of data bytes for you, but how it is done depends on the values that you assign to this (x83) byte. If the second digit of this first header byte is anything other than 0 (zero), the ELM327 assumes that you wish to have the length value inserted in that first byte when sending. This "helpfulness" of the ELM is a bit annoying, but it should mean that if I set the header as above, and then issue 30 03 01, the windows should go down. I'll hook two ELM327s to the Y-Splitter, one sending the commands and the other scanning the interface to see what is ACTUALLY being sent.
BOOM! Got it working. The minimum list of commands (one per line) are: ATSP5 ATWM 81 BC F0 81 ATSH 83 BC F0 30 03 01 -- Windows down 30 03 02 -- Windows up 30 03 04 -- Quarter windows down 30 03 08 -- Quarter Windows up So it turns out I wasn't waking up the bus. If I had have read the KWP2000 and ELM327 specs earlier, I'd have copped this days ago.
