Thread: E9x KCAN 101
View Single Post
      10-30-2008, 03:04 PM   #8
HighVoltage
.
HighVoltage's Avatar
United_States
30
Rep
867
Posts

Drives: 07 E90 335i
Join Date: Aug 2008
Location: .

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