E81/E87 Hands Free Arduino/KCANBus/BT solution

Check here to find out more about ICE, Satellite Navigation, Telecoms etc.

Moderators: babybmwadmin, Producethis, marco_polo, Lambster, Rich196

DaIceMan
Junior Member
Junior Member
Posts: 27
Joined: Thu Dec 27, 2018 5:27 pm

Re: E81/E87 Hands Free Arduino/KCANBus/BT solution

Post by DaIceMan »

Be sure to check that the MCP initilizes correctly using the serial monitor. It needn't be connected to a CAN bus, just connect it via USB and open the Arduino serial monitor.
vaporHR
Junior Member
Junior Member
Posts: 2
Joined: Tue Sep 07, 2021 4:03 pm

Re: E81/E87 Hands Free Arduino/KCANBus/BT solution

Post by vaporHR »

Hello guys, new to this forum.


I have a question regarding e90 2008 320d with bussiness radio and steering controls. I know this is 1 and 2 series forum, but are there any differences in implementation and does this have a chance to work on e90?

Thank you in advance, this is such a great solution!
Last edited by vaporHR on Tue Sep 07, 2021 4:10 pm, edited 1 time in total.
DaIceMan
Junior Member
Junior Member
Posts: 27
Joined: Thu Dec 27, 2018 5:27 pm

Re: E81/E87 Hands Free Arduino/KCANBus/BT solution

Post by DaIceMan »

Hi, theoretically this will work with any K-Can enabled model from the same period. Considering that your E90 is I don't see why it shouldn't work if your stock radio has the same K-CAN implementation (it works also on the E84 up to at least 2012). The headers may be different but that would be easy to modify in the code by looking at the serial debug traffic when pressing the buttons which I left enabled on purpose. I know that the "i" enabled models have a different implementation and this solution won't work. Quickest thing you can do is check the back of your radio and the connector pinout for the K-CAN bus then get an Arduino and an MCP board and try sniffing the traffic given the insignficant cost of the parts.
vaporHR
Junior Member
Junior Member
Posts: 2
Joined: Tue Sep 07, 2021 4:03 pm

Re: E81/E87 Hands Free Arduino/KCANBus/BT solution

Post by vaporHR »

Thank you very much for your response.

I'm not that good at coding, but I have scoured internet for the past few days and managed to understand the concept of it, having your code as a base was of big help.

I ordered parts from Ali, can't wait for them to arrive. I have a few friends who are using FM BT receivers as a solution and they are all interested to have this implemented.

Going from 300 dollars retrofit options to 12 dollar option which possibly has better sound quality is unreal, you should at least open a paypal for a beer donation :mrgreen: :mrgreen:
iignjic
Junior Member
Junior Member
Posts: 2
Joined: Tue Sep 14, 2021 4:26 am

Re: E81/E87 Hands Free Arduino/KCANBus/BT solution

Post by iignjic »

Great work DalceMan!

I am starting similar project with my E90 and I am planning to use MCP2515+TJA1049 for interfacing with KCAN bus.

Since you already have KCAN communication working, I would like to ask you about 120ohm resistor between CANH and CANL lines.
Does your CAN transciever use 120ohm resistor between CANH and CANL when you connect it on back of the radio unit?

Maybe using/not using this resistor causes faulty messages on can bus that send instrument cluster to party mode :) - the issue @Motorsportsz has.

I will try to integrate this project in my E90, I might do a slight modification to tap canbus and power at FZD (rooftop module), place all electronics with microphones there and route only aux cable down to the radio unit.

Thanks :)
DaIceMan
Junior Member
Junior Member
Posts: 27
Joined: Thu Dec 27, 2018 5:27 pm

Re: E81/E87 Hands Free Arduino/KCANBus/BT solution

Post by DaIceMan »

Hi iignjic, in this case, the termination resistor should not be used - let me explain. In long transmission lines such as CAN or SCSI for ex. the line impedance is matched by terminating the ends of the line with the relative matched resistor - or regulated voltage (active termination). The concept is to avoid signal reflections along the line creating stationary or random high and low voltages which interfere with the transient differential values (data) introducing errors. In no case should additional load (termination) be introduced along the line or the communication will be obviously impaired.
When you splice into a CAN bus as in this case, it depends also on where you are splicing in, in this case it's at the end of the line which is already terminated by the radio. Adding additional termination in parallel would introduce an additional load on the whole CAN line and create a potential reflection node between the radio and the MCP and radio and rest of the bus. The rule of thumb is simply piggy back the device as close as possible to the end of the line and the same applies to doing this *along* the line - it is a sort of short T splice. If you keep the length of the T splice short enough (I never exceed 20cms), no problems will arise considering the relatively low speed of the data on the bus (500kbit/s). I have worked with CAN bus many times also on avionic systems and have spliced into without any problems for debugging or modifications and it is stated clearly on many procedure manuals that this is possible and allowed *as long as the T splice is kept short*.
This is why I chose the back of the radio as it is the easiest point to splice in and keep the MCP as near as possible without any termination needed (the 120Ohm term jumper on the MCP2515 board is off).
The user Motorsportz reported a complete CAN failure (the dash and rest of devices go into a reset frenzy loop in an attempt to re-establish communication) - this is usually not because of some minor reflection or random error on the line but a major fault on the bus: either a stuck high or low line, a short or random garbage thrown into the bus by a device (MCP2515) gone haywire.
I hope this clears it up.
iignjic
Junior Member
Junior Member
Posts: 2
Joined: Tue Sep 14, 2021 4:26 am

