fe1rx adds an AiM MXS 1.2 Dash Logger

[fe1rx]

In order to be able to log damper position data, I have selected an AiM MXS 1.2 Dash logger to replace my AiM Solo DL. Due to my experience with the Solo DL and with their RaceStudio analysis software, an AiM logger was a given for me, as opposed to some other brand.



I selected the MXS over the bigger form factor options as it fits nicely in the field of view between the steering wheel spokes. As my car remains street legal and to avoid warning lights and unintended consequences, I did not want to remove the original instrument cluster, so the MXS I mounted to the steering column. That said, the original instrument cluster is now essentially completely obstructed.

The mounting bracket secures to existing metallic structure in the steering column.



The bracket I have constructed attaches with no modification to the column itself.



The column upper trim cover has been cut out to accommodate the mounting bracket.



The bracket secures with two nuts to the column metallic structure.



Installing the modified cover makes for a tidy installation. The MXS is secured to the bracket with four M4 screws into integral vibration isolators.



The MXS incorporates two autosport connectors. A 37-pin primary harness is supplied with the unit, and I opted for an optional 22 pin secondary harness to enable several additional data channels. A third connector will accept rear-view video which can be displayed on the dash. This video cannot be logged, and while it might be useful for maneuvering in the paddock, I am not currently planning to install a rear-view camera.



My bracket position positions the MXS far enough aft that the harnesses do not interfere with the existing instrument cluster over the useful range of steering wheel tilt and telescope positions.



Being mounted on the steering column, the MXS remains fully visible, regardless of steering wheel tilt and telescope position.



I elected to make my own ride height sensor wiring harnesses using MIL-Spec 22 AWG twisted triple wire. Cable routing utilized existing feed-through grommets and existing cable run routing. The image below is at the RH firewall (ECU removed for access).



While I was at it I elected to remove the existing MOST bus, USB interface, and wiring provisions for Sat radio, digital tuner, remote CD changer, exhaust flap and unused shark fin coax. My car had the iPhone integration option, which brought with it all those wiring provisions. I would not have attacked the removal without a wiring diagram in hand as there is significant risk of removing something significant and unintended when stripping wiring. As it is, my radio still works after the stripping out, so all is good. Fun fact, fuse 74 is identified on the fuse map as for the exhaust flap only. Actually, it also powers the gauge cluster, so after stripping out the exhaust flap solenoid and associated wiring, that fuse still has to stay. For reasons perhaps best explained by OCD I want to remove stuff that is not strictly necessary, without giving rise to un-extinguishable warning lights. Threading that needle takes some care.

The MXS utilizes a remote GPS antenna. I elected to get the “roof” version for permanent (as opposed to magnetic) mounting. That meant pulling the headliner down and drilling the roof. I elected a position on the vehicle centerline as close to the centre of gravity as possible.



The GPS works remarkably well, and is able to establish a good satellite signal though the walls of a concrete block building. I haven’t seen that before.



Having removed my AiM Solo DL, I also removed the wiring harness I had installed for it, which provided the DL with power and CAN data connections. The BMW protocol needs to be connected to the PT-CAN (powertrain) bus which on N54 cars is not accessible at the OBDII port. I have run a new twisted pair CAN data line from the junction box (blue connector pins 1 and 2) to the MXS.



The MXS has provisions for receiving data from a second CAN bus. I have tapped into the K-CAN (body) bus so that I can connect to that. Using those signals requires identifying the Message Identifiers of interest and decoding the data contained in the associated messages. I will describe progress on that front in a separate post.

My car is an N54, which has an oil pressure switch in lieu of a gauge. Due to concern over oil pressure, I have elected to install an oil pressure sensor. I am taking oil pressure from one of the plugs on the oil thermostat housing. Although I currently have the sensor mounted directly to this plug for trial purposes, I am going to remote mount the sensor because it is not rated for operation above 130°C and our oil gets hotter than that.



I am also going to log transmission and differential temperatures using the MXS via thermocouple sensors. Not entirely unexpectedly, they are not happy with reading the grounded junction thermocouples I had previously installed, so I will have to replace them with isolated junction versions.

