We pretend to be 0x4E8 which might be the optional rear iDrive controller, not sure. We then get a “hello” (0x1) from the iDrive controller, as below: RX ID: 0x4E7 Len: 8 Data: 0圆7 0x01 0xFE 0xFF 0xFF 0xFF 0xFF 0xFF We send an initial sync every 1500ms unless the “negotiation is complete”: TX ID: 0x480 Len: 8 Data: 0x00 0x01 0xFE 0xFF 0xFF 0xFF 0xFF 0xFF It uses 0xC0 as a CAN-ID, and sends a two byte message as below: To keep the bus active I have simulated the “Alive Central Gateway” controller on the bus – this seems to send out a sequence of polls continuously. This is a good link too – there is some documentation of DBC messages for reverse engineering cars – The CAN ID’s translate to COB-ID’s like this: CANopen is standard from CiA ( ), and is used in automotive and industrial automation – its quite complicated – but a this is a good intro ( ). I think they are correct, BMW have adapted bits of the standard for their own use. The final posts suggest this is a variation of the CANopen standard, which sits on top of the CANBUS, much the same way IP sits above MAC address in ethernet networks. I have to credit this post as much of what is needed is contained within it, though my unit isn’t quite the same, but the idea’s were enough to work it out – Bimmerfest forum
#BMW IDRIVE CONTROLLER TUTORIAL CODE#
My breakout board is available here: OSH Park Shared Projects, and jumping ahead the code is available here: Github I used the MCP2515 for the CAN controller, with the TJA1054 transceiver (same as the iDrive). This version of the hardware is 100kbps CAN, which is low speed (CAN2.0a) – so you’ll need a suitable transceiver. This iDrive doesn’t use the CAN ID’s that the later versions use (0x273, 0x500 and such), it also requires a bit of negotiation first. So a few weeks later, after following a lot of dead ends, it works…
0 kommentar(er)
