At this point, I have decoded the following PIDs that are active on the K-CAN bus and that contain parameters I think will be useful to display on the dash.
0x0F2 – trunk status
0x1D6 – steering wheel buttons
0x1F6 – signal lights
0x3B0 – reverse gear status
0x5A9 – DSC status
0x34F – handbrake status
0x330 – Odometer, etc.
0x2FC – door status (also contained on 0x24B)
I now want to look at getting the logger to read these PIDs so that the data contained in them can be logged and displayed in an appropriate format.
While the logger’s CAN1 channel is occupied by the PT-CAN bus through the BMW PT6 protocol, CAN2 is available for our purposes. RaceStudio 3 has a CAN Driver Builder function that allows us to construct a custom driver to communicate with a CAN bus using a protocol that we define. After dispensing with the obligatory “bad things can happen if you proceed” window, we first need to set up some passwords. These can be left empty, but they can’t be ignored. Every time a change is made to custom CAN driver, you will be prompted to select from one of your predefined passwords, even if the password fields are empty. This both protects intellectual property and assures somebody is taking responsibility for loading a driver AiM has not blessed.
Next step is to set up the applicable bus speed, endian protocol and termination resistor. It is right here that we get stuck. The dash is compatible with bus speeds of 125 kbps, 250 kpbs, 500 kbps and 1 Mbps. Our K-CAN bus has a speed of 100 kbps, so is not compatible.
Luckily, CAN1 and CAN2 are completely independent inside the logger. There is no reason they can’t be connected to the same (PT-CAN) bus. Because of the interconnectedness of the PT-CAN and K-CAN busses through the Footwell Module and/or Junction Box, we can hope that the data we have sniffed out on the K-CAN bus is also present on the PT-CAN bus.
A quick check reveals that all of our decoded PIDs are there except 0x0F2 Trunk Status. 0x24B Door Status isn’t there either, but the same data is present on 0x2FC, which is.
So, let’s re-title this post: “Reading the PT-CAN Bus with a custom driver on CAN2.”
If you have set up your decoding notes well, creating a custom driver with CAN Driver Builder is actually very straight forward.
I want to step back to the beginning of the process and mention the programmable termination resistor in the AiM dash. CAN busses consist physically of a pair of wires forming a trunk with 120 Ohm termination resistors at each end of the trunk. Individual branches lead to individual devices, which do not need and should not have a termination resistor. In a pure race car environment, likely the dash will be at one end of the trunk and the ECU at the other, so each of these devices should contain a termination resistor. In our case the logger branches off from a fully functioning and properly terminated CAN bus, so it doesn’t need and should not use the resistor. I mention this because the logger’s default is to select the programmable termination resistor ON. This needs to be selected OFF on CAN2 (and also, for that matter, on CAN1).
What follows is a screen shot of my custom CAN driver. For each CAN ID (aka PID), the bits or bytes of interest are identified. The logger will read the numerical value and log each of these. The setup process also allows the selected numeric values to be associated with text values (like 1 = OPEN, 0 = CLOSED) where this makes sense, as with door status. Similarly units of measure can be assigned to the data, scaling and offset can be adjusted, and other adjustments made to properly display the data in the desired units.
In case the of PID 0x2FC Door Status, the status of each door is most simply represented by a single bit – bit 10 for the passenger door and bit 8 for the driver door. Bits 24-27 represent the trunk status in some models of BMW, but not in our cars. When I took this screen shot, I had put them into the driver just so I could monitor them, but have confirmed they are not useful an have since deleted them.
Similarly, while I have found nothing useful on the CC-ID PID 0x338 byte 2, I have included it in the driver based solely on the loopybunny description of that PID so that I can keep an eye on it with the logger. For example, in theory the BMW CC-ID for low brake fluid level should bring up CC-ID code 0x4A (decimal 74), but it does not. I can’t yet even confirm that 0x338 is CC-ID in our cars.
Conclusion: with verified PID functions known and accessible to the logger on a CAN bus, creating a working custom CAN driver to read and decode the data is not difficult.
Next up, I will try to get this data to display on the logger in a useful format.