E90Post
 


ECS BMW
 
BMW 3-Series (E90 E92) Forum > E90 / E92 / E93 3-series Technical Forums > BMW Coding > E9x KCAN 101



Reply
 
Thread Tools Search this Thread
      10-09-2008, 10:46 PM   #1
HighVoltage
.
United_States
13

 
HighVoltage's Avatar
 
Drives: 07 E90 335i
Join Date: Aug 2008
Location: .


Posts: 867
iTrader: (0)

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
You have to wait to recv the rsp before issuing the 2nd cmd otherwise the light will force itself back off after ~1 second.
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
General Notes:

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
Each window will return a response to a command. They are listed as follows:
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.
I believe the the last byte is a diagnostic byte used to determine the motor temperature. I will have to test to verify. Here is an excerpt on the thermal protection:

"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.
Attached Images
   

Last edited by HighVoltage; 02-17-2009 at 03:48 PM.
Appreciate 0
      10-26-2008, 02:03 PM   #2
glamprecht
Private First Class
4

 
glamprecht's Avatar
 
Drives: June 2006 330i manual
Join Date: Jun 2006
Location: South Africa


Posts: 167
iTrader: (0)

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, 01:21 AM   #3
JoeyFiasco
Major
20

 
JoeyFiasco's Avatar
 
Drives: '09 Coupe
Join Date: Aug 2008
Location: P'boro, UK


Posts: 1,211
iTrader: (0)

great work voltage
Appreciate 0
      10-30-2008, 09:26 AM   #4
HighVoltage
.
United_States
13

 
HighVoltage's Avatar
 
Drives: 07 E90 335i
Join Date: Aug 2008
Location: .


Posts: 867
iTrader: (0)

Quote:
Originally Posted by glamprecht View Post
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.
Ive tried correlating the data portion of the ibus packets to the kbus and so far I have not seen any relationship. Im going to try to fully flush out the drivers side door this weekend.

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...
Attached Images
  
Appreciate 0
      10-30-2008, 01:29 PM   #5
glamprecht
Private First Class
4

 
glamprecht's Avatar
 
Drives: June 2006 330i manual
Join Date: Jun 2006
Location: South Africa


Posts: 167
iTrader: (0)

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
glamprecht
Private First Class
4

 
glamprecht's Avatar
 
Drives: June 2006 330i manual
Join Date: Jun 2006
Location: South Africa


Posts: 167
iTrader: (0)

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
HighVoltage
.
United_States
13

 
HighVoltage's Avatar
 
Drives: 07 E90 335i
Join Date: Aug 2008
Location: .


Posts: 867
iTrader: (0)

Quote:
Originally Posted by glamprecht View Post
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.
I'm not using a dongle. Im using a product I designed a few years ago. Its is an Ethernet to CAN gateway. It is based on the Motorola MCF5282CVF66 and its FlexCan interface. If there are any missed CAN packets it is at the (new for this E90 stuff) application layer in my code and not at the driver though. We've done extensive testing with this driver and there are no issues at least up to 500K and scan rates down to a 1ms.

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
HighVoltage
.
United_States
13

 
HighVoltage's Avatar
 
Drives: 07 E90 335i
Join Date: Aug 2008
Location: .


Posts: 867
iTrader: (0)

Quote:
Originally Posted by glamprecht View Post
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?
To be clear, that log is suppose to be a capture of 25 packets before and 25 packets after the 0FA was captured. Thats all the traffic on the bus at the particular time. So there is going to be traffic mixed in that log that has nothing to do with the windows. I have an option to filter out packets from the log with user specified CAN IDs that I did not use for that log. So for instance I could have filtered out all CAN IDs that were not <0FA> or <0B6>.

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
glamprecht
Private First Class
4

 
glamprecht's Avatar
 
Drives: June 2006 330i manual
Join Date: Jun 2006
Location: South Africa


Posts: 167
iTrader: (0)

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 0
      10-31-2008, 11:15 PM   #10
HighVoltage
.
United_States
13

 
HighVoltage's Avatar
 
Drives: 07 E90 335i
Join Date: Aug 2008
Location: .


Posts: 867
iTrader: (0)

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, 02:17 PM   #11
glamprecht
Private First Class
4

 
glamprecht's Avatar
 
