As with the AiM Solo DL and its replacement the Solo 2 DL, the MX series of dash loggers can directly read vehicle data through the OBDII or PT-CAN (powerplant) busses. The two options provide different amounts of data as a gateway sends only limited data to the OBDII bus. In practical term, connecting to the PT-CAN bus is the only option that makes sense. A description of the OBDII and CAN protocols can be found here:
https://www.aim-sportline.com/downlo...T6_102_eng.pdf
Concentrating on the BMW_PT6 CAN protocol, here are the channels that can be logged on an N54 6MT vehicle using an AiM logger. There will be slight variations in enabled channels for other transmissions and possibly for the N55, but no other data than on this list will be accessible through this protocol.
A few things to note:
1) Channel 1 is the AiM device’s internal battery voltage.
2) Calculated Gear is a standard AiM math channel that calculates the current gear based on speed and rpm, because, except for reverse gear, the 6MT BMW does not output the selected gear as a CAN message.
3) The three ACC channels are generated by the accelerometers internal to the AiM device.
4) The external (vehicle) battery voltage is measured by the AiM device
5) ECU channels 1 through 35 are received as CAN messages by the AiM device and are the channels of primary interest here.
6) On my N54 6MT, ECU_10, ECU_21, ECU_34 and ECU_35 are not supported by the ECU. Presumably ECU_21 GEAR is output on DCT or automatic vehicles.
7) Note that no oil pressure channel is present, so will not be recorded even on N55 cars, which have a pressure transducer.
8) BMWs record two different speeds. ECU_3 is nominally 5 km higher than the actual speed, and it is what is displayed on the speedometer. ECU_4 is nominally the actual speed. As an aside, with some coding you can get the “true” speed to display numerically in your gauge cluster, but the analog gauge will always show the higher value. These speeds are based on wheel rpm and rolling radius so are both affected by non-standard tire sizes.
9) ECU_25 DISTANCE_KM is not the main odometer. I haven’t investigated how this channel functions.
10) ECU_26 FUEL is an uncorrected fuel level in %. It needs to be adjusted with a factor to account for the different fuel volumes of different BMW vehicles. On ours, it looks like the value needs to be multiplied by a factor of 1.22 to accurately represent fuel volume. I need to verify this assumption with some more testing if I am going to make us of this data.
11) ECU_29 ABS STATUS has potential values of 0 through 3 (2 bit), according to AiM. It initially reads “2” when turning on the car, and “0” after successfully performing its self-check based on my testing. AiM can provide no further description of the meaning of the various potential modes.
12) ECU_30 MIL STATUS has potential values of 0 through 3 (2 bit), according to AiM. It reads “0”, assuming no check engine light is present based on my testing. AiM can provide no further description of the meaning of the various potential modes.
13) ECU_31 DSC STATUS has potential values of 0 through 7 (3-bit), according to AiM. It initially reads “2” when turning on the car, and “3” after successfully performing its self-check based on my testing. AiM can provide no further description of the meaning of the various potential modes. Changing the DSC mode (DTC, or DSC off) does not affect the status reading.
So, this is the data that is available “for free”. To get more than that, there are two practical options:
1) Install new sensors (e.g. damper position, oil pressure, thermocouples)
2) Find other useful messages on one or more of the vehicle’s CAN busses. Decode those messages to extract useful data. Make the physical connections necessary to access the messages. Write the CAN protocol required to decode and log that data.
I will look in more detail at both of these options in subsequent posts.