Lotus Exige Data Acquisition System

Part III: Configuration

This is the third page in a multi-part series and will focus on the details of configuring the MoTeC C187 display logger and calibrating sensors. The full list of pages is linked below:

• Part I: Overview

• Part II: Build

• Part III: Configuration

CAN Bus Decoding

The CAN bus on the 2007 Exige’s doesn’t carry much data. It’s only used for communicating data from the ECU to the dash, so the only data available on the bus is what is present on the dash. This entailed: engine RPM, water temp vehicle speed, fuel level, and MIL status. I needed to generate DBC file, a standard description of messages present on the CAN bus, which could be used by MoTeC’s Dash Manager software.

To reverse engineer the CAN bus you can use something like cansniffer from the linux package can-utils to get an idea of what is packed in each frame. But, after doing this on several vehicles I’ve put together an easier method. I have a repository MotecLogGenerator with a set of tools to make this easier. My process is:

1. Generate a DBC file with individual signals for every active byte from every CAN id present in the log

2. Generate a MoTeC i2 log file from the CAN log and the generated DBC file, which will have one channel for every signal in the DBC file

3. Plot channels, deduce what each one means, edit the DBC file to adjust scaling or combine bytes

4. Return to step 2, and repeat until done

Sensor Calibration

The following data sources needed to be calibrated:

• Damper position sensors

• Wheel speed sensors

• Intake air temp from MAF sensors

• Pitot tube

• Oil temp RTD

• Fuel level from the CAN bus

Damper Position Sensors: The calibration needed for these is determining the zero point. The datasheet will provide scaling between signal voltage and position, but you need to decide what zero means so that you can map damper positions to ride height. There are typically two options: zero at full droop, or zero at a set ride height.

I zero at full droop, then I also record the damper position values at a known ride height (typically while being set up on a level surface with accurate driver weight in place). This, along with your suspension motion ratio, gives you all the information you need to map damper positions to ride height. This method is also easier to re-zero the sensors by simply raising the car, which will remain valid as long as the shock length remains constant.

Wheel Speed Sensors: These are variable reluctance sensors, which means they output a non-square wave with the amplitude dependent on rotational speed. The Lotus documentation indicated these sensors were 32 pulses/rev, but I needed to measure what the voltage level of thoses pulses were at various speeds.

Getting an oscilloscope connected to the sensor while spinning it at a known fast speed would be difficult. So, I decided to use the C187 as a makeshift scope! I connected the output from one wheel speed sensor to one of the high resolution AV inputs on the logger and did a test drive while recording a log. Plotting this measured voltage against speed (from GNSS) gave me a good idea of what the voltage level was as a function of angular speed.

Intake Air Temperature: This data was taken from the existing MAF sensor in the intake. It’s a Bosch sensor, but I was unable to find a datasheet for it. However, intake temperature can be queried via OBD-II. So, I made OBD-II queries for the reported intake temperature covering a range of temperatures between 10-60 °C and noted the measured voltage. These values then went into a calibration table in the Display Manager software.

Pitot Tube: Texense provides datasheets for the pitot tube to map the signal voltage to the dynamic air pressure, which you can correlate to speed with a known air density. But, because the pitot tube is located ~0.5m back from the front bumper and only 100mm above the body surface the air velocity and pressure field will still be affected by the vehicle body. Meaning, it won’t quite be measuring freestream velocity.

To correct for this effect I used a dataset at a track from a run with low amounts of wind and limited vehicle traffic, with the air density recorded before and after the run. GNSS speed was used as the true speed which the pitot tube calibration would be corrected to match. Using a dataset from a track is actually advantageous because: a) the vehicle does a full 360° rotation each lap so all wind directions are represented (although not necessarily equally), and b) you can use a long duration of data to capture a good average of wind behaviour.

A second order polynomial was fitted to the data in a least-squares sense. One important detail when doing this was to make sure the data is evenly distributed across speed ranges. To do this, the data was divided into 8 bins based on ground speed then a fixed number of data points was randomly sampled from each bin.

Oil Temp RTD: The Texense PT-100 uses is a 2-wire RTD, which means you measure temperature based on the resistance across those two wires. But, there is several meters of wire between the sensor and the logger which is actually taking the measurement, adding a bit of extra resistance. RTD’s with 3 or 4 wires can correct for this, but 2-wire ones cannot. I corrected for this offset by taking two temperature measurements with the sensor connected through the full harness: once in an ice bath, and once in boiling water. Without this calibration the extra resistance added by the harness would have biased the temperature readings by ~15° C.

Fuel Level: The signal on the CAN bus for fuel comes from the float present in the tank. This was an 8-bit value that reported 0 when near empty, and 255 when full. To get the exact mapping I recorded the CAN bus values as I added known amounts of fuel in two batches. This provided enough data to get the scale and offset to apply to the CAN data to get fuel level in litres. I also did all of this while the car was on a set of scales, so I was able to estimate the longitudinal CoG position of the fuel tank.

Logger and Display Configuration

All configuration for MoteC displays and loggers happen through their Display Manager software. There is a second piece of software call Display Creator (which is not free) that enables you to customize the display style in any way you like.

