|
|
|
|
|
|
BMW Garage | BMW Meets | Register | Today's Posts | Search |
|
BMW 3-Series (E90 E92) Forum
>
E9x KCAN 101
|
|
10-09-2008, 10:46 PM | #1 |
.
42
Rep 867
Posts |
E9x KCAN 101
Ok, so I scoured the internet a few weeks back and could not find anything about the KCAN bus on the E9x. This bus is essentially the successor to the KBUS used in early models like the E46. Its primarily used for communication between the systems in the BMWs E9x cabin area. Examples include the windows, interior lighting, radio/idrive display, etc.. Attached below are figures of the all of the bus systems including KCAN on the E90, a list of all the modules and some data about the bit rates.
This is a work in progress, so I will be updating this post as we discover more. I will try to keep a log of all the changes in the revision history. The primary objective of this post is to list the commands to interface and/or control the components in the cabin. KCAN is based on CANbus 2.0A (11 bit identifier) with a bit rate of 100 kbits/sec. Some helpful links on CAN: http://www.aa1car.com/library/can_systems.htm http://www.mjschofield.com http://www.interfacebus.com/Design_Connector_CAN.html Revision Notes 1.000:: 10/9/08 First submission. 1.001:: 10/10/08 Formatting, Added info on light ON/OFF sequence 1.002:: 02/17/08 Window Data update ////////////////////////////////////////////////////////////////////// Now, the functions so far: xx = Don't Care nibble/byte value ===================================== Cabin Lights Confirmed Vehicle list: E90 335 ------------------- ON/OFF Sequence: Code:
CANID LEN DATA Notes: 1E3 2 F1 FF Command, wait for response 21A 3 00 10 F7 Response 1E3 2 F0 FF Command To give you an idea what is going on, the F1 FF msg are usually generated continously as you hold down (in) the button. When you release the button the F0 FF msg is generated. The 21A response from the vehicle usually comes within 50 milliseconds. This is usually significantly faster than you could press and release the button. I believe this method is BMWs way of preventing an accidental activation of the lights if there is a quick/momentary button press (e.g weak return spring on the button) or perhaps their way to deal with debounce. OFF Sequence (Alt): Code:
CANID LEN DATA Notes: 1E3 2 F1 FF If you simply issue this command without sending any other 1E3 command the lights will default to an OFF state Windows Confirmed Vehicle list: E90 335 The window controls on the sedan each have their own CANID. All buttons from the drivers side control use the same CANID. The passenger side front control has its own. The rear windows share the same CANID. Some commands only result in an incremental movement (approx 2 - 3 in). The windows controls are not directly linked to the KCAN. The interior buttons are on a seperate bus, LINbus. When you press the button, a message is sent over this bus to the FRM. The FRM serves as a gateway and pushes this request over KCAN to the window motor or JBE (not clear on this yet). WINDOW BUTTON ---over LINbus --> FRM -- over CANbus---> WINDOW MOTOR --------------- Cmds as issued From Front Driver (4 buttons): WIN - Window: FD - Front Driver FP - Front Passenger RD - Rear Driver RP - Rear Passenger DIR - Direction Code:
WIN DIR CANID LEN DATA Notes: FD UP 0FA 3 ?? (04 xx xx issued by button) FP UP 0FA 3 ?? RD UP 0FA 3 xx 04 xx Incremental movement RP UP 0FA 3 xx 20 xx Incremental movement FD DN 0FA 3 ?? (01 xx xx issued by button) FP DN 0FA 3 ?? (10 xx xx issed by button) RD DN 0FA 3 xx 01 xx Incremental movement RP DN 0FA 3 xx 10 xx Incremental movement You can combine the nibbles in the RD and RP to do both at the same time. Ex: Code:
WIN DIR CANID LEN DATA Notes: RP&RD UP 0FA 3 xx 24 xx RP&RD DN 0FA 3 xx 11 xx Code:
WIN CANID LEN DATA Notes: FD 3B6 3 pp pp F0 pp pp - position, FP 3B7 3 pp pp F0 Range {00FC (fullup) - 58FE (fulldn)} RD 3B8 3 pp pp F0 I am not sure what F0 is about. RP 3B9 3 pp pp F0 It may be used as a general state/fault/diagnostic byte. "Thermal Protection of Power Window Motors The FRM and the JBE monitor the power window motor temperature. The motor temperature is determined based on the outside temperature, motor running time and the time the motor is stationary (not operative). Each motor can be switched off individually to prevent the power window motors overheating during operation of the power windows (window regulators). The motor is then deactivated for a defined period of time." Cmds as issued From Front Passenger: Code:
WIN DIR CANID LEN DATA Notes: FD UP 0FB 3 2x xx xx Full Up FD DN 0FB 3 1x xx xx Full Down Ok so thats what Ive got so far. Hopefully more wil chime in and start expermenting to refine/add to the list. Last edited by HighVoltage; 02-17-2009 at 02:48 PM.. |
10-26-2008, 02:03 PM | #2 |
Private First Class
6
Rep 173
Posts |
Have a look if these units on the E46 is similar to the E90. The majority should be the same: (all in hex)
CD changer 18,76,67 Steering lock 5A Light switch module D0 Steering wheel buttons 50 PDC 60 Rain sensor E8 Sunroof 08 Can you check if at least the Steering wheel buttons are the same? I have all the other codes (and message detail) but too much to list here.
__________________
Jun 2006 330i Manual, Active Cruise, Comfort Access, Nav prof, Voice, Bluetooth
|
Appreciate
0
|
10-30-2008, 09:26 AM | #4 | |
.
42
Rep 867
Posts |
Quote:
Im a bit worried that I may be missing CAN packets because the contents of the log seem odd. So Ive developed a couple methods to capture these packets. 1) For each packet, look at the CAN ID and keep track of the number of packets (frequency) that CAN ID produces. Also as a kind of sub-histogram, keep track of the frequency of each of the packets for that CAN ID. (Attached second figure) So for instance the main table would have something like CANID Freq 0AA......100 3B6.......52 Then you can also go look at a table for 0AA: Freq Length Packet 4......4 .......FF 1F 00 FF 5 .... 3 .......00 00 01 2 .... 1 .......0F 2) Set a CAN ID to trigger on, and produce a log of x number of packets both before and after the capture of that CAN ID. The idea here is to see all the communications surrounding the transmission of this CAN ID So what I have been doing is firing up the unit then hit the start button to get the car talking. I will see a ton of traffic and a table for 1) fill up with 30-40 CAN IDs. Once this table stops growing, I *assume* that all the CAN IDs that have been pushed across are (at this time) not what I am interested in observing. I then push the window button and observe the new CAN IDs that will show up in table 1. Then I use these CAN IDs as triggers for method 2. Heres a snapshot. This is using 0FA as a trigger. The log also contains the time differential between sequential packets. For instance 0FA occurred 2550 microseconds after the one above it. Please ignore the Syscounter value. This is a simpe printf mistake I corrected after this capture. It is suppose to show the microsecond counter from the microprocessor that is being used to time stamp each packet and calculate the time differential. Whats got me a bit worried about missing packets is you can see 3B6 a few packets above 0FA. I know I have control of the window using 0FA packets yet I see 3B6, which I have been assuming is the response, in the log BEFORE the assumed command of 0FA. Or perhaps I just dont have the master/slave relationship worked out yet... |
|
Appreciate
0
|
10-30-2008, 01:29 PM | #5 |
Private First Class
6
Rep 173
Posts |
I think you're quite smart in figuring out from the data that you are missing packets.
If you send me your code I'll have a look at how you communicate with the CAN driver of your USB/CAN dongle. At the office we just did the same, because we are running 500k fully packed with data. I had quite a fight with the developer today that wrote code without putting traps in to detect buffer overflow, CAN error state, driver state and interrupt failure. I can probably help you a bit with the code. I have done Freescale and Fujitsu CAN implementations in the past. On the PC side using P-CAN, Vector and RM-bluetooth CAN At some stage even stream video over CAN. What I'm trying to say is that making sure from first principles that your driver/interface to the CAN box/DLL should be solid or robust from a coding perspective, otherwise you will always have some kind of problem you can't explain down the line.
__________________
Jun 2006 330i Manual, Active Cruise, Comfort Access, Nav prof, Voice, Bluetooth
|
Appreciate
0
|
10-30-2008, 01:31 PM | #6 |
Private First Class
6
Rep 173
Posts |
Some comments on your data.
I like the histogram idea- great! It is quite possible that using the window would "wake-up" some other traffic later on. What you are seeing is traffic before the expected window commands - We'll perhaps the first set of packets are the instruction from the button and the 0FA is the instruction to the motor (cant remember how the motors are controlled) or an acknowledgement of where the window is and the anti-trap mechanism? What do you think?
__________________
Jun 2006 330i Manual, Active Cruise, Comfort Access, Nav prof, Voice, Bluetooth
|
Appreciate
0
|
10-30-2008, 02:30 PM | #7 | |
.
42
Rep 867
Posts |
Quote:
I think I am just being paranoid about the missed CAN packets. I think Im just having a bit of trouble sorting out the communication protocol relationship between the FRM and the sensors. Last edited by HighVoltage; 10-30-2008 at 03:11 PM.. |
|
Appreciate
0
|
10-30-2008, 03:04 PM | #8 | |
.
42
Rep 867
Posts |
Quote:
I think the <0Bx> CAN ID packet data is some relative position of the window motor which the FRM uses to gauge sending additional <0Fx> commands to keep the window moving or react to a problem like pinching. Something like this occurs: 1) You physcially push the button. This sends a <0Bx> from the window motor/sensor to report the current position of the window to the FRM. 2) The FRM then sends the <0Fx> to move the motor in the *intended direction according to the button press. 3) The window moves a small fixed distance (looks like 2-3in) and reports the new motor position. 4) The FRM then decides if this is enough based on the total track position of the window and what the user did or is may be currently doing (like if the user is still holding the button). *What doesnt work in this theory is how the FRM would know in which direction the button was pushed. I dont see that data in the <0Bx> but I could be wrong. Maybe it is an additional CANID that I havent identified. Although this would be strange as I can issue a window up/down with the <0Fx>. Im definately missing something... Its just odd because the testing I did on the main cabin lights showed that the switch would constantly throw out the <1E3> F1 FF packets so long as you held the switch in. After you released it would only throw the one <1E3> F0 FF. This seemed consistant with how I would think one would implement and interface a button. Im also assuming there are no other wires to the FRM from the buttons other than the CANH/CANL pair. |
|
Appreciate
0
|
10-31-2008, 11:38 AM | #9 |
Private First Class
6
Rep 173
Posts |
On the E46 many functions actually work through the ZKE. The ZKE actually contained all the transistors that switched the motors, etc so many functions did not appear on CAN.
Another important note is that THE MESSAGE in CAN contains an ID. It actually does not have anything to do with the origin or destination of the message. Any control unit can place any message on the bus. So there is for example a speed message with ID ABC from the speed sensor. If the speed sensor would fail, a limp mode could possibly use the ABS sensor to put the same speed message on the bus. I am sure you know this but for the sake of other readers let me elaborate. In CAN there are MASKS setup in the control units. And only messages complying with those masks are handled by the CAN controller. So the unit will physically not know of any other messages. The MASK represent the TYPE/OR CLASS of message that it is interested in. It is possible to implement CAN messages in such a way that all messages between control unit 1 and 2 contain the same ID. So 2 units can happily communicate with each other using only one ID. Coincidently it may happen or be decided that all messages from the ECU are put on the bus with the same ID This is quite important as bus arbitration lets the lower IDs take priority over higher ID's. The nice thing here is that lower ID MESSAGES are more important regardless of which control unit post the message on the bus. This is where CAN is completely different to USB & Ethernet. I am going to attempt to get some documented message ID's, otherwise we will have to figure out what address means what message. If you want to do that is to try and explain ALL ID's. In other word isolate one ID and then play with everything in the car and see which devices trigger that message to appear on the bus. Then take the next ID and repeat the process.
__________________
Jun 2006 330i Manual, Active Cruise, Comfort Access, Nav prof, Voice, Bluetooth
|
Appreciate
1
808AWD325xi524.00 |
10-31-2008, 11:15 PM | #10 |
.
42
Rep 867
Posts |
I think there are few things that need to be clarified on this KCAN:
1)I dont know if KCAN is utilizing some standard protocol I am not familiar with or if it is propretiary. 2)Is this purely a Master/Slave protocol or is there some peer-to-peer communications? 3)Something to consider when looking at the data field in the frame of the KCAN packet is the Endianess. I'm not entirely sure if they are using big or little in this case. Ok, lets add some more for those who havent already nodded off: There are some aspects mentioned in the previous reply that are typical of how most protocols use the CAN bus identifier (CAN ID) but we should be cautious in assuming that is what BMW has done here. They may not have implemented any form of message "typing" or classification within the CAN ID. The CAN ID can contain information concerning direction (Master/Slave or TX/RX) but its left up to the protocol. I know Honeywell's old SDS protocol uses the most significant bit (MSB) for precisely this function and I believe CANopen does as well (havent worked with this one much), although a protocol like DeviceNet however does not. Although it is possible for multiple nodes on a bus to use the same CAN ID, the one consistency throughout most CAN protocols is to define some bits in the CAN ID as a means to specify a unique address for all the nodes on the bus. This generally simplifies the hardware requirements (i.e processing power) necessary to process through the traffic on the bus, which in turn keeps the manufacturing costs down. In this case a global mask on the node's CAN controller is typically configured relative to that nodes "address" to filter out traffic that it is not interested in. As most protocols do use message classification, CAN controllers also typcially have a group of message boxes with their own programmable masks to simplify handling. |
Appreciate
0
|
11-05-2008, 01:17 PM | #11 |
Private First Class
6
Rep 173
Posts |
Yes you're correct - we can not confirm anything.
I have some experience with some control units in cars of which one is in the E90 and others in Audi and so on, but I've also seen some strange stuff - so we will only know how it works when we know. As far as the ID's are concerned: you are right as well there are some control units that have ID's assigned to them. There are also as you mention ID-groups assigned to devices. Going through some of the E90 docs I notice a mix of both approaches. The messaging is described as "data is put on the bus and ID describes the type of data". This means the data format is consistent with the ID. However when functionality is described it says Unit1->(msg a)->Unit 3->(msg b)->Unit 4->(msg c)->Unit1 We'll in summary I'm also guessing :-) I'll be getting some more info in 2wks time, perhaps that helps.
__________________
Jun 2006 330i Manual, Active Cruise, Comfort Access, Nav prof, Voice, Bluetooth
|
Appreciate
0
|
12-22-2008, 02:40 AM | #12 |
Private First Class
3
Rep 113
Posts |
I have seached such topic for couple of days. This thread is very useful. I plan to install a carputer in my E90 and integrate the car control with the PC in two ways :
1)Interpret the action request by reading CAN-BUS. For example, carputer sense it when driver push the steering wheel button. 2)Control the car by putting packets on CAN-BUS. For exmple, carputer adjust the car temprature(climate control via carputer). So how to read and write the data from/to CAN-BUS? I found a website, it seems the CANUSB can do it(http://www.canusb.com/). Furthermore, I am not sure who gen the packet data when push the button, is it the button self or some control componment? Do you think the Fusion Brain (www.mp3car.com) can control the car in another way? seems it only sense the voltage. Since there are lots of packet(voltage changes) on the bus, it seems that fusion brain can not handle. Need your advice! |
Appreciate
0
|
12-25-2008, 02:10 AM | #14 | |
.
42
Rep 867
Posts |
Quote:
As far as what is generating the packets, well that is still in discussion. Im going to try to get back to this just a little next week but may not get to this till sometime in January. A project at work has been consuming most of my time to explore this stuff til after the first of the year. |
|
Appreciate
0
|
12-25-2008, 08:23 PM | #15 | |
Private First Class
3
Rep 113
Posts |
Quote:
What I am interesting in is 'steering wheel button and climate control'. Now I have ordered a CANBUS transciever (ValueCAN3 from http://www.intrepidcs.com) and try to parse the packet. They also have a software called 'Vechile Spy 3' for reverse engineering, but it's too expense for me. Can you give some pics to explain how to tap into the KCAN? Thanks in advance! |
|
Appreciate
0
|
12-29-2008, 04:12 PM | #16 | |
.
42
Rep 867
Posts |
Quote:
|
|
Appreciate
0
|
12-29-2008, 04:19 PM | #17 |
.
42
Rep 867
Posts |
I found out what is going on with the window controls. I completely forgot all about the LIN-bus...
(pg 69 - E90 GENERAL VEHICLE ELECTRICAL.pdf) "1. The signal is routed via the LIN-bus to the footwell module when the power window switch for the window in the driver's door or front passenger's door is operated. The footwell module drives the corresponding power window motor. 2. The signal is routed from the driver's door switch cluster via the LIN-bus to the footwell module when the power window switches for the windows in the rear doors are operated. The FRM sends the signal via the K-CAN to the JBE. On receiving the signal, the Junction Box Electronics Control Module activates the corresponding power window motor." So simply(?) its: Switch -> LINBUS -> FRM -> KCAN -> JBE -> KCAN -> Window motor |
Appreciate
0
|
12-30-2008, 01:04 AM | #18 |
Private First Class
3
Rep 113
Posts |
Oh, yes. It should belong to SZL module. The SZL is on F-BUS (see the pic you posted at first floor). But since the RAD2 response the command of wheel buttons, the control packet should also be on K-CAN, right? Maybe forward by JBE.
Last edited by efunroom; 01-07-2009 at 12:11 AM.. |
Appreciate
0
|
01-07-2009, 12:27 AM | #19 |
Private First Class
3
Rep 113
Posts |
"The functions of the Steering Column Switch Cluster (SZL) are ... Detecting the controls in the multifunction steering wheel (MFL)" (pg 44 - E90 GENERAL VEHICLE ELECTRICAL II.pdf)
-- MFL packets was produced by SZL "The Junction Box Electronics Control Module (JBE) serves as: Gateway Module for vehicle Bus System (provides a pass-through function for F-CAN)" (pg 10 - E90 GENERAL VEHICLE ELECTRICAL.pdf) -- JBE does not forward the F-CAN packets directly, only pass-through "The DSC control module is connected via the F-CAN to the SZL and serves as the gateway for the SZL, allowing data from the SZL to be distributed to the other control modules." (pg 44 - E90 GENERAL VEHICLE ELECTRICAL II.pdf) -- DSC is the gateway between F-CAN and PT-CAN Then, how Radio(RAD2) get the MFL commands? A possible way is : MFL Push --> SZL --> F-CAN --> DSC --> PT-CAN --> JBE --> K-CAN --> RAD2 I noticed that there is a direct link between PT-CAN and FRM. What is for? No BUS type info in the legend Last edited by efunroom; 01-07-2009 at 12:44 AM.. |
Appreciate
0
|
01-07-2009, 12:40 AM | #20 |
Private First Class
6
Rep 173
Posts |
>I noticed that there is a direct link between PT-CAN and FRM. What is for? No BUS type info in the legend
I think the wipers are physically on the FRM, but the PT-CAN requires information about the rain sensor in order to use the ABS system to keep the discs clean in whet weather. Does that make sense?
__________________
Jun 2006 330i Manual, Active Cruise, Comfort Access, Nav prof, Voice, Bluetooth
|
Appreciate
0
|
01-07-2009, 01:13 AM | #21 | |
Private First Class
3
Rep 113
Posts |
Quote:
I got a little confused about the direct link since it come from PT-CAN not any control unit. Anyway, my final goal is to get the MFL packet pattern, don't care who forward these packets (JBE or FRM). |
|
Appreciate
0
|
01-07-2009, 01:27 AM | #22 |
Private First Class
3
Rep 113
Posts |
That link should be PT-CAN. Maybe the overview diagram has a typo erro. FRM is the gateway for LIN-BUS, K-CAN, PT-CAN. Not sure who forward the MLF packets (FRM or JBE)
In addition, the diagram above is applied for E9x after 2007/03. Early model has not PT-CAN pins on FRM. |
Appreciate
0
|
Bookmarks |
|
|