Accessing the second CAN bus, and three additional A/D channels for oil pressure, transmission temperature and differential temperature required an auxiliary harness. AiM has several versions of auxiliary harness and a multitude of ways to add additional data channels, but the version I got provides two K-type thermocouple channels directly, two A/D channels, access to the second CAN bus and a bunch of other connections not currently needed by me. All those wires do result in something of a jungle.



I use a portable Garmin nav unit on the street, which was previously powered by the cigarette lighter plug. I have eliminated the ashtray and its plug to provide a passage for the sensor wires. To tidy up the Garmin power connection I installed a 12 VDC to 5 VDC converter with a short lead to the Garmin.

l

The Garmin is powered from the cigarette lighter circuit (fuse 6), which switches on and off with the key.

The MXS communicates with a laptop wirelessly over WIFI, which is really convenient. For this reason, I have elected to utilize the now abandoned digital tuner circuit (fuse 19) to power the MXS. This circuit is live for some time after the car is turned off, which may be useful when accessing the MXS when the ignition is off.

Next installments will look at:

- available data on the PT-CAN bus
- finalizing the oil pressure sensor installation
- deciphering the K-CAN bus data stream
- figuring out how to get the MXS to understand the K-CAN signals
- configuring the MXS bells and whistles

[lowside67]

Very nice - I see you went whole hog on the upgrade!

On the oil pressure sensor - I see you are planning to remote mount it due to temperature concerns. I am not sure that the temperature is a real issue as these are quite standard items in our motorcycle powered racecar applications which also see high temps. However, the issue that we all do see commonly is these sensors tend to die to vibration related concerns.

Remote mounting the sensor on a 12" extension hose is what we mostly do and that has seemed to address the issue completely. I use a high-temp rubber lined P-clamp around the sensor body to mount it which is a simple and effective way to do so.

Good luck!
Mark

[fe1rx]

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.

[fe1rx]

Originally Posted by lowside67

Very nice - I see you went whole hog on the upgrade!

On the oil pressure sensor - I see you are planning to remote mount it due to temperature concerns. I am not sure that the temperature is a real issue as these are quite standard items in our motorcycle powered racecar applications which also see high temps. However, the issue that we all do see commonly is these sensors tend to die to vibration related concerns.

Remote mounting the sensor on a 12" extension hose is what we mostly do and that has seemed to address the issue completely. I use a high-temp rubber lined P-clamp around the sensor body to mount it which is a simple and effective way to do so.

Good luck!
Mark

Thanks! My remote mounting plan is just about exactly what you suggest.

[fe1rx]

Adding sensors is where the AiM Solo 2 DL (and its Solo DL predecessor) depart the discussion.
To log more data than that provided by the CAN protocol and the device’s internal sensors, we need to step up to a dash logger. I have chosen an MXS for its form factor, but the larger variants have essentially the same capabilities.

AiM has a large variety of essentially plug and play sensors. Plug them in using one of their extension cables, and the logger provides signal power, signal ground and reads the sensor output. Standard sensors have a voltage output of 500 mV to 4500 mV over the sensor range of 0% to 100%. Identifying the sensor by part number in the logger setup software (RaceStudio 3) takes care of assigning the appropriate units to the display.

In my case, I chose an AiM 0-150 psi pressure sensor for logging my oil pressure, and getting it working was as easy as described above.



While the AiM datasheet above identifies the operating temperature range for the sensor, they do not identify its shock or vibration limits. lowside67 has identified vibration as being a weak point with regard to these sensors. This concern is also reflected in the installation notes on the Pegasus website:

https://www.pegasusautoracing.com/pr...sp?RecID=11532

I was responsible for the prototype installation of a V-8 aircraft engine some years back and elected to mount a fuel pressure sensor at a tee fitting hard mounted to the engine. In due course, the (aluminum) fitting failed due to metal fatigue, and while the resulting engine fire was contained, it was a cautionary tale about overhung moments and resonance in vibratory environments. Retrospectively, that mistake was stupid, but it did convince me that remote sensors should be kept, um, remote.

Next in line are my thermocouple sensors. AiM’s harness is compatible with the ubiquitous K-type thermocouple via standard miniature thermocouple connectors. In principle it is as simple as plugging in a thermocouple and identifying the channel as a thermocouple in the logger setup. In practice, there is a caveat arising from the measuring circuit. In AiM’s words in response to my query and suggestion that they revise their documentation:

“For the thermocouples, the fact that they are read with a single ended method (+ connected to analog input and - connected to a reference ground) already carries the fact that a noisy ground would affect the reading. In any case we'll see where to add this specification in the documentation available."

Not all grounds are created equal, and as I found out grounding the thermocouple junction to a chassis ground while the measuring circuit is referencing a sensor ground, with a mV level signal is a recipe for grossly inaccurate temperature readings. Over the range of temperatures of interest (0 – 250°C) a K-type thermocouple output voltage ranges from 0 to 10 mV. This is a very small signal that is easily corrupted by electrical noise or voltage offset between the junction ground and the logger’s sensor ground. Translation – isolated ground thermocouples must be used.

My damper position (aka ride height) sensors are typical of a whole range of 3-wire sensors with a nominal output range of 0-5 vdc. These are handled by AiM using a “custom sensor calibration”. Creating these calibrations is extremely easy in RaceStudio 3. For a simple linear sensor, it could be as simple as defining the signal voltage range (say 0.5 to 4.5 Vdc) and the corresponding measured parameter range (say 0 to 150 psi as was the case for my oil pressure sensor). Here is a look at the LH rear sensor installation:



Using the logger as to provide signal power and ground, and reading the sensor output in mV on our laptop from the live data stream, we can create a correlation table between damper positions and mV output for each sensor. Once we enter these values into the custom sensor calibration table for each sensor, the logger will now display the damper positions directly in the distance units we have selected (mm in my case). I rigged up a scale to measure the damper compression for calibration purposes. For the purpose of calibration, the spring was removed to allow cycling the suspension over is full travel.



My damper position sensor installations are mirror symmetric, so on the left side of the vehicle, increasing compression results in increasing mV readings, while on the right side they decrease. The custom calibration process takes care of this and outputs increasing mm values for each corner, starting at 0 mm for full droop.



I chose to calibrate the sensors at 5mm increments at the start and end of the travel (where I expected the greatest amount of non-linearity) and at 10 mm elsewhere. Clearly, I could have gotten away with fewer calibration points, based on the results, but using more points cause no problems.

[fe1rx]

In simple terms, our cars have three CAN busses:

PT-CAN (powerplant)
K-CAN (body)
F-CAN (chassis)



Various modules are connected to two busses simultaneously, providing a managed gateway that allows sharing of some data between the busses. In the bus chart above JB (Junction Box Electronics), DSC (Dynamic Stability Control), AL (Active Steering) and FRM (Footwell Module) are depicted as having gateway functions.

PT-CAN and F-CAN function at a bus speed of 500 kbps, and K-CAN operates at 100 bps.

KOMBI (the Instrument Cluster) receives data exclusively from the K-CAN bus. Since my goal is to add instrument cluster functionality (odometer, fuel gauge, warning icons, etc.) to the dash logger, it makes sense to look on the K-CAN bus to find it. “Looking” at, aka “sniffing” a CAN bus requires some understanding of how CAN busses function, and some hardware and software tools.

High Performance Academy released their CAN Fundamentals course with perfect timing. You can get a taste of it in this YouTube video:

I took their course and it was sufficient to convince me to dig in. It does a good job of putting CAN in a motorsport context without diving too deeply into a very deep pool that we don’t really need to explore fully. I acquired a Kvaser Leaf Light v2 to access the data, and using Kvaser’s Can King software started looking at the signal stream on the K-CAN bus.

The CAN data starts with an identifier. This is often called the PID for parameter ID, but you may also see them referred to as PGN for parameter group number. The ID is followed by up to 8 bytes of signal data. Some of those bytes are simply along for the ride and can be ignored. Some IDs contain information on multiple parameters, and some just a single parameter. Sometimes the data is contained in a single binary bit (i.e. a status variable that is either “on” or “off”). Each byte is composed of 8 binary bits, so is represented in hexadecimal. Data that is represented by multiple bytes must be combined (concatenated) in either little endian (least significant bit in position 0) or big endian (most significant bit in position 0). In our case, little endian applies. A good working familiarity with Excel is necessary, as it easily handles conversions between hex, decimal and binary, and concatenating data fields. The Kvaser Leaf Light logs data in text format, and Excel can import this into a useful spreadsheet format with some prior prep of the text file, and by properly setting up the import wizard when importing the text file. If this synopsis doesn’t have you running away, I am sure you can handle the task.