Two features I was able to achieve within the dash configuration were: automatically start logging when the vehicle moves, and tracking the best sector times from a session. Annoyingly, MoTeC doesn’t have any built in functionality for what would seem to be a common use case in the same way they do for tracking fuel usage or laps.

Auto Logging: The objective with this feature was to make it very difficult to not be recording when you need to be recording. It works as follows:

• On boot the  dash enters an "Auto Log Pending" mode while it waits for a trigger to start recording and will remain in the mode until either a recording is automatically or manually started

• Driving at >5km/h for >5s will trigger the auto logging to start

• At any point before the recording starts a user can cancel it by holding the "Log" button for 2s

• Auto log must be cancelled before a user can manually start  a recording

• Auto log will only occur once, if it is cancelled or a recording has been started it will not happen again

All of this was achieved with a collection of User Conditions in the configuration that set flags for various events like dash boot, button inputs, motion starting, etc.

Sector Times: Dash Manager has functionality to measure sector times based on Lat/Long coordinates, but it doesn’t keep track of your best sector times in the same way it can for your best lap times. I wanted this information so that I could see what my theoretical best lap time was while driving.

What I implemented is configured to support 3 sectors, which must be manually specified in the track details. This could be extended to support more sectors if needed. While running it will generate channels for:

• Previous time for each sector

• Fastest time for each sector

• Optimal lap time (sum of best sector times)

Achieving this required an extensive series of conditions, counters, and math channels to be implemented to realize some complex behaviour from the simply logic operations that Dash Manager provides.

Button Inputs: Besides the On/Off button, I allocated spaced for three momentary buttons. I have them programmed to be multi-purpose, producing different responses based on press duration and simultaneous presses.

Display Inspiration: There were a few existing real world displays and sim racing UI features that I drew inspiration from.

First, I always liked the general layout of wheel display on the Porsche 911 RSR. It’s simple, but effective at diving the screen into distinct sections. On iRacing the Porchse Cup car has a really nice representation for lap time delta that has a progress bar below the delta value that adds a bar for every 1/10th of a second in either direction. Lastly, ACC (Assetto Corsa Competizione) has some awesome tire graphics that show inner, middle, and outer tire temperatures based on colout.

I wanted to add elements of each of these to my own custom display.

Custom Display: The final design I ended up was able to incorporate all of the features and design inspiration I was after. It’s a two page setup: one with the essential data while on track, and a second with additional sensor info.

Below are renderings generated by the Display Creator software.

The main display page graphics are as follows:

• Top Left - Session Info: Timer running for the session and lap counter. The timer can be manually started with the buttons, or it will automatically start the first time you cross the start/finish marker.

• Middle Left - Lap Delta: Current lap time delta. The bar below has bands in 0.1s increments, and grows to the left in green for negative deltas, and grows to the right in red for positive deltas.

• Lower Left - Lap Times: PREV is the last lap time, BEST is the best time so far (gets preserved between power cycles), and OPT is the estimated optimal lap time from your best sectors.

• Top Middle - Min/Max Speed: Peak-Trough detection on speed to show the maximum speed from the last straight or the minimum speed from the last corner.

• Top Right - Temps: Current water and engine oil temperatures.

• Middle Right - Tires: Each graphic represents one corner on the car. The numeric values on the side correspond to the current pressure and temperature of the middle of the tire. The tire graphics work as follows:

  • The bands represent the inner, middle, and outer section of the tire

  • The colour maps to temperature, slowly transition from blue (cold), to green (optimal), to red (hot)

  • The “optimal” temperature is defined by a window, any values within that window all display as the same shade of green

• Bottom Right - Tell Tales: From left to right they are: Recording status (solid red for recording, green blinking for auto-log pending, and grey for no recording active), low engine temp (blue when water or oil temp are below a threshold), low tire pressure or temp (blue when either temp or pressure are low), GNSS status (solid green when fix acquired, flashing orange when not), and comms status (solid red when all serial or CAN devices online).

The second display page is just for further introspection, and most entries on there should be self explanatory. One difference with the tire section is that it will display the maximum observed tire pressures instead of the current ones. This is helpful to see at the end of a session (before the heat soak from the brakes elevate it further) to get an idea of where your pressures got up to before downloading the data.

The indicator lights on the sides and top are mapped to:

• Top: Shift lights that progress from the outside in changing from green, to yellow, to red, and finally flashing blue for the shift point.

• Sides:

  • For wheel spin all three lights flash yellow on the corresponding side with excessive wheel spin

  • For lock ups the lights progressively illuminate magenta and eventually flash on the side with the corresponding excessive wheel lock up

Miscellaneous Configuration Tips and Tricks:

• Do not configure your logger to automatically clear logs after each offload. If an offload ever fails part way through the Dash Manager software will throw an error, but the log will still be deleted on the device.

• Compute ground speed from a mix of GNSS and wheel speed. Only use wheel speed for low speed ranges (e.g. <5 km/h), and use GNSS speed for everything else since it will be more accurate and not influence by changes in tire radius due to loading or pressure.

• Create User Conditions to monitor digital inputs for button presses and update a designated channel instead of using digital input values directly. This abstracts the button presses away from which digital input was used, and it allows you to add logic in a single location to handle debouncing.