CAN Bus Interpretation
 

Good afternoon everyone,
I’m currently working on a long-running project of a performance dash for the E53, although I’ve reached an impasse. According to what I see on the wiring diagram, I am missing the CAN pins on my OBD port(which are on 6 and 14) and have the K-Line pins (7 and 8) yet the wiring diagram says the can wires are YlwBlk and YlwBrw which are the colors of the wires in pin 7 and 8.
My CAN bus interpreter for my raspberry pi cannot read any data from 7 and 8 (which could be up to the setup of my CAN bus tool) which makes me think I don’t have CAN, yet BMW scanner 1.4 was giving me all kinds of messages about the CAN bus having been interrupted after I had hooked the interpreter up to it. This brings me to my questions.
1) Does the E53 (2005) have CAN bus?
2) Can it be interpreted in any way (I.e is it encrypted)?
3) What wires are 7 and 8 actually?
4) Is there a way for me to only connect to certain CAN busses (since I know all the different modules communicate using it, and I really only need the DME)?
Thanks in advance for any help!


Sent from my iPhone using Xoutpost.com

Are you sure about the wire colours on OBD2 port? Pins 7 and 8 should both be white/violet. Pin 7 is TXD2 diagnostic link to power train modules (engine and transmission) and pin 8 TXD to instrument cluster working as a gateway to K-bus modules. CAN high and low are those mentioned yellow/black and yellow/brown. That communication is only between engine ECU, transmission control unit, instrument cluster, ABS module and steering angle sensor.

https://xoutpost.com/attachments/x5-...us_systems.png

Yes, 2 of them (one for DME <-> AGS, one for DME <-> other modules), but not for diagnostics via ODB2.

Yes, Google "e46 CAN bus project". Messages are similar (if not the same) for BMWs of that era.

K-lines for diagnostics.

Heres the resources I have. I have a pinout from the internet and my OBDII pins
https://xoutpost.com/attachment.php?...1&d=1631312023
https://xoutpost.com/attachment.php?...1&d=1631312140

The generic OBD2 CAN pinout won't matter. That is a federal mandate for model year 2008 and newer. Even if your car was 2008 or newer the CAN pins on the OBD2 connector would not be directly tied to one of the CAN buses that the DME lives on - they would go to some gateway (body module, cluster, etc) and be filtered and/or altered by that gateway.

So my best bet is to tap straight into the YellowBlk and YllwBrw wires on the DME module itself. And at that point, how likely am I to end up permanently damaging something, such as the EEPROM?

Little to none, CAN is designed to be robust. You could absolutely interrupt bus traffic and set all sorts of codes, cause trans failsafe message, etc. by improper termination, shorting the bus or flooding it with high-priority messages.

You should make sure whatever device you connect is not terminated (since the bus is already terminated at both ends) and follow general CAN rules regarding wiring.

I'm guessing whatever hardware you use will live inside the car, so I'd tap in at the cluster or somewhere else inside. I would also look up pinouts on WDS and not rely on wire colors alone. You will want to use the bus that connects a number of modules, not the one specifically used for DME to AGS communication.

So what exactly do you mean by terminated? I’m not sure how I would be able to connect into the canbus wires without creating a termination. This add on board has a CAN H and CAN L screw down terminal block which I was using inline wire taps to get a signal for (plastic things with a metal insert that poke a hole in the side of the wire to give connection to another wire)
The only way I can think of to “avoid terminating” would be to cut the can bus wires, and run two wires to each of the boards terminals, so the connection between the modules is not being intercepted by the add on board, but is instead required to go through it


Sent from my iPhone using Xoutpost.com

Are you using a CAN bus module or chip or does the Raspberry Pie have built in CAN bus??

I’m using a CAN HAT called the waveshare RS485
It has a setup that is involved which I may have done incorrectly, but am unsure if that’s the direction you were going with the question.


Sent from my iPhone using Xoutpost.com

There are 120 ohm termination resistors at each end of the bus, see https://www.kmpdrivetrain.com/paddle...-tips-can-bus/. I believe the E53 has them at the cluster and DSC.

I posted saying that won't work then I read about it. The name is deceiving - RS485 is not the same as CAN, but looks like that device does both.

I don't think the BMW CAN bus uses RS485 which could be part of your problem. RS485 is directional so the software will need to take that into account. Almost anything can be made to work but you might be best off to get a specific CAN bus module.

So do you think a module with this kind of specifications is more appropriate?
https://www.amazon.com/dp/B087PWBFV8...TQB2EDBKT15SPK

