E46 Can bus project.

[Thaniel]

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)

Sorry for the slow reply. My email notifications dropped again,

Humm. I think the z4s I've messed with were 2004. I'll have to look at my records. Didn't the later z4s end up more like e90s instead of e46?

- - - Updated - - -

Bit of an update on my work. With the revised message sending strategy was able to get the dsc errors to go away even with the DME removed. See attaches pic.


And here is a short clip of key on. Haven't tried driving the car yet. As it currently doesn't drive :-)
https://m.youtube.com/watch?v=ACOkzF3axVs

[TerraPhantm]

Sorry for the slow reply. My email notifications dropped again,

Humm. I think the z4s I've messed with were 2004. I'll have to look at my records. Didn't the later z4s end up more like e90s instead of e46?

Yes and no. The vast majority of the car is still E46 like. It's only the powertrain modules that got updated. And the dsc system is unique to the z4. So I don't really know if they bothered changing the can format or not. Guess I'll have to find one to hook up to

[mdrobnak]

No additional thoughts on the scaling, guys? I can only emulate what I see at the moment, without understanding it better.

[TerraPhantm]

No additional thoughts on the scaling, guys? I can only emulate what I see at the moment, without understanding it better.

I'll try capturing some data in a few minutes and see what I come up with

[mdrobnak]

Thaniel,
I was very confused why your code was working, but the code that I had in place was not. It turns out that not only was I cycling through the values too quickly, my code had a logic error in it, and I was not actually cycling back to the first value. Now that the code is fixed up, DSC no longer throws an error for me either.

I have had limited success with the torque stuff so far.

-Matt

[Andrew Cooke]

Greetings,

I don't have a BMW, so sadly can't contribute much to your thread, but I am looking for a CAN instrument cluster that I can drive, and that's what brought me here. I've done a fair bit of embedded CAN using an 8051, and this is what I'd drive the cluster with. I'll confess to being lazy here, and only having skimmed through the thread, as to me the important bits are what I can drive over CAN, the ID's and transmission rates.

Having read your comment below I thought I'd try and contribute something:

If I'm reading it right you're suggesting that messages are getting dropped off the bus once you get a full set of modules? I've not scanned a bus myself, so can't be certain, but I doubt that's the case. CAN is pretty robust at retrying to get messages out when the bus gets busy, and as long as the bus occupancy isn't great, I forget what's sensible, maybe 30-50% for asynchronous CAN?, it'll work just fine. I doubt BMW would push the bus occupancy to the point that messages are getting dropped. 100% occupancy would be about 40 messages every 10ms at 500KHz, where are you at?. My best guess is that you're failing to receive messages fast enough and they're getting stamped on in your buffer, certainly many of the cheaper CAN-USB interfaces fail to keep up with a busy bus, this is where buffers and masks are your friends - try masking out everything but 316.

I mostly work with 1Mb CAN, anything that uses USB-RS232-CAN won't keep up, a decent USB-CAN can handle a full bus. For what it's worth I've used PCAN, Kvaser, and Softing happily.

I could be way off, but thought I'd put it out there.

keep at it, you're doing great stuff.

Andy

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.



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.



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

Thaniel

[Thaniel]

Hey Andrew. Thanks for your contribution.

all I can say is my data comes from testing actual bmw components. If it makes sense that they do it a specific way I can't say. I can only say what the modules do and how to mimick their behavior EXACTLY requires what I described. It satisfies the dsc and it gets no errors. And that satisfies me :-)

[e36 323ti]

Browsed through this thread and made a summary of what is gathered of infomation of the Arbids. Impressive work!
Regarding Arbid 0x329 Byte0: Could it be that Byte0 is mulitpurposed?
Multipurpose is used for some of the bytes in the Arbids 0x1f0, 0x1f3 and 0x1f5...

[Thaniel]

Hello All,

Another update. Updated the program running on an LS1 E46 M3. The old can message sending had the DSC and TPMS light on. With the new method, described a few posts up, the DSC and TPMS lights are off :-).....
https://youtu.be/sTicgxHjVxo

Browsed through this thread and made a summary of what is gathered of infomation of the Arbids. Impressive work!
Regarding Arbid 0x329 Byte0: Could it be that Byte0 is mulitpurposed?

Thanks for your comment and summarizing. Byte zero probably does have more than one purpose. But it seems it's main purpose is to supply a heart beat, if you will, to show the DME is on. The messages themselves might have some data in them. But the fact they don't change or vary from car to car, with few exceptions, doubt there is much interesting in there.

Thaniel

[Matt]

Browsed through this thread and made a summary of what is gathered of infomation of the Arbids. Impressive work!
Regarding Arbid 0x329 Byte0: Could it be that Byte0 is mulitpurposed?
Multipurpose is used for some of the bytes in the Arbids 0x1f0, 0x1f3 and 0x1f5...

Sounds pretty likely. If you draw out each possible byte in binary, you can see a pattern. In fact, according to a thing I have... "gemultiplextes Signal; mit Vorsicht zu genießen." MD_NORM is listed as 6 bits long and has a conversion of X*16 into Nm. Range of 0 to 1008Nm. 6 bits obviously excludes the two top bits which cycle 0-1-2-3. So it's possible that what you have is actually four different 6-bit torque values.

Looks like TerraPhantm already posted something along these lines, relating to the value that gets ORed with 0xC0. I am guessing these values tell the ASC/DSC how much control the DME can offer over engine torque. NORM is probably the value that represents 100% in the calculations based on percentage.

[mapleridge]

this is a great thread.

[mdrobnak]

this is a great thread.

Indeed.