Before beginning, we need to know the bus speed, and to find a place to tap into the physical bus. I had already tapped into a K-CAN twisted pair adjacent to the handbrake lever and terminated it with a Mate-N-Lock connector, anticipating connecting it to the logger, so connecting there was easy. The scientific way to figure out the bus speed is to look at the signal on an oscilloscope and measure the duration of a single bit of data. No such foolishness is actually necessary though, as the internet will tell you that the K-CAN bus speed is 100 kpbs.

There are about 95 always active K-CAN PIDs. Many are transmitted at 10 Hz, some faster, some as slowly as once every 20 seconds. Others only appear on the bus under specific operating modes (e.g. DSC off), or only when a specific action occurs (e.g. a steering wheel button is pressed). It should be clear that a log of every PID gets very big, very fast.

Luckily, you can filter the data and only log a single or range of PIDs of interest. Of course, large data files can be sorted and selected from, but pre-filtering the data is much simpler when it is possible.

Knowing what PID is associated with the parameter of interest is step one. The internet should be your first stop, with the caveat that there is no consistency between manufacturers, and not great consistency between BMW models. The following website was very useful in providing a likely list of PIDs, and an idea of the encoding strategies employed:

http://www.loopybunny.co.uk/CarPC/k_can.html

In a few cases, the examples above worked out exactly right. Most are outright not applicable to our vehicle. Sometimes the subject matter of the PID is right, but the encoding is not quite right. The conclusion is that if you can’t sniff out your CAN data directly and verify its encoding yourself, you really can’t make use of someone else’s reverse engineering of a similar model.

At this point, I have decoded the following PIDs that I intend to utilize (0x indicating that the ID is in hexadecimal):

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 have also decoded the following PIDs that are not needed because the data is already collected by the dash:

0x2CA – outside air temperature
0x0C4 and 0x0C8 – different versions of steering wheel angle

There are definitely other parameters I am potentially interested in finding, but this gets us started.

A deeper look at PID 0x34F (handbrake status) is an example of an easy decoding:

1) The loopybunny link provide above tells us that 34F is the handbrake status, that the message is 2 bytes long and that byte 0 contains the data. Further when byte 0 is 0xFE (decimal 254) the handbrake is on, and when byte 0 is 0xFD (decimal 253) the handbrake is off.
2) Connecting to the bus and looking at PID 34F while cycling the handbrake, confirms this function.
3) Byte 1 reads FF (255) at all times so contains no useful data.



Logged data is associated with an internal clock time (in seconds) for each data point. This is very useful. If we didn’t know which PID was associated with handbrake status but had a few suspects, we could set up a log of multiple suspect PIDs, cycling the handbrake at a known interval (say every 2 seconds) and then look for suspect bytes in those PIDs that change between two states at that frequency.

DSC status was one of my greatest areas of interest. I want to be able to display that status on the logger to avoid confusion on track. Finding 0x5A9 required some real detective work, and many tests to decode it. The loopybunny link provides no hints in this case. To find this PID, my approach was:

1) I logged all PIDs while cycling DSC from DTC to OFF to ON at regular intervals.
2) I imported the (large) file to Excel and sorted by PID.
3) Many PIDs were static for the duration of the test so could be discarded.
4) Many PIDs have bytes which change dynamically, but not with any possible correlation to my test, so these too could be discarded.
5) Since DSC is a critical function, I expect he applicable PID to report at a high frequency, so any low frequency reporting PIDs can be discarded (maybe).
6) From this data, I identified 4 PIDs that behaved in a manner that could possibly be correlated to the DSC status.
7) I then repeated the test, looking one at a time to each of the suspect PIDs, under similar test conditions. One by one they were rejected leaving only 0x5A9.

Actually, decoding 0x5A9 was surprisingly difficult. Firstly, it is completely silent when DSC is ON, reporting only DTC and OFF conditions. Second, multiple codes appear during the transition between states and some appear multiple times. And, third, the DTC and OFF states are pinged every 7 seconds while active – something that is only picked up in a long data log.