I'm more of an Arduino guy, but yes, and that's probably even overkill but nice to have the isolation and for sure the voltage transition since I think the Pi is 3.3v. You should maybe make sure of the voltage that the X5 uses on the CANbus. Is there maybe a sketch to use the Pi as a logic analyzer ??

Not sure about the second part, but I’ll look. I can only find it in a 2 channel variation, which I thought would be nice but I can’t terminate the bus so I wouldn’t be able to connect the engine and trans systems separately.

There is no need to terminate the bus ?? Should be no reason you can't read both channels.

The board you have is fine despite its misleading name. It has a MCP2515 CAN transceiver which I'm familiar with and have used in some BMW CAN projects of my own.

No need to worry about Pi GPIO voltage since that has nothing to do with the CAN bus voltage.

There is also little likelihood that you need to tap into the dedicated DME <-> AGS bus as well. What values are you looking to read and use in your display? I can probably help with that.

No, it is already terminated at each end or else it wouldn't work. If you add another device that has a termination resistor it will likely disrupt existing bus communication.

So the RS458 board I talked about first will be okay? And that is good to know about the voltages. I’m looking to retrieve coolant temp (as a value), oil temp, mpg, AFR and throttle pos

Yes. That board does RS485 (which is of no use here) and CAN.

From the bimmerforums link I posted:

ARBID: 0x329 (DME2)
-B0
-B1 is Temp [Temp in C = .75 * hex2dec(byte01) - 48.373]
-B2
-B3 (bit0 == LSb) bit 7 Cruise 1/0 bit 6 Cruise - bit 5 Cruise + bit 6&5 Cruise Resume
-B4
-B5 Throttle position (00-FE).
-B6 kickdown switch depressed is value (4) Brake pedal depressed is value (1).
-B7

ARBID: 0x545 (DME4),
combinations work to get multiple lights
-B0 Check engine light (binary 10), Cruise light (binary 1000), EML (binary 10000), Check gas cap 2002+ cars (hex 40).
-B1 Fuel consumption LSB
-B2 Fuel consumption MSB. Values just cycle from 0 to FFFF then start over at zero. Fuel consumiption is the rate of change.
-B3 Overheat light (binary 1000, Hex 08), oil level 2002+ cars, (binary 0010, hex 02), On M3's 0x10 7K and Up RPM lights, 0x20 6.5K and up RPM lights, 0x40 5.5K and up RPM lights.
-B4 Oil Temp [Temp in C = hex2dec(byte04) - 48.373]
-B5 Charge light, 2002+ cars (Binary 0001)
-B6
-B7

ARBID: 0x153 (ASC1)
-B0
-B1 Speed LSB
-B2 Speed MSB [Signal startbit: 12, Bit length: 12, 0x0008 = 1 km/hr]
-B3
-B4
-B5
-B6
-B7