It seems from additional data logging (and my limited translation of some German docs), that all of the torque values on 0x319 are on a 0-99.6% scale, which I assume is from the max torque value in 0x329 byte 0. My transmission is giving me some trouble at the moment, so I don't have much new data to give back at the second.

-Matt

- - - Updated - - -

Hello All,

Another update. Updated the program running on an LS1 E46 M3. The old can message sending had the DSC and TPMS light on. With the new method, described a few posts up, the DSC and TPMS lights are off :-).....
https://youtu.be/sTicgxHjVxo
...
Thaniel

Looking good, Thaniel.

[Thaniel]

Looking good, Thaniel.

Thanks. I'm happy with it myself.

Got feedback that the new sending method also makes a z4 happy enough that no dash error lights and the EPS functions.

So far I have tested this on the following cars and the DSC light stays off.:

2000 323i E46
1999 740i
E46 M3
2000 328i
2003 Z4

I'm thinking I can move on to something else. I'm thinking MPG gauge again. With the new sending method I expect control of it will work better.

Thaniel

[mapleridge]

Big things are happening. Great work.

[e36 323ti]

Got hold of an IKE from an e46 320dat. Coupled the sensor inputs to their appropriate signal levels to get rid of warning lams caused by missing sensors. Attached the IKE to the CAN-bus on my RaspberryPi2. Made me a program that simulated the CAN messages supposed to come from the DME and ABS units. The CAN-messages simulated was the 0x316, 0x329, 0x545 from the DME and the 0x1f0 and 0x153 from the abs-unit. Simulated the speed signal input to the IKE as well. Works pretty well :-)





Edit: Added the 0x43f CAN-message to cope with the transmission error symbol in the IKE:

[Thaniel]

Edit: Added the 0x43f CAN-message to cope with the transmission error symbol in the IKE:

Great work. I had wondered if you could make the trans error go off. Now we know :-)
What year is your IKE from?

[e36 323ti]

The IKE has CI 04, HW 10, prod date week 35/00. Based on the VIN in the IKE the car is prodused Sep. 2000. Seems like there is only one CAN message from the slush box (0x43f), so it should work on all IKEs for e46 with slush box. For the smg the CAN message 0x43d is also used, where the format/values varies dependent on ///M or not.

Destroyed the IKE in my attempt of having the fuel indicator showing something else than empty. Is there any hints of how to make the fuel indicator work in a bench? Based on the WDS I imagined some resistors between the terminals for the levelers would work - it didn't.

[Thaniel]

Resisters as you describe will work. However.... The fuel gauge isn't directly wired to the fuel senders. There is a computer in between. And if it sees the needle doing things that don't make sense it ignores it and moves the needle based on the fuel consumption values. Things like the tank increasing in fuel while driving. Or the needle dropping too rapidly.

[mdrobnak]

e36 323ti - Ooh. 0x43f eh? That's interesting. Only 0x43d on Magnetti Marelli non-M SSG/SMG. Do you have a breakdown of data for 0x43f and 0x43d for the M3 SMG?

Thaniel - Just take fuel injected values % 65535 (in uL) and you're golden. The MPG gauge will work fine, but I'm not sure if that requires correct ABS data.

[Thaniel]

Before when we messed with the mpg needle we didn't need the abs messages. Our only trouble was the needle would wobble. Looking back I'm sure that had to do with the sending method. As spacing between the messages affected the values. With the more accurate sending method I anticipate it'll work perfect.

Actually sent a module out that includes mpg function. Will see how it turns out once the owner hooks it up.

Thaniel

[mdrobnak]

Ah. I noted that the data from the DME seems to be a little bit 'smoothed' compared to what I got from the M1, but it was not too different. It was probably the sending method, as you theorize.

-Matt

[joekitch]

just as a general question (having not read the entire thread so far); would it be possible to have an arduino send commands directly down the can bus to do simple things like turn the fan speed on max + lower the windows + crack open the sunroof?

i'm looking into making a ventilation mode which activates if the sun is out (not raining or cloudy), its above a certain temperature inside the cabin, and the battery is above a certain voltage (when it drops below that voltage the fan cuts off but the windows stay slightly open)

the alternative is to have the arduino use a servo to just hold down the unlock button on a dummy remote keyfob until the windows pop, then lock the car again

edit: im referring to the e39 specifically, by the way

[Thaniel]

would it be possible to have an arduino send commands directly down the can bus to do simple things like turn the fan speed on max + lower the windows + crack open the sunroof?

Yes but those are not on the Can bus they are on the "Kbus" (until say an E90 and they are on the K can bus :-) ) Once a friend broke his door lock and we programmed a module to send the unlock doors message over the kbus. Plugged it into the CD changer plug (which has kbus) in the trunk. Was quite cool.....Anyway.

One thing to consider is if you send a command via another module what is the car sending. For example if I send window down and the car is sending window up :-) but for most things what you want to do will work. Research Kbus. There is lots of stuff for the E39 out there and the E46 is pretty much the same.

Thaniel

[joekitch]

Once a friend broke his door lock and we programmed a module to send the unlock doors message over the kbus. Plugged it into the CD changer plug (which has kbus) in the trunk.

well it's always nice to hear when a proposed project is easier than you first thought
i'll look into Kbus, there's a laundry list of nice comfy things i wanted to do with one of them being that, and it'd be nice to know if most of them could be done easily over Kbus with a simple arduino interface

[prove]

Hi, firends.
I have to you a question as to experts on automobile BMW electronics.
Who knows or who tried to stop the BMW M57 engine or only any other team on CAN (PT-CAN) to the tire of data?
Here http://ican-immo.ru/ people suppress the engine regular (???) signal. Thus no mistakes and failures in the equipment arise.
I want muffling of the engine on CAN but in the system.


I will be very grateful for any helps.