In theory, DSC status (of which there are only 3 states) can be reported by only 2 data bits. I was expecting to find a PID that reported in that manner, and to find it reporting all three states at 5 Hz or higher. What I found is completely different. Concatenating bit 1 through 3 little endian, we have:

0x1D00B8 = mode changed to DTC with ping every 7 seconds in DTC mode

0x1D0024 = mode changed to OFF with ping every 7 seconds when OFF (*)

0x24001C = mode changed to ON, no ping (*)

(*) these codes are initially repeated 3 times at 0.16 second intervals

My final worksheet is shown below, and it reveals that the clock field, and a calculated interval between event can be very useful in understanding how things work.



Decoding PIDs can be hard work, and while some people guard that work jealously, others share it freely, recognizing that what goes around comes around. One way the data can be shared is in a compact format called “dbc”. It takes a bit of sleuthing to decode the format but a Google search for “DBC CAN Format” will point you in the right direction. Here is an example of a work in progress for the E90:

https://github.com/commaai/opendbc/b...mw_e9x_e8x.dbc

Aside from those PIDs that are fully decoded, such databases provide hints as to the functions of undecoded PIDs. Of course, everything needs be verified to be useful, and a lot of the commonality you would expect between the E90 and E82 is not there. In any case, I found this link to be of some help.

We still need to get our logger to communicate with our bus, and to understand the useful PIDs we have identified. Getting that to work is the subject of a future post.

[fe1rx]

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.

[amg6975]

Great work! I did the same thing a while back going through and finding everything usefull on the CAN bus. If there’s anything else you’re looking for let me know!

From 9) above, the ECU distance is probably the DSC’s output of how far you’ve gone at regular intervals... 100ms maybe? The KOMBI uses this to determine display speed, odometer, trip, fuel consumption, etc. The KOMBI then outputs display speed, and odo value on the K-CAN. The wheel speeds directly outputted by the DSC are used by the ECU and DCT for various things.

The other thing that may be useful to log that I found is engine output torque. I found it for the N55, I expect it would be the same for the N54. I’ll check my notes.

[fe1rx]

The dash has provisions for displaying status icons on an “Info Line” consisting of 12 display positions. Multiple different icons can be displayed at each location. The test condition with the highest assigned priority will display if multiple assigned test conditions are met for an icon location.



The first task is to assign functions to each of the 12 locations. My approach is shown below:



Those items identified in red text are aspirational. I do not yet have access to data that provides the information required to activate those functions. In summary:

1) I need to find a PID providing SRS status to activate the airbag warning light.
2) DSC mode (ON, DTC, OFF) is activated by data from PID 0x5A9 as described in an earlier post. DSC status is provided by ECU_31 channel from the PT6 protocol.
3) Parking brake status is provided by data from PID 0x34F. ABS fail data is provided by ECU_29 from the PT6 protocol. I still need to find a data source to enable a low brake fluid warning.
4) Low oil pressure indication is provided by my added oil pressure sensor.
5) Engine temperature data is provided by the PT6 protocol. I have set the cold icon to activate when oil is below 60°C. The hot icon has been set to activate when either oil exceeds 151 °C or coolant exceeds 117 °C. Above these temperatures and the ECU begin to reduce power. The max icon has been set to activate when either oil exceeds 156 °C or coolant exceeds 120 °C.
6) Signal light status indication is activated by data from PID 0x1F6.
7) I need to find a PID providing headlight status.
8) MIL status is provided by ECU_30 from the PT6 protocol. The engine not running icon is activated when engine rpm I less than 10.
9) The fuel low icons are activated at 20% and 10% fuel indications using fuel volume reported by ECU_26 from the PT6 protocol, adjusted with the scaling factor previously discussed.
10) I need to find PIDs providing low washer fluid and low coolant level data to activate the low fluid icons.
11) Driver and passenger door status is provided PID 0x2FC. I still need to find a PID containing trunk status to activate the trunk open icon.
12) The charging fault icon is activated whenever the vehicle battery voltage is less than 13.2 V, as measured by ECU_27 from the PT6 protocol.

Icons are setup on the logger using RaceStudio 3. The process is quite intuitive. A snapshot of the icon setup screen follows:



The actual icons can be chosen from predefined palate:



Another palate offers icons that can be filled with a colour of choice:



Custom icons can also be imported, but the file format and settings are quite particular (.bmp, 16 bit – A1, R5, G5, B5). I had no luck with getting the alpha channel to work as I intended when I tried it, and I was left with a solid background that looked out of place relative to the other icons.

Remaining logger functions to be set up include the shift lights, calculated gear, programmable alarms, and setting up the data screen(s). I would also like to look at using my unused steering wheel buttons (phone and voice) to control screen selection as the steering wheel buttons are more accessible to the driver than those on the dash itself.

[amg6975]

Originally Posted by amg6975

The other thing that may be useful to log that I found is engine output torque. I found it for the N55, I expect it would be the same for the N54. I’ll check my notes.

For the N55, PID 0x0A9 bytes D7 and D6 or 0x0AB Bytes 1 and 2 should be engine output torque in two's compliment. I believe it's in Nm.

0x0A8 Bytes 4 and 3 are a smoothed torque value.

((HighByte*256) + LowByte)/64 should = Nm.

[fe1rx]

Originally Posted by amg6975

For the N55, PID 0x0A9 bytes D7 and D6 or 0x0AB Bytes 1 and 2 should be engine output torque in two's compliment. I believe it's in Nm.

0x0A8 Bytes 4 and 3 are a smoothed torque value.

((HighByte*256) + LowByte)/64 should = Nm.

Thanks for that. The basic AiM PT6 protocol provides torque, so I don't need to find it myself.

[amg6975]

Originally Posted by fe1rx

Thanks for that. The basic AiM PT6 protocol provides torque, so I don't need to find it myself.

Oh yeah, 32. I missed that the first time reading through that.

Does the dash have provisions for user input or do you have to use the buttons on the unit?

[fe1rx]

Originally Posted by amg6975

Oh yeah, 32. I missed that the first time reading through that.

Does the dash have provisions for user input or do you have to use the buttons on the unit?

I am not entirely sure what you mean by user input.

A few minor things can be set up with the buttons, but generally programming is by Wi-Fi connection (or wired USB connection) to RaceStudio3. You make the changes to the logger setup in RaceStudio3, then upload the new setup to the logger.

I do have my voice and telephone steering wheel buttons programmed to change the logger display screens up and down. That is just a little easier than reaching around to the buttons on the unit.

[amg6975]

Originally Posted by fe1rx

I am not entirely sure what you mean by user input.

I do have my voice and telephone steering wheel buttons programmed to change the logger display screens up and down. That is just a little easier than reaching around to the buttons on the unit.

That is exactly what I mean. Scrolling through the screens, starting/stopping data logs, etc.

[rac]

Originally Posted by fe1rx

Thanks! My remote mounting plan is just about exactly what you suggest.

I wonder how common is common and what the design difference if any, there is between oem sensors that are direct mount and aftermarket sensors that we tend to remote mount.

I googled this last year and came up with no answers on oem design differences. I ended up remote mounting my MAP sensor because it was an aftermarket unit (and direct mount in my case would have made it hard to replace) and direct mounting my oil sensor because I used the n55 unit to replace my n54 oil switch. On the later I figured nobody seemed to be complaining about failed n55 oil sensors so cant be that bad.

Maybe its as simple as racing applications are more often high vibration shake your teeth loose solid mount everything compared to mass production vehicles.

[lowside67]

Originally Posted by rac

Maybe its as simple as racing applications are more often high vibration shake your teeth loose solid mount everything compared to mass production vehicles.

My world is generally bike powered race cars so not only are they constantly at wide open throttle but the revs are VERY high comparatively speaking. With that said, it is super easy insurance so...

-Mark

[PcarDefector]

Originally Posted by fe1rx

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:

Thank you fe1rx for another detailed and very informative post.

[fe1rx]

OIL PRESSURE

The parts arrived to allow me to complete the oil pressure sensor installation. The installation uses a 45° NPT to AN fitting, a swaged -3 AN hose assembly and an AN to NPT adapter. The transducer is secured to the power steering reservoir bracket by cushioned clamp. To keep the installation one-handed, I installed a rivnut in the bracket.