Drives: June 2006 330i manual
Join Date: Jun 2006
Location: South Africa


Posts: 167
iTrader: (0)

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, 03:40 AM   #12
efunroom
Private First Class
3

 
Drives: E90 325
Join Date: Jan 2008
Location: China


Posts: 113
iTrader: (0)

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-22-2008, 09:30 PM   #13
LateralG
First Lieutenant
Taiwan
8

 
Drives: M54E46
Join Date: Jul 2006
Location: Shanghai


Posts: 324
iTrader: (0)

.... so "advanced"... what are you guys trying to do here? E90 transformer?
Appreciate 0
      12-25-2008, 03:10 AM   #14
HighVoltage
.
United_States
13

 
HighVoltage's Avatar
 
Drives: 07 E90 335i
Join Date: Aug 2008
Location: .


Posts: 867
iTrader: (0)

Quote:
Originally Posted by efunroom View Post
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!
The Fusion Brain is not capable of CAN BUS communications. Its just a simple Digital + Analog I/O card. You must have something that contains a CANBUS transciever and CAN controller.

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, 09:23 PM   #15
efunroom
Private First Class
3

 
Drives: E90 325
Join Date: Jan 2008
Location: China


Posts: 113
iTrader: (0)

Quote:
Originally Posted by HighVoltage View Post
The Fusion Brain is not capable of CAN BUS communications. Its just a simple Digital + Analog I/O card. You must have something that contains a CANBUS transciever and CAN controller.

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.
Thanks for your answer.

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, 05:12 PM   #16
HighVoltage
.
United_States
13

 
HighVoltage's Avatar
 
Drives: 07 E90 335i
Join Date: Aug 2008
Location: .


Posts: 867
iTrader: (0)

Quote:
Originally Posted by efunroom View Post
Thanks for your answer.

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!
Im not sure you are going to gain access to the steering wheel buttons via K-CAN Those may be on F-CAN.
Appreciate 0
      12-29-2008, 05:19 PM   #17
HighVoltage
.
United_States
13

 
HighVoltage's Avatar
 
Drives: 07 E90 335i
Join Date: Aug 2008
Location: .


Posts: 867
iTrader: (0)

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, 02:04 AM   #18
efunroom
Private First Class
3

 
Drives: E90 325
Join Date: Jan 2008
Location: China


Posts: 113
iTrader: (0)

Quote:
Originally Posted by HighVoltage View Post
Im not sure you are going to gain access to the steering wheel buttons via K-CAN Those may be on F-CAN.
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 01:11 AM.
Appreciate 0
      01-07-2009, 01:27 AM   #19
efunroom
Private First Class
3

 
Drives: E90 325
Join Date: Jan 2008
Location: China


Posts: 113
iTrader: (0)

"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 01:44 AM.
Appreciate 0
      01-07-2009, 01:40 AM   #20
glamprecht
Private First Class
4

 
glamprecht's Avatar
 
Drives: June 2006 330i manual
Join Date: Jun 2006
Location: South Africa


Posts: 167
iTrader: (0)

>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, 02:13 AM   #21
efunroom
Private First Class
3

 
Drives: E90 325
Join Date: Jan 2008
Location: China


Posts: 113
iTrader: (0)

Quote:
Originally Posted by glamprecht View Post
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?
Seems FRM does not involved in Wiper/Washer System (Chpater: Wiper/Washer System). Rain sensor signal produced by RLS, then was sent to K-CAN by FZD. JBE take it as one input. Another input is speed which sent by DSC via PT-CAN. As for the command (wiper steering column stalk), it was sent to F-CAN by SZL, then foward to PT-CAN by DSC. JBE finally received this command.

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, 02:27 AM   #22
efunroom
Private First Class
3

 
Drives: E90 325
Join Date: Jan 2008
Location: China


Posts: 113
iTrader: (0)

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
Reply

Bookmarks

Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump


All times are GMT -5. The time now is 03:16 AM.




e90post
Powered by vBulletin® Version 3.7.0
Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
1Addicts.com, BIMMERPOST.com, E90Post.com, F30Post.com, M3Post.com, ZPost.com, 5Post.com, 6Post.com, 7Post.com, XBimmers.com logo and trademark are properties of BIMMERPOST