Re: E81/E87 Hands Free Arduino/KCANBus/BT solution

Post by iignjic »

Sure does IceMan, all clear.
Mystery around 120ohm resistor is now gone. Thank you for the in depth analysis :)
I will start by recording kcan frames, analyze them and work my way from there...

I have one more question where you might have valuable knowledge/opinion/point of view....
Maybe it is more a topic for a new thread, but it is still linked to can bus systems...
Actually it is more system level than physical level question.
Let's say I want to inject a can frame into existing can network (for example to roll a window up or down).
And I take one of the commands already reverse engineered (for example: http://www.loopybunny.co.uk/CarPC/can/0FA.html)
After I check that such message exists in my network I go ahead and inject it.

What are the risks of doing that from a system level point of view?

In the example above Master Unit(the one which sent the command) issues a command to the Slave Unit (window actuator here).
I would assume that Slave Unit would respond with something like "command accepted/rejected" or even after actuator completes its job with a message indicating actuator status" (here: window rolled up/down).
Now if I inject command (can frame to roll up/down the window) then the response coming from Slave Unit will be received by Master Unit which did not send the command but it got a response. Would this cause the Master Unit to throw an error saying something like "there is a tampering attempt" and enter some kind of protected state (like to disable the car start system).
Out of your experience, would you say that there is high risk of permanent damage if such situation occurs in a system? (permanent damage being a module which is electrically ok, but recorded such irregular network packet that it locked itself).
I know that if for example crc is wrong, the packet would be simply dropped. Maybe retransmission could be requested. But what if a valid, but unexpected packet arrives?

Easy solution I can think of now would be to use OBD/Test port ID as Master Unit ID, in which case there will be no unmatched command-response situations in the network.
However, using OBD/Test port might require some initialization and might not support all the functions.

I guess everything is down to particular system implementation, but since modern cars must comply with a lot of safety requirements it makes sense that some sort of protection is implemented.

Thanks :)
DaIceMan
Junior Member
Junior Member
Posts: 27
Joined: Thu Dec 27, 2018 5:27 pm

Re: E81/E87 Hands Free Arduino/KCANBus/BT solution

Post by DaIceMan »

It depends on the communication protocol implementation: in this case and on this low priority device "K-bus", every device has an Originator ID to identify the source (who sends), length and the actual data packets. All you need to do is follow this protocol and you can emulate/spoof any master device so that the slave will accept the command. The other devices will ignore the packet as it doesn't represent any valid ID for them and have not requested any command. As long as you don't disrupt the regular "chitter chatter" no harm is done. The MCP will take care of correctly communicating at the right time and moment. For ex. pressing previous and next on the steering wheel requires no acknowledgement, they're "blind packets", like a UDP packet, it's sent and that's it, whatever, no response is required. The packet is merely recognized by the device because of the ID 0x1D6 which identifies the steering MFD. All you need to do is send such a packet with that ID and subsequent 2 byte command and the device on the bus which recognizes it will execute it. Being that these commands are unique to their respective devices there is no conflict, unless you create one yourself. If you just log some traffic you will get the idea - mind you, there is A LOT of traffic going on on the K-Bus, every second you get over 50Kbytes of data if you don't filter it which can overwhelm your MCU. The filtering must be done at the MCP level in this case (check my code), it's much smarted and cleaner and is the purpose of the MCP. If you checkout loopbunny's page, he has done an immense job of collecting and identifying most IDs so you know what to look for and how to use it correctly. Basically you can emulate anything which is on the bus, you can control the whole dash system if you want, but you would need to disconnect it from the K-Bus as then you would be creating conflicts with data already being sent from the EMS. You can control anything which is usually "idle" such as windows, radio, climate control etc anything on the bus which sits there and waits for it's command. My suggestion is make an unfiltered log and press some buttons for a few seconds then analyse it to learn the traffic. Then set the right filters on the MCP for what you want to actually read to narrow down the traffic (radio or other stuff). Then format one command spoofing any one you have logged with the right ID and length and data command. Be careful not to loop these commands, send only ONE at a time not 100 as this may stall the listening device. Some commands require 2 commands, a start and a stop, some only one, some contain proportional or value data - it depends on the type of command. If you inadvertently clog the bus you may get a warning on the dash which will go away when removed or turned off and on but the error is always logged and will have to be cleared with INPA. Have fun.
DaIceMan
Junior Member
Junior Member
Posts: 27
Joined: Thu Dec 27, 2018 5:27 pm

Re: E81/E87 Hands Free Arduino/KCANBus/BT solution

Post by DaIceMan »

vaporHR wrote: Fri Sep 10, 2021 10:19 am Thank you very much for your response.

I'm not that good at coding, but I have scoured internet for the past few days and managed to understand the concept of it, having your code as a base was of big help.

I ordered parts from Ali, can't wait for them to arrive. I have a few friends who are using FM BT receivers as a solution and they are all interested to have this implemented.

Going from 300 dollars retrofit options to 12 dollar option which possibly has better sound quality is unreal, you should at least open a paypal for a beer donation :mrgreen: :mrgreen:
That's the beauty of it, cheap, stealthy and functional! No modifying your dash, no removing your original radio and mostly you keep the original parking sensor chimes working as the original radio takes care of this too! If you remove the radio and replace it with an android version, you need to add the external "chime box" at the back of the radio which doesn't really work the same was as the original (i.e no directional sound of the obstacle from lefto to right).

You're right, a cold beer is always appreciated, I have to setup a beer account;).
Post Reply

Return to “In Car Entertainment, Communication & Sat Nav”