You are not going to get MPG. MPG is calculated by injector pulse width (which I can't seem to find, will look) and speed.

Your car is a 2005 (V8 or L6?) and I'm not sure if it has wideband O2 sensors that would provide a real AFR value. Narrowband sensors do not read AFR, they read rich or lean. Even if it does have wideband AFR is probably not broadcast on the CAN bus because there is no need for other modules to know. If it does have wideband sensors you would probably need to use a K-line transceiver to poll for values from the DME (as opposed to listening for a CAN broadcast).

I came across this - https://www.ms4x.net/index.php?title...s_MS43_CAN_Bus. All should be accurate if your car has an L6 and is still likely to be accurate for the V8.

No info on decoding the injector pulse width from the two bytes, but it says:

DME4 0x545
Byte 1 - FCO[LSB]
Byte 2 - FCO[MSB]
Fuel Consumption

If you do happen to have a V8 it would be the N62 since yours is a 2005. That motor does have wideband O2 sensors.

Holy cow! Thanks for all this info? Where are you even finding all of it!
I do have an M54 so the I6 info is correct. I will keep this all for later, and when I make an official write up about all of this, I will be 100% certain to credit you with the findings, since I’m sure that this was not easy to find. I’m not sure if I mentioned it before, but I would like to have the RPM as well, for a “side project” that is going to be fused to this project after I have ironed out all the fine details.


Sent from my iPhone using Xoutpost.com

Also as an extension of what we talked about, do you know how the RPM wire works? Does it send a pulse from the coil packs like I've read or does it send it as a voltage range based on rpm from 0-redline?

You can get RPM from CAN, it is in the bimmerforums link I posted:

ARBID: 0x316 (DME1)
-B0
-B1
-B2 RPM LSB
-B3 RPM MSB [RPM=(hex2dec("byte3"&"byte2"))/6.4]
-B4
-B5
-B6
-B7

This one?

https://www.bimmerforums.com/forum/s...an-bus-project

That's a good thread....

Says it creator. I'd agree. Thanks for contributing so much.

To the question of fuel consumption:

Thanks for this! I will give it a read!

I still can’t seem to read any data from the car. I tapped directly into the yellow black/brown pair of wires on one of the connectors behind the glovebox, and the pi seems to understand it’s connected to some kind of can bus interface, but it is not receiving any messages. Does this have to do with the rate at which the vehicle transmits them, or am I just doing something wrong?


Sent from my iPhone using Xoutpost.com

Baud rate for the PT-CAN bus (only CAN bus in an E53, I expect) is 500k.



What do the wires you connected to attach to?


CAN bus wires are twisted pair. For the E46 and similar vehicles (probably E53) it is yellow/brown and yellow/red or something very similar. Might be good to check a wiring diagram. It should clear it up. Careful with yellow wires as yellow is often used in airbag systems. Don't randomly try wires. Also CAN bus is 5V or less. Tapping a 12V wire could have bad consequences.


Make sure CAN H and CAN L are not reversed as well.

I didn’t check the module, but it was the lowest module in the rack behind the glovebox. I assume the DME, since the plug looks just like the one in that pic. I grabbed those two wires, and a wiring diagram I’d consulted shows that it is yellowblk and yellowbrn as high/low respectively, which I did with red and black wires respectively. I also got nothing when I reversed the polarity on the can receiver. I will try a 500k baud in a bit!

Curious what you have tapped into. Per the diagram shared on post 2 https://xoutpost.com/1209456-post2.html
CAN bus wires only goes between
KOMBI
DME
AGS
DSC
Steering angle sensor.

DME, AGS and DSC are under the hood.

WE are talking E53 right (not E70).?

Correct, E53. I will send a pic shortly if I can

Behind glovebox sounds like body module (GM3).

On GM3:
*Yellow/black - rear lid (bottom) unlocking
*Yellow/brown - drive rear lid (top)

https://www.pss-autosoft.net/diagram...s/G_120195.png

After a brief google search, that would be the one. Makes sense why it wasn’t doing anything hah.
Is there a cable grommet on the passenger side to pass wires thru to the cabin?

The CAN interface you are using has a termination resistor. That may be one of your problems.

https://www.waveshare.com/w/upload/1..._Schematic.pdf

You should look at WDS for pinouts before hooking things up.

So after I was out of town for a week, I’m back to working on this. I tapped the twisted pair that run in accordance with that picture. I’m still not getting any data back. Would I have to physically de-pin the connector then essentially force the signal to go through the pi, by essentially removing the direct line between the two modules and put the PI in the middle? I’m not sure what else to try at this point other than a different CAN bus module.


Sent from my iPhone using Xoutpost.com

Are you running the display with a serial channel? Does the library for the canbus module have some test and diagnostic routines?

I’m not sure about the display, but it’s on the miniHDMI if that says anything. There are two test routines that display the raw data that’s coming in on the CAN lines, but I’m not sure about how to test if the setup is correct

If you are using a sketch to run the display and a different sketch for the CANbus then there could be conflicts between the two. Have you done other projects using the display? Does it show anything from the CANbus sketch? Again I'm talking Arduino so what I'm saying might be completely out to lunch for the Pi. What kind of display are you using btw?

I’ve never had issues with anything else that worked through the GPIO in regards to the display. I’m not exactly sure what you mean by sketch, but I know that the I/O lanes for the first HDMI port are not shared with anything else. I’m using my Kenwood headunit in “mirror” mode which I assume is for phones but it’s what the HDMI port on the back connects to so :dunno:

Can you get the Pi to display anything on the head unit? Maybe the problem is more to do with not displaying data more than not reading it. Sketch is what we call the program we upload to the Arduino to run. What do Pi people call it?

Okay now I get what you mean by the sketch thing. RPi’s are fully fledged Debian Linux single-board computers, so as long as you have proper libraries and support, most Unix programs can run on it, like in this case the apps are .sh or shell files. Yeah I get the desktop and a shell where I run the diagnostic commands and the open source dashboard program as well. The program just says “data: can0. Polling… “ and a blank screen where it should display the hex values.

OK, so you are getting something on the screen just not the data. Is the dashboard app(program) known to work with the CAN module that you have? Have you checked the source code for parameters to be set? Do you have a scope or any way to verify that you have data on the bus or coming from the CAN bus module?

Yes, this was actually the one most users recommend as being compatible with everything. The HAT requires some setup in the boot config files but mine are consistent with everyone else's known working configs, which don't seem to take much else into consideration (like the car transfer speed). Unfortunately I do not have another way to see if I have data coming from the module. Most people had said the best way to ensure your config would be to have gotten the 2 CH module and wire them together and send data from one, to be read by the other.

Is there maybe a ground required from the car to the CAN bus module that you are missing?

I use Phytools PEAK PCAN adapter on all my CAN sniffing projects. It gives me all the information on the bus like CAN addresses, baud rate, etc. It even allows CAN message transmitting to test issues you have.

https://phytools.com/products/pcan-usb-adapter

https://cdn.shopify.com/s/files/1/00...g?v=1569234442

I’m not sure, I will take a look at the pinout, and do some probing to ensure that the ground pins are actually connected to the vehicle ground.

I will look into this, thanks for the tip!

I think I actually have 2 different CAN bus modules that I was going to try with the Arduino but never did. This thread is renewing my interest a bit. My plan was going to be to put an Arduino in the E-box and maybe at the fuel tank to gather information that isn't available on the bus and another on the dash to run the display all linked with a RS-485 bus. I chose RS-485 partly because it seemed to very robust and good for longer distances and other projects I have and didn't know much about CAN. I have everything working (the RS485 with my own data packets and error detection) but haven't put everything together.

If you like electronic projects the DSO138 scope kit (about $15-$30) is pretty cool for the money and is more than adequate for checking most automotive stuff including CAN bus.

well, maybe with this improved and refined knowledge we can tackle this issue together and see if we can finally make something work

Have you checked the source code for comments and clues? I'm guessing this is on GitHub? have you posted questions there? As far as the hardware goes you are working blind without a scope or at least a logic analyzer. Have you tried to see if you can use the Pi as a logic analyzer bypassing the CAN bus shield/hat?
Have you tried disconnecting the terminating resistor as suggested? (My CAN bus module appears to have jumpered pull-ups.) Did you check into the grounding?
If your CAN module is fully isolated it will need both power and ground from the vehicle on the input side.

So the project is on GitHub, and I’ve been communicating with the devs and other users on their slack for quite some time now. They’ve been helpful but nothing has made much progress. They believe the bus traffic may be encrypted.
I will look into the logic analyzer question in a little bit, but if it’s possible I will give it a try.
The pi is powered by the cigarette lighter outlet, so the ground and hot pins have direct continuity to the vehicle battery ground/power.
In response to the resistor question, I actually returned the original can module and switched it out for a 2 channel which also has a jumper for the termination resistor, which I have tried both on and off.
This is turning into one of those projects that I’m in way over my head and it’s starting to bother me that I can’t make progress. I guess the logic analyzer is the next best step.
Even the repair manual contains little to no info on the actual speeds/configuration of the can bus, besides telling me what it’s hooked up to on which pins.


Sent from my iPhone using Xoutpost.com

It is absolutely not encrypted. If if the message payload were you would still see CAN messages if your hardware/software were functioning properly.

RE the isolation: If isolated the CAN module will need power and ground (depending on the level of isolation) on the data input side SEPERATE from the Pi supply. Yes it could be coming from the same place but the makers of the module don't know how you are going to use it. I also noticed that the CAN module has it's own crystal so it will be limited to only certain data rates that can be derived from the crystal which might not match up with the BMW data rate. Just putting that out there as a possibility.

BMW and almost every street car CAN bus baud rate is 500k. Work with that as default. :thumbup:

500k is pretty fast! I tested my RS485 setup up to 512k and was error free (I was totally blown away that it could go that fast!) I didn't even try faster because I thought that was already ridiculous and about 100x faster than I would really need. Looking at the CAN bus protocol though there is a huge amount of bits around each packet so will need at least 3 times the speed to move the same data as what I'm doing with the RS485 bus. For sure good to know though and you would think if 500k is pretty universal for automotive the CAN bus module and software would be set up for that. :)

Haha! I had just had a look at my CAN module and it has a 8,000 mhz crystal so a divide by 16 counter would give exactly 500k :) so that all makes sense as does the reason for the crystal in the first place since 500k is not normally dividable from most processor clocks I'm thinking. ;)

@ikv0315 maybe try setting the address filter for a specific piece of data. Polling for anything probably won't return anything if the filter is exclusive to everything it's not set to. Makes sense in a way because there is no way you can display scrolling data fast enough. If you can get into the source code and set a "data capture" to a buffer for set time or number of frames and then display the buffer it might help to see what's going on.

There also seems to 2 different bit frame lengths, 11 and 29, so that might be something to look into.

Keep the wiring short and twisted pair. BTW How are you tapping in to the wires?

Also maybe make sure you have the right identifiers for the CAN bus you are working with. AFAIK the other diagnostic and communication lines are Can buses(use CAN protocol) as well and probably use different identifiers.