DIFFERENTIAL AND TRANSMISSION THERMOCOUPLES

Finding suitable thermocouples to install in the transmission and differential was a bit of a challenge. To avoid having to drill and tap the cases, I wanted to install the thermocouples in the fill plugs. I found some stainless hex head drain plugs at belmetric.com that I drilled and tapped 1/8 NPT to accept a thermocouple.

In the case of the differential I also reduced the length of the M22 x 1.5 thread to match that of the OE plug and shortened the hex to reduce the length of the assembly.



I found some suitable 4-inch probe thermocouples at TheSensorConnection.com. These are supplied with 1/8 NPT fittings, which allow setting the depth of insertion.
I bent the thermocouple probe to avoid any internal conflict.



The bung installs with an aluminum crush washer.



The transmission installation is more constrained so a bit more effort was needed to shorten the assembly. This bung is M18 x 1.5 and is also installed with an aluminum crush washer.



The bung and associated fitting were assembled with Loctite.



The gears are quite close to the bung so only a small insertion depth is possible.



I am using Red Line D6 ATF in my transmission, and hadn’t looked at the fluid since I put it in 5 years ago. It was black enough to be opaque, so definitely due for a change. I will have to keep a closer eye on this fluid. While the Red Line 75W140 GL5 differential fluid was changed only last summer, it still looked a nice amber colour with no sign of black.



These sensors are now all connected to the logger. I am not sure what temperature limits are appropriate for the differential and transmission, but have provisionally set amber alerts at 120°C and red alerts at 140°C until I am able to establish rational limits. I will try to do that in consultation with Red Line.

[fe1rx]

Daylight is unpolarized. Daylight can be horizontally polarized by reflection from horizontal surfaces, so the resulting glare is primarily horizontally polarized. Polarized sunglasses removes glare by absorbing the incoming horizontally polarized light, while allowing other orientations to pass.

LCD and TFT displays incorporate polarizing filters to control the display output, so the resulting images are polarized in a direction defined by their construction. The angle of polarization can be checked by viewing the display through a polarizing lens and by rotating the lens until the displayed image darkens or disappears. I have checked the centre console, nav and HVAC displays on an ’08 BMW 135i and an ’11 BMW 328i and found that the displays are polarized at 45° so they are visible through polarized sunglasses worn normally. Same for an ’08 Porsche Cayman console, HVAC and radio and the LCD displays on my desktop. The radio display on the BMW 135i is horizontally polarized so is not visible through polarized sunglasses worn normally.

I have a couple of portable Garmin GPS nav units. Their displays do not appear to be polarized as they are visible through polarized sunglasses at all orientations. Same for my iPhone.

The front facing display on my AiM SmartyCam HD rev 2.1 is polarized at 45° so is visible through polarized sunglasses worn normally.





The display on my AiM Solo DL is polarized vertically so is visible through polarized sunglasses worn normally.





The display on my AiM MXS 1.2 is polarized horizontally so is NOT visible through polarized sunglasses worn normally.





A secondary display that is not visible through polarized sunglasses is a minor annoyance. A dash logger that is not visible through polarized sunglasses seems like a serious design flaw, particularly when the manufacturer has implemented viable solutions in their related products.

[amg6975]

Ouch. Are all sunglasses polarized in the same direction? I know the stock radio display is not visible through my polarized RayBans which is kind of annoying, but not like a whole dash...

[lowside67]

Out of sheer ignorance, what is the rationale for using thermocouples rather than standard 1/8 NPT AIM temperature sensors? They look like a bit of a pain with their physical size, both on the inserted end and the bulky connector side.

-Mark

[fe1rx]

Originally Posted by lowside67

Out of sheer ignorance, what is the rationale for using thermocouples rather than standard 1/8 NPT AIM temperature sensors? They look like a bit of a pain with their physical size, both on the inserted end and the bulky connector side.

-Mark

I have multiple thermocouples located all around the vehicle. Getting the thermocouple harness allows me to connect those to the logger whenever I see fit. If I didn't want that flexibility, using a standard RTD sensor would have been easier. While I have a separate 4-channel thermocouple logger, being able to log those thermocouples synchronized to the other AiM data will be useful occasionally.