E46 Can bus project.

[Thaniel]

Yah a bench test setup is the way to go. Mine keeps growing. I keep adding more of the car modules to it as I want to try different things.

[Zandr]

As it turns out, VW developed a great CAN API for Linux (SocketCAN) that extends the common application level network API (Berkeley sockets). You can send packets from the command line as well as sniff traffic without having to write code (although the C API is familiar to anyone who's had to do any networking type stuff).

This sounds alarmingly like you could decode a CAN datastream in Wireshark.

[TerraPhantm]

Ok TerraPhantm, I need your detective work again.

It seems that Byte 0 of 0x329 is the key to making the DSC happy, unfortunately - the byte we know least about.

I've narrowed it down to the fact that the rolling counter does not start until the IKE comes online.

I have isolated the DME onto it's own bus on the Motec, and the Motec is outputting 0x316, 0x329, and 0x545 onto the main bus.
I put a "debug" flag onto the transmit function that I could turn on and off for bytes I thought might be a problem. If the flag is on, I just copy the bytes from the DME bus to the main and transmission buses. With the debug flag off for all of the bytes, my rolling code algorithm isn't good enough to make the DSC happy. I turned them all on except for byte 0, and still no go. I cycled the ignition, still no go. Finally I turned on the debug flag for byte 0, and the DSC symbol went away. I turned the rest of the flags to off, and everything continued to work after another ignition cycle. Within 3 seconds of putting byte 0 back to my algorithm, the DSC light turned on.

So, byte 0 is definitely important. Hopefully you can shed some light as to what on earth it's really for.

-Matt

Okay so I took a closer look at this since I finally got a CAN interface.

On my DME, that byte 0 constantly cycles between 0x11, 0x40, 0x80, and 0xDF. It looks like that 4th value is what can vary from engine to engine. On the MSS54, that 4th value is determined by ORing 0xC0 with a variable BMW calls "md_norm_can" which is taken directly from scalar called "K_MD_NORM" which is set to 0x1F on my DME. The math works out -- 0x1F OR 0xC0 = 0xDF.

According to the funktionsrahmen, K_MD_NORM is the "Standard Torque for CAN" (and for whatever it's worth, the pdf defines "md_norm_can" as "Normalization reference for torque interface"). According to the MSS54 damos, the conversion is 16*x. So 0x1F (31) would equal 496 Nm. 496Nm is quite a bit more torque than the S54 produces. So I don't know if BMW just coded it so that DSC is more aggressive than "necessary" for the amount of torque the S54 makes, or if the "reference" torque refers to something other than the engine's peak torque.

In an earlier post you mentioned that the 4th value in your sequence is 217 or 0xD9. If the formula is the same as in the MSS54, that suggests your reference torque is set to 0x19 (25), which would equal 400Nm.

There is the possibility that the formula in the MSS54 A2L is wrong. If you multiply by 12 instead of by 16, those reference torque values are near identical to engine torque in Nm. M54b30 makes 300Nm torque; 25*12 = 300. S54 makes 365Nm torque, 31*12 = 372.

S62 is pretty far off no matter how you slice it. The value is set to 0x32 (50). 50 * 16 = 800Nm, 50 * 12 = 600Nm. Actual torque is 500Nm. I have heard people say that the DSC on the M5 is ridiculously intrusive however.

[mdrobnak]

That's some great information.

I think you are correct that the scaling formula might be incorrect. I wonder if those are the values used in the 0x316 torque bytes. (Bytes 1,4,5,7 starting the count from 0). I think Thaniel was the one that originally suggested they were torque bytes and I thought he was crazy at the time. But it definitely makes sense. Byte 1 seems to be 'reality' - as when the injectors are off (overrun), the value is 0. Byte 4 is 'ideal'? The value always seems to eventually meet up with this value. I think Byte 7 is with torque reductions taken into account. I know you mentioned something about these earlier...need to look back at old posts.

I may come up with some simple tables to be able to calibrate these items on the Motec. Looks like there's no simple formulas for these items.

Also, 0x80 seems to turn into 0x84 for me once the engine is running. Is your byte 0 data from just engine stopped, or engine running as well?

-Matt

[TerraPhantm]

Mine was with the engine stopped, but in this DME, 0x11, 0x40, and 0x80 appear to be hard coded. I'll confirm whether or not that's truly the case tonight.

0x316:
byte 1 is "md_ind_ne_ist" -- which according to my pdfs is "produced indexed actual torque of the engine under consideration of all interventions" (google translate). Seems like "reality" is a pretty accurate description
byte 4 is "md_ind_ist" -- "produced indexed actual torque of the engine without taking into account the DSC intervention"
byte 5 is "md_reib" -- "Torque loss of the motor incl. All consumers (alternator, oil pump, air compressor, ...)"
byte 7 is "md_ind_lm_ist" -- "theoretical engine torque calculated from the measured air mass excluding external ignition angle"

Also interestingly, bit 2 (starting at 0) of byte 6 is set if the sport button is pressed

[mdrobnak]

Ah, so byte 7 can be calculated. Good. Now just to figure out the scaling of all of this. It's definitely not 12x because that would be ~300 N*m of torque loss at idle. (25 decimal * 12..).

Byte 6 of either 316 also has an interaction with the transmission controller after a shift is completed. No idea of the purpose. Value of 0x80 .5 seconds after shift completion for 0.1 seconds. :: shrug ::

-Matt

[Thaniel]

0x316
My guesses are:
B1 - Indicated Engine torque without intervention (%)
B4 - Standard Torque output (Nm)
B5 - Torque consumed by friction (%)
B7 - Indicated Engine torque during Intervention (%)

0x316:
byte 1 is "md_ind_ne_ist" -- which according to my pdfs is "produced indexed actual torque of the engine under consideration of all interventions" (google translate). Seems like "reality" is a pretty accurate description
byte 4 is "md_ind_ist" -- "produced indexed actual torque of the engine without taking into account the DSC intervention"
byte 5 is "md_ind_reib" -- "Torque loss of the motor incl. All consumers (alternator, oil pump, air compressor, ...)"
byte 7 is "md_ind_lm_ist" -- "theoretical engine torque calculated from the measured air mass excluding external ignition angle"

Seems my guesses weren't all that far off. The difficulty with this data message, I think, is validating the results. Any ideas?

[TerraPhantm]

From what I'm seeing, the formulas are

0.1*x for MD_IND_NE (unit = Nm)
0.390625 * x for MD_IND_NE_IST, md_reib, and md_ind_lm_ist (unit = %)

[loftygoals]

Are you certain that the TQ figure is at the crank? I know on the MINI R53, which also uses a Siemens ECU and MK60 ABS, many of the Torque Management calculations are at the wheels. It uses the gear ratios specified to calculate torque at the wheels. This is why DSC behaves differently in 1st gear vs. 5th gear, because the torque at the wheels is massively reduced in 5th vs. 1st.

-bj

[TerraPhantm]

At least for the E46 M3, the torque that's broadcast is at the crank. Documentation specifically indicates it is the torque that is applied to the clutch. The DME does know the gear ratios internally, and DSC could probably figure out the effective ratio since it knows wheel diameter, rpm, and speed.

[loftygoals]

Documentation specifically indicates it is the torque that is applied to the clutch.

How much of the Funktionsrahmen Documentation have you read? I have it as I was a part of p0lar's group that obtained it, but I've only gone through a few chunks. I bet at a minimum you are getting pretty good at reading German!

-bj

[TerraPhantm]

How much of the Funktionsrahmen Documentation have you read? I have it as I was a part of p0lar's group that obtained it, but I've only gone through a few chunks. I bet at a minimum you are getting pretty good at reading German!

-bj

I've skimmed through most of it. Spent a bit more time reading the torque management pdf, but it's a hard read even if it were in English. My native German friends have a hard time with it too. It does make understanding the assembly significantly easier (though there are parts that seem outdated)

[Thaniel]

Hello All. Had a EUREKA moment this week and long story short were able to simulate the ECU close enough the ABS and traction control lights went out . The ABS/DSC no longer shows any Can errors. It does still show engine torque not adjustable. I think I've seen that on my stock cars from time to time. And it doesn't appear to keep the light on. So progress. What did we do different?

My son had Monday off and I had to work. While I worked he data collected and compared samples of can data from our bench test set up. Comparing several data streams from key off to on of ECU and IKE only and also ECU IKE and DSC. In doing that we discovered that the DME timing and sequencing on the messages it sends are differently than we previously thought. Originally we couldn't quite understand what dictated the time between messages. The times would vary from 10 milliseconds to 100+ milliseconds. What we found was that the DME tries to send all 3 ARBID's 0x316, 0x329 and 0x545 at more or less the same time every 10 milliseconds. And which Messages get out on the bus and which are skipped are a result of arbitration with the other modules. This causes the irregular and random looking intervals. When the ECU and IKE were the only things on the bus the messages came at very regular intervals and rarely was there a "missed" message (the few missed messages seemed to from arbitration with the DME's own messages). With the DSC in play, which has a lower ARBID, many more ECU messages were missing from the bus. When in the car there are even more missed messages as there are more modules competing for the bus. Which also made this phenomenon less obvious. The bench test setup is paying off already :-)

Garrett reworks our can bus programs to send the E46 messages in "one shot" mode. Uses 3 registers in the MCP chips, one for each ARBID and then has them attempt to send every 10 milliseconds (the measured interval from the DME). And VOILA. Our simulated data stream for the first 100 or so messages exactly matches the DME's data stream. Time to try it in a car. We put it in our project car (complete car less motor) and we are pleased to see that the ABS and traction control lights do go off (car stationary RPM being sent). Some Progress I think

We will fiddle around with it more to see which bytes are necessary and which are not. For now we are just mimicking what we see the DME do on some of the less understood bytes.

Ok TerraPhantm, I need your detective work again.

It seems that Byte 0 of 0x329 is the key to making the DSC happy, unfortunately - the byte we know least about.

I've narrowed it down to the fact that the rolling counter does not start until the IKE comes online.

I have isolated the DME onto it's own bus on the Motec, and the Motec is outputting 0x316, 0x329, and 0x545 onto the main bus.
I put a "debug" flag onto the transmit function that I could turn on and off for bytes I thought might be a problem. If the flag is on, I just copy the bytes from the DME bus to the main and transmission buses. With the debug flag off for all of the bytes, my rolling code algorithm isn't good enough to make the DSC happy. I turned them all on except for byte 0, and still no go. I cycled the ignition, still no go. Finally I turned on the debug flag for byte 0, and the DSC symbol went away. I turned the rest of the flags to off, and everything continued to work after another ignition cycle. Within 3 seconds of putting byte 0 back to my algorithm, the DSC light turned on.

So, byte 0 is definitely important. Hopefully you can shed some light as to what on earth it's really for.

-Matt

Hey Matt. Did you get this to work? Perhaps with what we found we can get it working? 329 byte zero sends the repeated messages. Each value the same number of times at 10 millisecond intervals. If a message doesn't get out on the bus it doesn't retry but keeps going with the pattern and tries the next one in the pattern at the next 10 milliseconds. There was one other strange moving byte we were emulating (think it was 316 B7). Not sure it was important or not. Will try without that one later.

For 0x316 byte 0

Bit 0 - Something is pushed here, but I'm having a hard time tracing what it is. Appears it would always be set to 1 if everything is running normally
Bit 1 - Unused (in this DME)
Bit 2 - Set to 0 if ASC/DSC error, 1 otherwise
Bit 3 - Set to 0 if manual, Set to 1 if SMG (on this DME, I guess MS45 is different)
Bit 4 - Set to bit 0 of md_st_eingriff (torque intervention status)
Bit 5 - Set to bit 1 of md_st_eingriff
Bit 6 - Set to 1 AC engaged
Bit 7 - Set to 1 if MAF error


In this DME, it appears 0x329 byte 0 could be 0x11(17), 0x40(64), 0x80(128), or 0xC0(192). Doesn't appear to be based on anything more than DME running time, but I could be wrong

Got to say TerraPhantm. I finally dug into some of the data you've been posting. Good stuff.

Thaniel

[mdrobnak]

Nice work, Thaniel.

So it turns out that my initial calculation of the byte 0 messages was wrong in terms of duration, which is why it was busted. I was cycling through the values way too fast. I think given TerraPhantm's info, I can replace the DME now.

However, I think the scaling of all the values is simply 0.1 * x...because bytes 1,4,7 are all the same value for me a large percentage of the time, so they're not just % based. I will be doing some data collection and trying to replace the DME data with values from a table soon.

-Matt

[Thaniel]

Nice work, Thaniel.

So it turns out that my initial calculation of the byte 0 messages was wrong in terms of duration, which is why it was busted. I was cycling through the values way too fast. I think given TerraPhantm's info, I can replace the DME now.

However, I think the scaling of all the values is simply 0.1 * x...because bytes 1,4,7 are all the same value for me a large percentage of the time, so they're not just % based. I will be doing some data collection and trying to replace the DME data with values from a table soon.

-Matt

Glad you are able to get it to work.

Pretty confident in the scaling factors. At least % vs Nm. I read some documents, probably similar to TerraPhantms (but in english) and I think we have it correct. Yah on the data I have Byte 1 and Byte 7 are identical. I'm thinking they are only different WHEN torque reduction is happening. THe frictional torque I did some calculations on and it looked like it was correct. I need to go through what I did again and double check it. I'd also get my bench test DSC happy enough to similalte some various traction conditions while monitoring. But might be easier to just monitor the complete car while spinning the tires :-)

Thaniel.

[evsparker]

Been following for some time now. Can't tell you how helpful it has been for my project, electric conversion of an E85. Has any one seen any odometer messages?

[Thaniel]

Been following for some time now. Can't tell you how helpful it has been for my project, electric conversion of an E85. Has any one seen any odometer messages?

Yup. From page 1 of the thread..... :-)
ARBID: 0x613 also sent from the instrument cluster if 0x615 is acknowleged.
-B0 Odometer LSB
-B1 Odometer MSB [Convert from Hex to Decimal. Multiply by 10 and that is Odometer in Km]

[evsparker]

this doesn't work out for me, as 1 bit equals about 6 miles.
from ARBID 0x613
LSB is 0x51
MSB is 0x34

133930 KM or 83,220.2 miles

when
LSB is 0x52
MSB is 0x34

133940 KM or 83,226.4 miles

what am i missing?

[Thaniel]

this doesn't work out for me, as 1 bit equals about 6 miles.
from ARBID 0x613
LSB is 0x51
MSB is 0x34

133930 KM or 83,220.2 miles

when
LSB is 0x52
MSB is 0x34

133940 KM or 83,226.4 miles

what am i missing?

if that matches your mileage on the instrument cluster than you aren't missing anything. Just means the resolution of the value on the can bus is 10km (6 miles).

[evsparker]

so does that mean that the display is generating the odometer value via maybe the speed, and then only putting out a odometer value in 6 mile increments? was hoping for more resolution.
Reason for this is that I have a different display panel and have lost the mileage values. Everything else is available due to your fine work.

[TerraPhantm]

The cluster calculates distance traveled based on the wheel speed sensors and stores it in 1km increments. I guess it broadcasts the mileage to other units in 10km increments

On another note - Thaniel, have you messed with 2006+ Z4s at all? I've always been tempted to grab the MK60e5 module from that car and use it in the E46 since the wiring and hydraulics match. I'm not sure whether or not they changed the CAN signals at all. Always thought it'd be cool to have some of the newer functions (brake wiping and hill hold for example)

[e36 323ti]

Thanks a lot for the good work and willingness to share! Even though being a newb, I thought I could share my story/exprience/questions:

My config is based on the Raspberry Pi 2 (RPi2). To the RPi2 I have attached a PiCAN CAN-module and an USB2OBD FTDI-based dongle (4 usb ports on the RPi2). My "test bench" is for the time being a std e46 MK60 and a std e46 m3 MK60 (and my BMWs). The PiCAN module is connected to the CAN-bus on the MK60 and the USB2OBD dongle is connected to the K-bus on the MK60. The PiCAN is configured with 500kbaud and the USB2OBD by 9600 baud, 8 bit, 1 stop bit and even parity.


Figure 1: RPi2 with CAN.

For the time being I am using Wireshark and software following the PiCAN for monitorig the CAN bus, and Python towards the K-bus (and the pylibftdi library).

When powering on the MK60, it transmit ARBID 0x610 five times (see the figure below). Then it stops, and no more traffic on the CAN-bus...


Figure 2: Wireshark dump on RPi2

However, by demanding the MK60 to enter the diagnose mode and do a fault-reset by sending ('B8 29 F1 02 10 87 F5' followed by 'B8 29 F1 03 14 FF FF 77') on the K-bus, the MK60 started to transmit ARBIDs 0x1f0, 0x1f3 and 0x153 each 7th msec (msg 6-13 in the figure above). The fault-reset could also be done by Tools32 and the 'fs_loeschen' command. The time between the CAN messages is shown in the figure below.


Figure 3: Time between CAN messages MK60

As can be seen in Figure 2, the ARBID 0x610 is not showing the VIN. The VIN stored in this MK60 is FW48531. Based on my experience with inserting a used e46 m3 MK60 in my car, I imagine that these 0x610 "boot"-messages is a part of the sequence for checking that the MK60 is initialized the proper way. At boot there is a handshake going on between the IKE (and also maybe the LEW/LWS). If this boot sequence fails, the DSC/ABS light is switched on and the MK60 throws error 5E1F. When I struggled with inserting the e46 m3 MK60 in my car, the error check resulted in:

PA Soft Error: 5E1F[24095] PT-CAN chassis number wrong / ECU not initialized.
PA Soft dump-file Error: ABS* -> 5E1F/E0 - PT-CAN chassis number wrong / ECU not initialized.
INPA Error: 5E1F - ABS/ASC/DSC: VIN not initialized, execute LWS calibration
DIS/GT1 Error: 5E1F ABS-DSC: Vehicle identificaton number different

However, by using INPA 4.4.7 and the LEW/LWS calibration procedure (<Shift-F4>) or the Tools32/ DSC_MK60/ lenkwinkel_dsc_abgleichen the MK60 was aligned with the IKE (and LEW/LWS), and the DSC/ABS light in the IKE was switched off. According to my knowledge, the lenkwinkel_dsc_abgleichen procedure request VIN and km from the IKE and "programs" these data into the MK60. I guess that also some interaction with the LEW/LWS is going on.

Also shown in Figure 2 above, there are two different 0x610 messages. Maybe one goes to the IKE an one to the LEW/LWS? If anyone having a test bench with IKE, MK60 and LEW/LWS they could probably confirm/unconfirm this...

[drukhadze]

In Figure 2 I see 5 identical 0x610 messages. Yes, the Data-area looks different, but this are RTR messages and data does not matter. An RTR (Remote Transfer Request , Remote Frame) message has no data area. Even If data is set, it should be ignored.
In the normal case, there are only 2 0x610 messages in sequence. RTR, which appears to come from DSC and other is Reply from IKE as STD (Standard frame) Message with VIN stored in IKE


If DSC don't get answer (0x610 STD), it sends 0x610 RTR again, up to 5 times.

[mdrobnak]

Ok, so I'm still confused on units...

Here I did a full throttle shift, and the values go to near maxes pretty much instantly...even when I highly doubt I'm making that much torque.

Ie:
tq_units.png

So I'm still very confused.

-Matt

[TerraPhantm]

This probably isn't terribly important, but now that I've got a logger setup and am able to look at the data as I play with the car, I found a couple things on message ID 615 (bolded stuff I added)

ARBID: 0x615 sent from the instrument cluster.
-B0 AC signal. Hex 80 when on (10000000) Other bits say something else (Load, Aux fan speed request? system pressure?)
-B1 4 when headlights/parking lights on
-B2
-B3 Outside Air Temperature: x being temperature in Deg C, (x>=0 deg C,DEC2HEX(x),DEC2HEX(-x)+128) x range min -40 C max 50 C
-B4 1 = Driver door open; 2 = handbrake up
-B5 2 = Left turn signal, 4 = Right turn signal, 6 = hazards

Probably some more things on there, but I can't think of anything obvious to test.