Channels and Events

This page outlines the core concepts of channels and events, which are essential for data communication within the system.

Definitions

Channels

Channels represent a single piece of dynamic data, serving as the primary communication method within the system. They facilitate data transmission between inputs, functions, and outputs, holding either numerical values or text strings. Channels are ideal for representing sensor readings, user inputs, intermediate values, or other dynamic data that requires processing or display.

The system includes a wide range of built-in channels for common use cases. Using these predefined channels is recommended, as they ensure compatibility across Emtron displays, enabling seamless mapping during configuration imports. If no suitable built-in channel exists, custom channels can be created.

Examples: Engine Speed, Manifold Pressure and Engine Temperature

Custom Channels

Custom channels allow you to define named channels tailored to specific use cases. However, when importing or exporting sub-configurations with custom channels, compatibility issues may arise with other base configurations. Reconfiguring or remapping channels is often necessary in such cases.

TIP: If a commonly used channel is missing from the predefined list, contact Emtron support to request its addition.

Units

Channels use predefined metric units wherever applicable. The system operates internally in metric units.

The channel preference system allows you to change display units (e.g., from meters to feet) at the point of display. The system automatically handles conversions between compatible units of the same type.

Events

Events signal specific occurrences within the system, enabling different components to communicate and respond to changes. Unlike channels, which represent continuous data, events are discrete and occur at a specific point in time.

Examples Engine Start, Lap Beacon and Keypad Press 1

Custom events can be created the same as custom channels

Concepts

Coupling

The channel and event system enables communication between various system functions without requiring direct knowledge of each other. This design offers maximum flexibility, allowing functions to interact in any desired configuration.

However, be mindful of the following:

• Avoid writing to a channel from multiple sources, as this can cause conflicts.
• Tracking the source of a channel’s value can be challenging.

The flexibility provided by this system outweighs these potential drawbacks for a highly configurable product.

Inputs

Inputs receive channel values or events. For example, a gauge on a display can be an input that reflects a channel’s value. Channels and events can be mapped to configurable inputs across various system functions, and a single channel or event can be mapped to multiple input functions as needed.

Outputs

Outputs write data to channels or events. Key distinctions between channels and events as outputs include:

• CautionA channel can only be written to by a single function. Failing to do so will result in conflicts and erratic behavior. The system cannot detect this error.
• An event can be triggered by multiple functions without issue, as events are discrete and do not hold continuous values.

Chaining

Functions can be chained together to perform more complex processing tasks.

It is important a unique channel is used between each function.

graph LR;
  A[Example Input] -- Channel Value A --> B(Math Function)
  B -- Scaled Value A --> C(Table Function)
  C -- Scaled Value B --> D(Table Function)
  D -- Scaled Value C --> E(Example Output)

Note: Each level of chaining can add between 0 and 10ms of processing delay.

Examples

The following are contrived examples to demonstrate what is possible.

Averaging frequency inputs then sending on CAN

This uses the math function to average two channels before spitting them out on the CAN bus.

graph LR;
  A[Frequency Input 1] -- Wheel Speed Left Rear --> C(Math Function)
  B[Frequency Input 2] -- Wheel Speed Right Rear --> C
  C -- Wheel Speed Average Rear --> D(CAN0 Tx)

Note: As channels can be assigned to multiple inputs, Wheel Speed Right Rear could also be assigned to a gauge on the display, or recorded by the data logging system.

Potentiometer and engine temperature controlled shift point adjustment

Unlikely in real life, but demonstrates combining data from different sources, using a table to scale, then outputting the result.

This uses the table function to combine the potentiometer and engine temperature to select a shift point which is fed into the shift pattern.

graph LR;
  A[CAN0 Rx] -- Engine Speed --> C(Table Function)
  A[CAN0 Rx] -- Engine Temperature --> C(Table Function)
  B[Analog Input] -- Shift Adjust --> C(Table Function)
  C(Table Function) -- Shift Level --> D(Shift Light)

By default the shift system uses a gear based calculation. This steps around this and uses a table to combine engine temperature and a user setting.

Telemetry

Introduction

The Emtron telemetry system provides high speed, fully wireless telemetry services. Telemetry can connect over a 4G wireless modem or a Starlink satellite modem.

Telemetry products can be purchased from the Emtron website.

Data Service

Remote monitoring of channel and event data.

• Encrypted and secure data transmission
• Up to 64 slow channels (10Hz max)
• Up to 64 fast channels (50Hz max)
• Up to 50 events per second
• Configurable start/stop conditions to prevent bandwidth waste

More Info…

Voice Service

Voice Communications (Voice Comms) is a real-time audio communication feature that allows you to talk with other users connected to the same vehicle. Whether you’re coordinating between multiple operators, communicating with remote technicians, or managing a team during testing, voice comms provides clear, direct communication with built-in priority management.

• Encrypted and secure voice transmission
• Real-time voice calls with other connected users
• Automatic speaker management - System intelligently prioritizes speakers
• Push-to-Talk (PTT) mode - Control when you transmit using a keyboard shortcut
• Priority levels - Higher priority users can interrupt lower priority speakers
• Audio activity detection - Know when audio is being transmitted or received

More Info…

Text Service

Text Communications is a real-time messaging feature that lets you communicate with other users who are connected to the same vehicle or session. Whether you’re using the desktop application or accessing the web interface, you can send and receive messages instantly.

• Send and receive messages in real-time with other connected users
• Automatic alerts/Quick Messages - Send quick messages automatically triggered by system events
• Triggers - The display can be configured to act on certain text message commands.
• View message history - See the last messages exchanged in your session
• Multiple connection options - Access the feature via desktop app or web browser

More Info…

Quick Start

Activation - License Server

To activate the Telemetry feature on your device, login to EmNet. Once logged in, from your Dashboard, click the Activate Telemetry button.

• Enter the device serial number.
• Enter the one time user Telemetry Activation code as provided after purchase.
• Enter the Telemetry Vehicle Name. This will be used in the telemetry authentication settings.
• Enter the Telemetry Password. This will be used in the telemetry authentication settings. Use a password you are comfortable sharing with team members as it is used by all software connecting to the vehicle.

Once the details have been filled out, click Activate Now to complete the process.

Supported Devices

Setup - ED7/ED7M/ED10M

Authentication

In Display Studio, the first thing to configure is the authentication settings, found in File → Telemetry Credentials.

Ensure to click Save Telemetry Settings as these are stored independently of the config.

PC Client — EmStream

On the PC, use EmStream to subscribe to the live telemetry stream, monitor channels, and use voice and text chat. See the Getting Started guide for connection steps.

Service Specific Setup

• Data Service
• Voice Service
• Text Service

Architecture

The following diagram shows the relationships between systems for a telemetry data connection via a RUTM11 4G modem.

erDiagram
"License Server" ||..|| "Telemetry Server": "validates credentials"
"Telemetry Server" ||..o{ "Telemetry Modem (RUTM11)" : "4G internet"
"Telemetry Modem (RUTM11)" ||--|| "Emtron Display (ED10/ED7)" : "PUB: telemetry data"
"Telemetry Server" ||..o{ "Standard Modem" : "internet"
"Standard Modem" ||--o{ "PC with EmStream" : "SUB: telemetry data"

"PC with EmStream" {
    display-name required-text-chat
    vehicle-name REQUIRED
    password REQUIRED
    region REQUIRED
}

"Emtron Display (ED10/ED7)" {
    serial-number built-in
    display-name optional
    vehicle-name REQUIRED
    password REQUIRED
    region REQUIRED
}

Logging

Functions → Logging

The logging function records channel values and events to files on the display’s internal storage. Logged data can be downloaded from the Home view when a device is connected.

Logging Groups

Logging is organised into groups. Each group defines what to log, when to start, and when to stop.

Creating a Group

1. Open Functions → Logging.
2. On the Groups tab, click Add Group.
3. Name the group and configure its settings.

Groups can be exported and imported as .lgrp files to share logging setups between configs.

Group Configuration

Each group has four main areas:

Start Conditions

Define when logging begins. Use condition sets to trigger on channel values, events, or combinations — for example, when engine RPM exceeds idle speed.

Stop Conditions

Define when logging ends. Common choices include ignition off, a manual stop event, or a timer expiry.

Logged Channels

Add channels to record and set each channel’s Log Rate. Higher rates capture more detail but produce larger files.

Logged Events

Add events to record. Event timestamps are stored when the event fires.

Settings Tab

The Settings tab configures global logging parameters such as file naming, storage limits, and post-trigger behaviour. Adjust these to match how much storage the display has available and how long you need logs retained.

Drag Race Timing

Functions → Drag Race Timing

Drag Race Timing measures elapsed time and speed from a standing start, recording results at standard drag strip distance markers. Distance is calculated by integrating the configured speed channel.

Enabling

Check Enable to activate the function.

Configuration

Typical Setup

1. Arm when the vehicle is staged (for example, a staging light input or speed below 2 km/h).
2. Start when the vehicle begins moving (for example, speed exceeds 2 km/h, or a launch event fires).

Distance Markers

When a run is active, the function records time and speed at each marker:

The run completes automatically when the 1/4 mile distance is reached, or aborts if speed falls below the abort threshold.

Output Channels

The function writes elapsed time and trap speed at each marker, plus cumulative Drag Time and Drag Distance channels during a run. A live drag time slip preview is shown on the configuration page when a device is connected.

Displaying Results

Map the drag timing output channels to Value or Time gauges on a screen. For example, show 1/4 Mile Time and 1/4 Mile Speed on a dedicated drag page.

Drag timing can also work alongside Lap Timing — use a finish beacon on a drag strip start/finish line for point-to-point events.

Counters

Functions → Counters

Counters hold a numeric value that changes when events fire or conditions become true. Typical uses include counting gear shifts, button presses, or how many times a threshold was crossed.

Increment and decrement

Each counter can increase or decrease based on:

• An event, or
• A condition becoming true

Step (increment / decrement amount) controls how much the value changes each time.

Wrap

When Wrap is enabled, the counter wraps to the minimum when it exceeds the maximum (and the reverse when decreasing). When wrap is off, the value clamps at the limits if clamp options are used.

Following

A counter can follow another channel: it tracks the increments and decrements of that channel rather than copying its absolute value. Use a follow condition when the follow behaviour should only apply in certain states.

Resetting

Reset the counter to a fixed value or to the value of another channel when an event or condition becomes true.

Forced value

While a forced condition is true, the counter is held at a forced value. When the condition clears, the counter returns to its previous value.

Persistent

If Persistent is enabled, the counter value is stored on power off and restored on power up. The initial value is only used the first time, before any value has been stored.

See also Persistent Channels for retaining arbitrary channels across power cycles.

Odometer

Functions → Odometer

The odometer function integrates a speed input to track total vehicle distance and up to four independent trip meters.

Configuration

The main Odometer channel holds total distance in km. Trip channels hold distance since their last reset event.

Resetting the Odometer

The total odometer value can only be decreased with a one-time code from Emtron support:

1. Connect to the display.
2. Open Functions → Odometer.
3. Note the challenge code displayed on the page.
4. Contact Emtron support with the code to receive a reset password.
5. Enter the new odometer value. If the new value is higher than the current reading, no password is required.

Increasing the odometer (for example, after an instrument cluster replacement) does not require a support code.

Persistent Channels

Functions → Persistent Channels

Persistent channels save their values to non-volatile storage on the display. Values are restored when the device powers on, surviving power loss and config reloads.

Use Cases

• Store user-adjustable settings (shift point offsets, display preferences)
• Retain counter values that must survive ignition cycles
• Hold calibration offsets set by the driver

Configuration

1. Open Functions → Persistent Channels.
2. Click Add to add a channel to the persistent list.
3. Select the Channel to persist.

Both numeric and string channels are supported.

Behaviour

• On startup, stored values are loaded from the device and written to the configured channels.
• On power-down (or when a Store event is triggered), current channel values are written to storage.
• Only channels in the persistent list are saved — other channel values are lost on power cycle.

Note: Only one function should write to a given channel. Do not configure the same channel as both a persistent channel and an active output from another function.

Timers

Functions → Timers

Timers produce a time value (seconds) on an output channel with configurable start, stop, and reset logic.

Example: hide the camera view 10 seconds after reverse gear is deselected.

Settings

Output Channel

Channel that holds the running time in seconds.

On Expired Event

Event triggered when the timer reaches Max Time.

Max Time

Maximum time in seconds. 0 = no time limit.

Reset Mode

Start Condition

When the start condition is true and the stop condition is false, the timer runs. The stop condition takes precedence.

Stop Condition

When true, the timer stops. If no stop conditions are set, the result is always false (does not force a stop by itself).

Reset Condition

When true, the timer resets to 0. Only used when Reset Mode is On Condition. If no reset conditions are set, the result is always false.

CANopen

CANopen

CANopen is an industrial fieldbus protocol that runs on a standard CAN network. Use it when you need to exchange cyclic process data with drives, I/O modules, sensors, or other CANopen devices — for example fan controllers, valve drivers, or third-party modules that speak CANopen PDOs rather than a custom CAN message list.

Overview

For each CAN bus you can:

1. Turn CANopen on and optionally act as network master (NMT).
2. Optionally produce SYNC and heartbeat.
3. Define nodes (devices on the bus by node address).
4. On each node, define PDOs (process data objects) that either transmit (encode channels onto the bus) or receive (decode bus data into channels).
5. Export / import the whole CANopen configuration for that bus as a .canopen file.

Where to find it

1. Open Communications.
2. Select the CAN bus you want to configure.
3. On Settings, enable CANopen.
4. Open the CANOpen tab (shown when CANopen is enabled).

Bus settings (Settings tab)

These appear under the CANOpen heading on the bus Settings tab (alongside name, bit rate, and termination).

CAN bus basics (still required)

CANopen uses the same CAN bus settings as other traffic:

• Bit rate — Must match all devices (commonly 250 kbit/s, 500 kbit/s, or 1 Mbit/s).
• Termination — Enable bus termination only when this device is at a physical end of the bus (120 Ω).

CANopen tab

With CANopen enabled, the CANOpen tab configures nodes and PDOs for that bus.

Export and import

At the top of the tab:

Nodes

A node is one CANopen device on the bus, identified by its node address (node-ID).

Node list

• Lists all configured nodes.
• Labels show address and enabled state, e.g. Node 3 [On].
• Drag to reorder (order is for organisation only; the bus address is what matters).
• Add Node creates a node with the next free address (1–127) and Enabled on.

Node settings

PDOs (process data objects)

PDOs are the cyclic data packets of CANopen. Each PDO belongs to a node and has a direction:

Adding PDOs

• Add TX PDO — Creates a transmit PDO with COB base 0x200 (standard RPDO1 base when you are the master writing to a slave).
• Add RX PDO — Creates a receive PDO with COB base 0x180 (standard TPDO1 base for data from a slave).

These defaults match the common predefined connection set; change the COB base if your device datasheet specifies different IDs.

PDO settings

Transmit types

Effective CAN ID

Displayed for the selected PDO:

Effective CAN ID = COB Base + (Node Address & 0x7F)

Example:

Encode (transmit mapping)

For a TX PDO, encode entries pack channel values into the 8-byte payload.

Encode list

• One row per field in the frame.
• Label shows channel name and byte index (or “(no channel)” if unassigned).
• Add Encode appends a field; the next free byte index is suggested automatically when possible.

Encode settings

How encoding works (simple model)

raw = round(channel_value × multiplier)
raw = (raw & mask) << left_shift
store raw in payload at byte_index for byte_count bytes (little-endian)

Multiple encode fields can share a byte (values are ORed into the payload), which is useful for bit-packed flags.

Decode (receive mapping)

For an RX PDO, decode entries unpack the payload into channels.

Decode list

Same idea as encode: list of fields with channel + byte position.

Decode settings

How decoding works (simple model)

raw = read little-endian integer at byte_index for byte_count
raw = (raw >> right_shift) & mask
if signed: sign-extend using mask width
channel_value = raw / multiplier

Typical setup workflow

Command a slave (master → device)

1. Enable CANopen on the correct bus; set bit rate and termination as needed.
2. Turn on Act as Network Manager if this unit should start the network.
3. Add Node with the device’s node address; keep Enabled on.
4. Add TX PDO (default base 0x200 is often correct for RPDO1).
5. Add encode fields for enable, setpoint, etc., matching the device manual (byte layout, scaling).
6. Optionally Add RX PDO (base 0x180 for TPDO1) and decode status feedback into channels.
7. Optionally set heartbeat consumer on the node if the device produces heartbeats.
8. Apply/send configuration and watch CANopen Tx/Rx Count channels and live channel values.

Example: 16-bit scaled speed at bytes 2–3

Device expects target speed × 10 as unsigned 16-bit little-endian at bytes 2–3:

Status channels

Per CAN bus index (1–4), the firmware publishes counters you can log or display:

If TX count stays at zero: confirm CANopen Enable, node Enabled, PDO is Transmit, configuration has been applied to the device, and the CAN bus is online.

Quick reference — COB-ID bases (predefined set)

These are industry-standard bases; many devices use them by default:

Always confirm against the device manual — some products use custom COB-IDs.

Troubleshooting

Related

• Channels and Events — how channels are used across the system
• OBD-II — diagnostics protocol on CAN (different from CANopen)
• LIN Bus — another serial bus configuration page

Stage Timing

Functions → Timing → Stage

Stage Timing measures one continuous segment from start to finish — stage rally, hill climb, or any point-to-point run. It does not count laps. Runs save to the Timing Run Library.

Enabling

Check Enable and set the speed channel (km/h). Distance can be integrated from speed or read from a distance channel.

Arm, start, finish, abort

Unlike circuit timing, stage does use Finish Beacon for the finish line. Circuit S/F uses Lap Beacon only.

Live delta

Stage Time Delta is distance-matched against the stage run set as reference in the Run Library (current time − reference time at the same distance). Negative means ahead of the reference.

• Requires a saved trajectory on the reference run.
• There is no fixed “manual reference time” in stage config — use the library.
• Without a usable reference trajectory, Stage Time Delta stays invalid (blank/NaN).

Output channels

Events: Stage Start, Stage Finish, Stage Abort (when those transitions occur).

Related

• Locations & lines — map finish line to Finish Beacon
• Timing Run Library
• Circuit Timing · Drag Race Timing

Timing Run Library

Functions → Timing → Run Library

The Timing Run Library stores finished (and aborted) runs from Circuit, Drag, and Stage timing on the device. Use it to compare live runs against a past result, or to show a past result on the dash.

Legacy circuit .trk files are no longer used. Best laps and trajectories come from this library.

List and filters

When connected to a device, the page lists runs with discipline, location, time, and duration.

• Filter by discipline (circuit / drag / stage) as needed.
• Select a run for actions below.
• Import / export packages for backup or transfer (where available in Studio).

Reference vs review

Set as reference

1. Select a finished run.
2. Set as reference.
3. Confirm live delta channels start tracking that run (circuit best-lap trajectory, drag splits/trajectory, or stage trajectory).

Clear reference removes the ghost so circuit Δ falls back to the current outing’s best lap, and stage/drag live library deltas stop.

You can also step reference on the device with virtual-button events (Timing Reference Next / Prev / Best / Clear) if those events are wired on a page.

Review

Set as review (or copy reference → review) fills Timing Review channels for gauges that should show a historical result without affecting live deltas.

What “time” means in the list

Timing Reference Time on the bus matches that representative time for the selected reference run.

Channels (overview)

Reference group (live ghost metadata): run id, label, location, time, distance, mode, plus discipline-specific splits (drag markers, circuit best lap / sectors).

Review group: same idea for display-only selection, including stage review time/distance.

Library count reflects how many runs match the current filter.

Tips

• After a good outing, set that run as reference before the next session.
• For circuit, ensure the reference run has a usable trajectory if you want smooth distance-matched Δt/Δv.
• For stage, distance-matched Stage Time Delta requires a trajectory on the reference run.
• Drag can use a full library trajectory or fall back to a sparse curve from marker times / manual timeslip.

Related

• Circuit Timing · Drag Race Timing · Stage Timing
• Locations & lines

Alarms

Alarms

Alarms monitor the system at runtime and notify the operator when something requires attention. Each alarm evaluates a set of trigger conditions every update cycle and, when active, broadcasts its message through dedicated system channels.

Alarm List and Priority

Alarms are processed in list order — position 1 is the highest priority, position 2 is lower, and so on. When multiple alarms are active simultaneously, only the highest-priority active alarm (lowest list index) is shown on the alarm channels at any given time.

The alarm list can be reordered by dragging, and individual alarms can be exported to .alarm files for reuse.

Settings

Identity

Trigger Conditions

Defines when the alarm becomes active. Uses the standard condition editor — see Conditions for full details on comparisons, CH mode, and logic operators.

The alarm activates on the first update cycle where all conditions evaluate to true (subject to the hold-off timer — see Timing below).

Acknowledgement

Manual and automatic acknowledgement both set the alarm inactive and clears the auto-acknowledge timer.

Timing

With Auto Acknowledge: the hold-off starts from when the alarm auto-clears.

Without Auto Acknowledge: the hold-off starts the moment the alarm first fires, so the alarm can only re-fire this many seconds after it was last triggered.

Output

Channels

While any alarm is active, the device writes the winning alarm’s data to system-wide channels every update cycle:

These channels can be used to drive displays, overlays, logging triggers, or any other part of the system.

Tips

• Order matters. If two alarms can be active at the same time, place the more critical one higher in the list so it takes priority on the alarm channels.
• Use Hold Off to avoid flicker. If a channel is noisy near a threshold, set a hold-off of a few seconds to prevent repeated firing.
• Active Status Channel for independent reactions. The alarm channels only show the highest-priority alarm. If you need a specific lower-priority alarm to also drive an output (LED, relay, log trigger), use its Active Status Channel.
• Always False / Always True conditions. An alarm with a single “Always True” condition fires immediately on startup — useful for testing the notification pipeline. An “Always False” condition is equivalent to disabling the alarm but leaves the configuration intact.

Conditional Logic

Produces Channels and/or Events based on programmable conditions.

• The Logic Output Channel is the channel that will be produced when the condition is met. It’s value will be 1 when true, 0 when false.
• The On Logic True Output Event is produced when the condition becomes true.
• The On Logic False Output Event is produced when the condition becomes false.
• The Logic On Delay is the time in milliseconds that the logic output will be delayed after the condition is met.
• The Logic Off Delay is the time in milliseconds that the logic output will be delayed after the condition is no longer met.

Conditions

Condition Setup

Conditions are the trigger logic used throughout the system — in alarms, virtual inputs, conditional logic, and more. A condition set is a list of one or more individual conditions combined with logic operators.

Individual Conditions

Each condition compares a channel value against a threshold and returns true or false.

Comparison Operators

Constant vs Channel RHS

The small # / CH toggle to the left of the RHS field switches modes:

• # mode — compare against a fixed number you type in.
• CH mode — compare against the live value of a second channel. This lets you express relationships like “Engine RPM > Target RPM” or “Oil pressure < Minimum oil pressure”.

In CH mode the live value of the RHS channel is shown alongside the LHS value so you can see both sides in real time.

Live Preview

The coloured dot at the left of each condition row shows its current evaluation result:

The dot updates every realtime frame — you can watch conditions transition as the system runs without needing to save or trigger anything.

Logic Operators

When a condition set contains more than one condition, a logic operator sits between each pair and controls how they are combined.

Evaluation Order — Left to Right, No Precedence

Important: Logic operators are evaluated strictly left to right. There is no AND-before-OR precedence as you might expect from mathematics or programming languages.

Given conditions A, B, C with operators between them:

A  [AND]  B  [OR]  C

Evaluates as:

(A AND B) OR C

And:

A  [OR]  B  [AND]  C

Evaluates as:

(A OR B) AND C

This means the order of your conditions matters. If you need AND to bind tighter than OR, place the AND conditions consecutively at the top of the list.

Example — Engine over-temperature alarm

You want: “Water temp high AND (RPM above idle OR load above 50%)”

With left-to-right evaluation you cannot express this directly in one flat list. Instead, split it across two condition sets, or reorder so the OR comes first:

RPM > 1000
[OR]
Load > 50
[AND]
Water > 95

Evaluates as ((RPM > 1000) OR (Load > 50)) AND (Water > 95) — which is correct for this case because the AND is last.

Gauges

Gauge Types Reference

This document provides comprehensive documentation for all gauge types available in the Emtron Displays.

Table of Contents

1. Common Properties
2. Text Gauge
3. Value Gauge
4. Time Gauge
5. Bar Gauge
6. Dial Gauge
7. Image Gauge
8. Cropped Image Gauge
9. Cropped Circular Image Gauge
10. Multi Image Gauge
11. Color Fade Gauge
12. Status Gauge
13. Layer Group Gauge
14. Camera Gauge

Common Properties

All gauges share these common configuration properties:

Text Gauge

Displays static text on the screen. This gauge renders during the static content phase and does not change with channel values.

Configuration

Usage Notes

• Text is pre-rendered and cached for performance
• Static content only - no dynamic updates
• Ideal for labels, titles, and static indicators
• Uses the fast font rendering system

Example Use Cases

• RPM label above a value gauge
• Screen titles
• Unit indicators (km/h, psi, °C)
• Static warning messages

Value Gauge

Displays numeric channel values with optional decimal places and color thresholds.

Configuration

Behavior

• Displays “-” if channel doesn’t exist or value is NaN
• Supports both numeric and string channels
• String values use GetStringTexture for rendering
• Numeric values use font atlas for performance
• Color changes based on threshold comparison

Usage Notes

• Thresholds allow for visual warnings (e.g., red for high temperature)
• Font atlas provides fast rendering for numeric displays
• String channels display the raw string value

Example Use Cases

• Engine RPM display
• Temperature readings with warning colors
• Pressure gauges with threshold alerts
• Boost levels

Time Gauge

Displays time values in M:SS.mmm format (minutes:seconds.milliseconds) with threshold-based coloring.

Configuration

Behavior

• Input value is in seconds (supports negative values)
• Format: [-]M:SS.mmm
  • Minutes padded to 1 digit minimum
  • Seconds padded to 2 digits
  • Milliseconds padded to 3 digits
• Displays “-:–.—” if channel doesn’t exist or value is NaN
• Color changes based on threshold comparison

Usage Notes

• Designed for lap times, timers, and duration displays
• Supports negative times with “-” prefix
• Millisecond precision for racing applications

Example Use Cases

• Lap timers
• Split times
• Best lap comparison
• Countdown timers

Bar Gauge

Displays a filled bar that grows/shrinks based on channel value. Supports multiple directions and color modes.

Configuration

Supported Directions

• Left (0) - Fills from right to left
• Right (1) - Fills from left to right
• Up (2) - Fills from bottom to top
• Down (3) - Fills from top to bottom
• UpLeft (4) - Fills diagonally
• UpRight (5) - Fills diagonally
• DownLeft (6) - Fills diagonally
• DownRight (7) - Fills diagonally

Behavior

• Value is clamped between minValue and maxValue
• Fill ratio = (value - minValue) / (maxValue - minValue)
• invert flips the ratio (1 - ratio)
• MultiColour mode selects color based on current value

Usage Notes

• Perfect for analog-style gauges
• Diagonal directions allow creative layouts
• MultiColour provides visual zones (safe/warning/danger)

Example Use Cases

• Fuel level indicator
• Temperature bars
• RPM bars with color zones
• Battery charge indicators

Dial Gauge

Rotates an image around a pivot point based on channel value. Supports linear and non-linear angle mapping.

Configuration

AngleToValueMap

Behavior

• Linear mapping: Angle interpolates linearly between min and max
• Non-linear mapping: Uses custom mapping points for irregular scales
  • Points are sorted by value
  • Linear interpolation between mapping points
  • Angles outside range are clamped
• Direction affects angle sign (AntiClockwise negates angle)

Usage Notes

• Pivot point is relative to the gauge dimensions
• Image should be designed with needle pointing at 0 degrees
• Non-linear mapping useful for non-uniform gauge scales
• Supports values outside min/max range (clamped to limits)

Example Use Cases

• Traditional speedometer needles
• Tachometer needles
• Temperature gauge needles
• Fuel gauge needles with non-linear sweep

Image Gauge

Displays a static image. Can render in static or dynamic phase.

Configuration

Behavior

• Static rendering (forceForegroundRender = false):
  • Renders once during RenderStaticContent
  • Image never changes
  • Best performance for backgrounds
• Dynamic rendering (forceForegroundRender = true):
  • Renders every frame during RenderDynamicContent
  • Can layer on top of other dynamic gauges
  • Slightly lower performance

Usage Notes

• Use static rendering for backgrounds, frames, and decorations
• Use dynamic rendering when image needs to appear above other gauges
• Image is scaled to fit gauge dimensions (w × h)
• Supports transparency (PNG alpha channel)

Example Use Cases

• Background images
• Gauge bezels and frames
• Logos and branding
• Decorative elements

Cropped Image Gauge

Displays a progressively revealed image based on channel value. The image is “uncropped” as the value increases.

Configuration

Behavior

• Value is clamped between minValue and maxValue
• Ratio = (value - minValue) / (maxValue - minValue)
• invert flips the ratio
• Source and destination rectangles adjusted based on direction
• Only the visible portion is rendered

Supported Directions

Same as Bar Gauge: Left, Right, Up, Down, UpLeft, UpRight, DownLeft, DownRight

Usage Notes

• Image gradually appears based on value
• Different from opacity - only reveals portion of image
• Perfect for creative fill indicators
• Source image should represent “full” state

Example Use Cases

• Creative fuel gauges (image of fuel tank filling)
• Battery icons that fill up
• Progress indicators with custom graphics
• Temperature visuals (thermometer filling)

Cropped Circular Image Gauge

Displays an image with circular/radial cropping based on channel value. Creates a “pie chart” or “arc” effect.

Configuration

Behavior

• Renders image using triangular geometry from center point
• Image is UV-mapped to create circular reveal effect
• Linear mapping: Angle interpolates linearly between start and sweep
• Non-linear mapping: Uses custom mapping points
• Direction affects sweep direction

Technical Details

• Divides sweep into triangular segments
• Handles both horizontal and vertical edge tracing
• Supports full 360° sweeps (multiple rotations)
• Angles wrap around 2π radians

Usage Notes

• Best for circular gauges with image backgrounds
• Center of gauge (w/2, h/2) is the rotation pivot
• 0° angle points upward, increases clockwise by default

Example Use Cases

• Circular RPM gauges with gradient backgrounds
• Radial progress indicators
• Speedometer arcs
• Fuel level circles

Multi Image Gauge

Displays different images based on discrete channel values (acts like a switch statement).

Configuration

ValueWithFilename

Behavior

• Compares channel value (rounded) to each image’s value
• Displays first matching image
• If no match, nothing is displayed
• Only one image shown at a time

Usage Notes

• Values are rounded to nearest integer before comparison
• Useful for discrete states or modes
• Images should be same size for consistent display
• Order matters - first match wins

Example Use Cases

• Gear position indicators (1, 2, 3, 4, 5, 6, N, R)
• Drive mode displays (Eco, Sport, Race)
• Warning icons based on error codes
• State indicators (Off, Idle, Active, Error)

Color Fade Gauge

Fills a rectangle with color that transitions smoothly between three colors based on channel value.

Configuration

Behavior

• Value is clamped between Min Value and Max Value
• Three zones:
  1. Min Value to Mid Lower Value: Linear interpolation from Min Colour to Mid Colour
  2. Mid Lower Value to Mid Upper Value: Solid Mid Colour
  3. Mid Upper Value to Max Value: Linear interpolation from Mid Colour to Max Colour
• Color interpolation is RGB lerp (linear interpolation per channel)

Usage Notes

• Creates smooth color gradients
• Middle zone can be zero-width (midLowerValue = midUpperValue)
• Useful for visual feedback without numbers
• Fills entire gauge area

Example Use Cases

• Temperature warning lights (blue → green → yellow → red)
• Background status indicators
• Visual alarm states
• Mood lighting effects

Status Gauge

Displays text with colored background based on discrete channel values. Similar to Multi Image but with text.

Configuration

StatusText

Behavior

• Compares channel value (rounded) to each status text’s value
• Displays first matching text with its colors
• Background fills entire gauge area
• Text is pre-rendered and cached

Usage Notes

• Values are rounded to nearest integer before comparison
• Both foreground and background colors customizable
• Text is cached for performance
• Order matters - first match wins

Example Use Cases

• Gear position display (“N”, “1”, “2”, “3”)
• System status (“OK”, “WARNING”, “ERROR”)
• Mode indicators (“ECO”, “SPORT”, “RACE”)
• Boolean states (“ON”/“OFF”, “ARMED”/“DISARMED”)

Layer Group Gauge

Manages multiple layers (screens within screens) that can be switched via events. Each layer contains its own set of gauges.

Configuration

LayerConfig

Behavior

• Each layer has its own texture for off-screen rendering
• Only one layer is active/visible at a time
• Layer switching triggered by events:
  • Next Layer Event: Cycles to next layer (wraps around)
  • Prev Layer Event: Cycles to previous layer (wraps around)
  • Show Event: Jumps directly to specific layer
• Layers are rendered to texture, then copied to screen
• Both static and dynamic content supported per layer

Rendering Process

1. Set render target to layer’s texture
2. Clear texture
3. Render layer’s gauges (static or dynamic)
4. Restore render target
5. Copy layer texture to screen at gauge position

Usage Notes

• Layers are separate screens with independent gauge layouts
• Event-driven switching enables complex UI flows
• Each layer has its own texture (memory overhead)
• Default layer shown initially if specified
• Texture size matches layer dimensions (may differ from gauge size)

Example Use Cases

• Multi-page dashboards (Main, Performance, Diagnostics)
• Context-sensitive displays (Normal, Warning, Critical)
• Menu systems
• Wizard-style configuration screens

Camera Gauge

Displays live camera feed with optional flipping.

Configuration

Behavior

• Renders camera texture provided externally
• Does not render anything in static or dynamic phases
• Texture alpha controlled by gauge opacity

Usage Notes

• Camera texture provided externally (not loaded from file)
• Flip options useful for correcting camera orientation
• No static/dynamic rendering - only camera feed
• Scales camera feed to gauge dimensions

Example Use Cases

• Rear-view camera display
• Side camera mirrors
• Track camera feed
• Dash cam preview

Rendering Architecture

Two-Phase Rendering

The gauge system uses a two-phase rendering approach:

1. Static Content Phase

   • Rendered once or when screen changes
   • Text labels, backgrounds, static images

2. Dynamic Content Phase

   • Rendered every frame
   • Values, needles, bars, etc.
   • Updated based on channel values

Z-Layer Ordering

Gauges are rendered in order of their Z Layer property:

• Lower Z Layer values render first (background)
• Higher Z Layer values render last (foreground)
• Allows complex layering of gauges

Opacity and Blending

• Opacity range: 0-100
• Supports transparency in images and colors

Color Format

Colors are specified as hex strings:

• Format: "#RRGGBB" (e.g., “#FF0000” for red)

Best Practices

Layout

• Use alignment properties for precise positioning
• Consider screen resolution and scaling
• Group related gauges with similar zLayer values
• Use layer groups for complex multi-screen UIs

Visual Design

• Use color thresholds for warnings (value/time gauges)
• Use color zones for operational ranges (bar/colorfade)
• Maintain consistent opacity for visual hierarchy
• Use multi-state gauges (status/multiimage) for discrete values

Configuration

• Test with testValue during development
• Define clear min/max ranges for accuracy
• Use non-linear mapping for irregular scales

Troubleshooting

Common Issues

Gauge not appearing:

• Check channelId is valid
• Verify zLayer ordering
• Ensure opacity > 0
• Check xPos/yPos within screen bounds

Colors not working:

• Verify hex color format (#RRGGBB)
• Check opacity setting
• Ensure blend mode supported

Images not loading:

• Confirm file exists in images/ directory
• Check fileName spelling and case
• Verify image format (PNG recommended)

Performance issues:

• Move static elements to RenderStaticContent
• Reduce number of dynamic gauges
• Use simpler gauge types where possible
• Optimize image sizes

Layer group issues:

• Verify layer IDs are correct
• Check event IDs are unique and valid
• Ensure at least one default layer
• Confirm texture creation succeeded

Inertial Measurement Unit

Emtron ED Series Displays contain 6 axis Inertial Measurement Unit (IMU).

Output Channels

• G-Force Lateral
• G-Force Longitude
• G-Force Vertical
• Acceleration Lateral
• Acceleration Longitude
• Acceleration Vertical
• Angular Velocity X
• Angular Velocity Y
• Angular Velocity Z
• Roll
• Pitch
• Yaw

Calibration

1. Make sure car is parked on a flat level surface.
2. Click Zero Calibrate to put the IMU into calibration mode. The device will take 5 seconds worth of samples and find it’s vertical orientation. The calibration is stored in permanent memory in the device.
3. Once completed, G-Force Vertical should read close to 1.0G, while G-Force Lateral and G-Force Longitude should be 0.0G.
4. Drive the car forward and stop. G-Force Longitude should go positive when accelerating and negative when braking. G-Force Lateral should remain near zero.
5. If required, adjust the Yaw Orientation value until the Longitudinal and Lateral G-Forces are aligned correctly.

In Field Calibration: Conditional Logic can be used to generate the IMU Calibration Begin event. This allows the IMU to be calibrated from a keypad button or similar user input.

Filtering

Accelerometer Filter and Gyro Filter values control how filtered the IMU measurements are.Values are a percentage (0 - 99.9%). Higher filtering gives a cleaner signal, but slows down the signals rate of change. Use the least filtering you can get away with. Typical values would be 10-40 %

Lap Timing

The Lap Timing function outputs lap and timing data based triggered by lap beacon events.

Input Channels

• Speed Channel: Select the channel to use as the speed input.
• Lap Distance Channel: Optional - Select the channel to use as the lap distance input.

Note: Lap and Race distance can be calculated from the speed input channel.

Input Events

Three main events are used to control the lap timing function. These events can be triggered however you see fit. Typically they’re triggered by GPS position as configured in Track Setup.

Lap Beacon

• Triggers the start of a new lap.
• Triggers the update of Best Lap, Previous Lap, and Time Delta related channels.

Sector Beacon

• Triggers the start of a new sector within the current lap.

Finish Beacon

• Triggers the end of the current lap and sector. The Lap Timing system will wait for a new race to start.

Input Channels

Speed Channel

The selected speed channel is used to record speed data during the lap.

Lap Distance Channel

When Generate Lap & Race Distance Channels from Speed Channel is CHECKED, the Lap Distance and Race Distance channels hold values automatically calculated from the Speed Channel.

When Generate Lap & Race Distance Channels from Speed Channel is UNCHECKED, the selected Lap Distance channel is read and the data is stored in the current lap data.

Lap Count

If the Lap Count channel is generated and holds a non zero value, it is used to trigger the end of a race.

Finishing a Race

End on Lap Count

When the Lap Beacon event is triggered, and the Lap channel value equals the Lap Count channel value, the Current Lap (and sector) is ended. The Lap Timing system will wait for a new race to start.

End on Finish Beacon

When the Finish Beacon event is triggered, the Current Lap (and sector) is ended. The Lap Timing system will wait for a new race to start. This is useful for point to point or drag races.

Output Channels

The following channels are written to by the Lap Timing system.

• Lap
• Sector
• Best Lap
• Best Sector (up to 63 sectors)
• Prev 4 lap times
• Optimal Lap Time (sum of best sector times)
• Current Lap Time
• Speed Delta to Previous Lap
• Speed Delta to Best Lap
• Time Delta to Previous Lap
• Time Delta to Best Lap

LIN Bus

LIN Bus Configuration

Overview

The LIN (Local Interconnect Network) Bus configuration allows you to define frames and signals for LIN communication. LIN is a serial communication bus commonly used in automotive systems for low-speed, cost-effective data exchange.

Note: Currently, master mode only is supported. The system acts as the LIN master, controlling communication with slave devices on the bus.

Settings Tab

Bus Configuration

• Enabled: Turn the LIN bus on or off
• Baud Rate: Set the communication speed in bits per second (e.g., 9600, 19200). Typical values are 9600 or 19200 bps

Frames

Frames are the fundamental units of LIN communication. Each frame contains a PID (Protocol ID) and carries signals.

Frame List

Displays all configured frames with their names and period (update interval in milliseconds). Use Add Frame to create a new frame, or Import Frame to load a previously saved frame.

Frame Settings

Configure the following for each frame:

• PID (0-63): Unique identifier for the frame on the bus
• Name: Descriptive name for the frame (optional, helps identify frames in the list)
• Direction:
  • Publish: Master transmits, slaves receive
  • Read: Master receives from slaves
• Length: Data payload size in bytes (1-8)
• Period: How often the frame is transmitted (milliseconds)
• Checksum Type:
  • Classic: Standard LIN checksum
  • Enhanced: Extended checksum format

Frame Diagram

Visual representation of your frame layout showing how signals are distributed across the data bytes. Each colored line represents a signal, with a legend showing signal names below the diagram.

Signals

Each frame can contain multiple signals carrying data values.

Signal Configuration

• Bit Offset: Starting bit position within the frame
• Channel: Which data channel this signal maps to (or “NO CHANNEL” for unused signals)
• Type: Data format (Integer, Float32, Float64)
• Endianness: Byte order
  • Little Endian: LSB first
  • Big Endian: MSB first
• Factor: Scaling multiplier for the raw value
• Offset: Value offset to apply
• Length: Signal width in bits

Use Add Signal to add signals to a frame. The Export Frame button at the bottom saves the current frame configuration for reuse.

Math Functions

Settings

Evaluation

• Continuous — expressions are evaluated constantly at 100 Hz
• On Event — expressions are evaluated only when the assigned event occurs (uses a fixed 10 ms timeDelta)

Variable Name

This is the variable name that will become available for use in the expression. Names must match [a-zA-Z_][a-zA-Z0-9_]*.

Derivative

When checked, an additional variable will become available containing the derivative of the input channel. The derivative variable uses the standard variable name with a d prefix.

e.g. If the channel variable is EngineSpeed, then the derivative variable will be dEngineSpeed.

The derivative is computed from consecutive channel timestamps when the delta is at least 10 ms. If derivative is disabled, d{Name} is always 0.

Reset totalTime on

Optional event channel (Continuous mode only). When the event fires, totalTime is reset to 0 on the next evaluation so gen.* waveforms can restart without recompiling. This does not clear filter or integrator state.

Changing the expression text triggers recompile and a full state reset (totalTime, filters, integrators).

Expression Syntax

Expressions are written using emexpr, Emtron’s expression language for real-time signal processing. Expressions are compiled once, then evaluated each tick to produce a single numeric output channel.

Numeric Literals

Line comments are supported: // everything after is ignored

Constants

math.PI is also available as an alias for PI.

Arithmetic Operators

Comparison Operators

Returns 1 (true) or 0 (false).

Logical Operators

Logical operators short-circuit: in a && b, b is not evaluated if a is falsy; in a || b, b is not evaluated if a is truthy.

A value is truthy when it is not 0 and not NaN. NaN is falsy — use util.IfNaN or math.IsNaN when you need explicit handling.

Conditional (Ternary) Operator

condition ? valueIfTrue : valueIfFalse

Example: rpm > 3000 ? 1 : 0

Local Variables

Use let to declare intermediate values within an expression. Separate statements with ;.

let x = rpm / 60;
let y = x * 2;
y + offset

The last expression in the let body is the result.

Built-in Variables

Stateful Evaluation

Functions in the filter, calc, and gen namespaces maintain state across evaluations. Each call site gets its own independent state slot — two filter.Exponential calls in the same expression do not share memory:

filter.Exponential(A, 0.1) + filter.Exponential(B, 0.2)

Several filters seed their internal state from the first sample on the first tick, so the first output may equal the first input rather than a neutral value.

Math Utilities

All trig functions are in radians.

Filter Utilities

Calculus Utilities

Utility Functions

Signal Generators

Timed waveform generators. All use totalTime (seconds since first eval after compile or last reset event).

Example — smoothed test signal:

filter.LowPass(gen.Sine(1, 100, 0), 0.2)

OBD-II

OBD2 Scanner User Guide

Overview

The OBD2 Scanner module provides comprehensive vehicle diagnostics and data acquisition through the On-Board Diagnostics II (OBD2) protocol. This guide covers configuration, operation, and troubleshooting.

Table of Contents

• Quick Start
• Configuration
• Status Monitoring
• Supported Services
• Advanced Features
• Troubleshooting
• Examples

Quick Start

Prerequisites

• Vehicle with OBD2 port (1996+ vehicles in most regions)
• CAN bus connection to vehicle OBD2 port
• OBD2 adapter cable or direct CAN connection

Basic Setup

1. Enable OBD2 on CAN Bus

   • Navigate to CAN Bus settings
   • Enable OBD2 scanner on desired CAN bus (typically can0)
   • Set request interval (recommended: 100-200ms for standard polling)

2. Configure Service 0x01 (Current Data)

   • Enable Service ID: 1 (0x01)
   • Enable PID Discovery for automatic detection
   • Add PIDs you want to monitor (see Standard PIDs)

3. Test Connection

   • Check OBD2 Service Status channel
   • Should show “Connected” when receiving data
   • Check OBD2 Poll Rate to verify polling frequency

Configuration

CAN Bus Settings

CAN Bus: can0
├── OBD2 Enabled: Yes
├── Request Interval: 100ms (adjustable 50-1000ms)
└── Services:
    └── Service 0x01 (Show Current Data)

Service Configuration

Each OBD2 service (0x01, 0x09, 0x22, etc.) can be independently configured:

PID Configuration

For each PID you want to monitor:

Status Monitoring

Status Channels

Monitor OBD2 system health through these channels:

Global Status

Per-Service Status (Service 1-8)

Status Values

Disabled          = 0  // Service not enabled
Connected         = 1  // Receiving valid data
No Response       = 2  // Not receiving responses (timeout after 5x poll interval)
PID Not Supported = 3  // ECU reports PID not supported
Response Error    = 4  // Other communication error

Supported Services

Service 0x01: Show Current Data

Real-time engine and vehicle parameters.

Configuration:

• PID Width: 1 byte
• Supports batch requests (up to 6 PIDs per request)
• Supports PID discovery (recommended)

Common Use: Engine RPM, coolant temp, throttle position, vehicle speed

Service 0x09: Vehicle Information

Static vehicle identification data.

Configuration:

• PID Width: 2 bytes
• Single PID per request (no batching)
• Discovery optional

Common Use: VIN, calibration IDs, ECU name

Service 0x22: Read Data By Identifier (UDS)

Manufacturer-specific extended data.

Configuration:

• PID Width: 2 bytes
• Single PID per request
• Discovery not typically supported

Common Use: Custom manufacturer parameters, advanced diagnostics

Advanced Features

Multi-PID Polling (Batch Requests)

Request multiple PIDs in a single CAN message for faster polling.

Benefits:

• Higher effective poll rate
• Reduced CAN bus traffic
• Lower latency

Limitations:

• Only Service 0x01 supports this (per SAE J1979)
• Maximum 6 PIDs per request
• Must use physical addressing (0x7E0) not broadcast (0x7DF)
• Some ECUs may not support this feature

Configuration:

Service 0x01:
├── Batch PID Requests: Yes
├── TX Address: 0x7E0 (physical addressing required)
└── PIDs: [0x0C, 0x0D, 0x05, 0x0F, 0x10, 0x11]

Expected Poll Rate:

• 6 PIDs with 100ms interval = ~10 Hz per PID
• Without batching = ~1.6 Hz per PID

PID Discovery

Automatically detect which PIDs your vehicle supports.

How It Works:

1. System queries PID 0x00 (supported PIDs 0x01-0x20)
2. System queries PID 0x20 (supported PIDs 0x21-0x40)
3. Continues for PID ranges: 0x40, 0x60, 0x80, 0xA0, 0xC0
4. Only polls PIDs that are marked as supported
5. Falls back to polling all configured PIDs if discovery fails

Benefits:

• Faster polling (skips unsupported PIDs)
• Better compatibility
• Automatic adaptation to vehicle capabilities

Retry Logic:

• 3 retry attempts if discovery times out
• 2-second timeout per attempt
• Falls back to polling mode if all retries fail

Custom Decode Formulas

Convert raw PID data to engineering units using mathematical expressions.

Formula Variables:

• A = First data byte (0-255)
• B = Second data byte (0-255)
• C = Third data byte (0-255)
• D = Fourth data byte (0-255)
• E to H = Additional bytes if needed

Examples:

// Engine RPM (PID 0x0C, 2 bytes)
(A*256 + B) / 4

// Coolant Temperature (PID 0x05, 1 byte)
A - 40

// Throttle Position (PID 0x11, 1 byte)
A * 100 / 255

// Fuel Pressure (PID 0x0A, 1 byte, result in kPa)
A * 3

// Intake Air Temperature (PID 0x0F, 1 byte, result in °C)
A - 40

// MAF Sensor (PID 0x10, 2 bytes, result in g/s)
(A*256 + B) / 100

// O2 Sensor Voltage (PID 0x14, 2 bytes)
A / 200  // Voltage (V)
// B = Short term fuel trim (%)

// Vehicle Speed (PID 0x0D, 1 byte, result in km/h)
A

// Runtime since engine start (PID 0x1F, 2 bytes, result in seconds)
A*256 + B

// Fuel Tank Level (PID 0x2F, 1 byte, result in %)
A * 100 / 255

Standard PIDs

Service 0x01 Common PIDs

Service 0x09 Common PIDs

Troubleshooting

Connection Issues

“No Response” Status

Symptoms: Status shows “No Response” or never connects

Causes:

1. Vehicle not in RUN or ENGINE ON mode
2. Incorrect CAN bus connection
3. Wrong CAN bitrate (should be 500 kbps for OBD2)
4. CAN termination issues

Solutions:

1. Verify vehicle ignition is ON
2. Check physical CAN bus wiring (CAN-H and CAN-L)
3. Confirm CAN bitrate: 500 kbps or 1 Mbps
4. Check CAN termination (120Ω between CAN-H and CAN-L)
5. Try both physical (0x7E0) and broadcast (0x7DF) request addresses

“PID Not Supported” Status

Symptoms: Status shows “PID Not Supported” with error code 0x11 or 0x12

Causes:

1. Vehicle doesn’t support the requested PID
2. Service not available on this vehicle/ECU
3. PID configuration error

Solutions:

1. Enable PID Discovery to auto-detect supported PIDs
2. Check vehicle OBD2 compliance level
3. Try Service 0x01 PIDs first (universal)
4. Verify PID byte count matches specification
5. Some vehicles only support basic PIDs (0x00-0x20)

Low Poll Rate

Symptoms: OBD2 Poll Rate < 1 Hz, data updates slowly

Causes:

1. Too many PIDs configured
2. Request interval too high
3. Multi-PID batching disabled

Solutions:

1. Reduce number of active PIDs
2. Decrease request interval (minimum 50ms recommended)
3. Enable Batch PID Requests (Service 0x01 only)
4. Use physical addressing (0x7E0) for faster responses
5. Check OBD2 Response Rate - should be >80%

Low Response Rate

Symptoms: OBD2 Response Rate < 80%, intermittent data

Causes:

1. CAN bus errors or noise
2. ECU busy with other operations
3. Too short request interval
4. Poor connection quality

Solutions:

1. Increase request interval (try 200ms)
2. Check CAN bus wiring quality
3. Verify CAN termination
4. Monitor CAN bus load (should be <70%)
5. Check for CAN errors in bus statistics

Data Issues

Incorrect Values

Symptoms: Channel values don’t match expected ranges

Causes:

1. Wrong decode formula
2. Incorrect byte count
3. Byte order mismatch

Solutions:

1. Verify formula against OBD2 specification
2. Check byte count matches PID definition
3. Test with known PIDs first (RPM, Speed)
4. Compare with other scan tools
5. Check formula syntax (use A, B, C, D for bytes)

Flickering/Unstable Values

Symptoms: Values jump erratically between readings

Causes:

1. Poll rate too high causing data race
2. Formula error causing invalid calculations
3. CAN bus errors corrupting data

Solutions:

1. Increase poll interval
2. Verify formula produces valid output
3. Check CAN bus quality
4. Monitor OBD2 Response Rate for drops

Discovery Issues

Discovery Never Completes

Symptoms: Service stuck in “Disabled” state, never reaches “Connected”

Causes:

1. Discovery timeout (vehicle doesn’t respond to PID 0x00)
2. Vehicle doesn’t support discovery
3. Wrong service configuration

Solutions:

1. Wait for 3 retry attempts (6+ seconds)
2. Disable PID Discovery to skip auto-detection
3. Manually configure known PIDs
4. Check logs for timeout messages
5. Some vehicles require specific timing

Discovery Detects No PIDs

Symptoms: Discovery completes but no PIDs are polled

Causes:

1. Vehicle returned empty bitmap
2. No configured PIDs match supported PIDs
3. Discovery misinterpretation

Solutions:

1. Manually configure common PIDs (0x0C, 0x0D, 0x05)
2. Disable discovery and poll all configured PIDs
3. Try Service 0x01 PIDs 0x00-0x20 first
4. Check Supported PIDs bitmap channels for values

Performance Optimization

Maximizing Poll Rate

Goal: Achieve 10+ Hz poll rate for critical parameters

Strategy:

1. Enable Batch PID Requests (Service 0x01)
2. Use physical addressing (0x7E0)
3. Request only essential PIDs (6 maximum per batch)
4. Set request interval to 100ms
5. Ensure vehicle supports multi-PID requests

Expected Results:

• 6 PIDs @ 100ms interval = ~10 Hz per PID
• Total CAN messages = ~10/second
• Response rate should be >90%

Minimizing CAN Bus Load

Goal: Reduce CAN bandwidth usage

Strategy:

1. Increase request interval (200-500ms)
2. Disable unused PIDs
3. Use batch requests to consolidate messages
4. Prioritize essential parameters

CAN Load Calculation:

Single PID request = 1 frame (~10 bytes @ 500kbps = ~200µs)
Response = 1-8 frames depending on data size
Total per poll = 2-9 frames

Example: 10 PIDs @ 100ms interval
= 10 requests/second × 2 frames avg = 20 frames/sec
= ~4 kbps out of 500 kbps = <1% bus load

Balancing Multiple Services

Scenario: Monitor Service 0x01 (current data) and Service 0x09 (VIN)

Strategy:

Service 0x01:
├── Request Interval: 100ms
├── PIDs: High-frequency data (RPM, Speed, Throttle)
└── Batch Requests: Yes

Service 0x09:
├── Request Interval: 1000ms (slower)
├── PIDs: Static data (VIN, Calibration ID)
└── Batch Requests: No

Examples

Example 1: Basic Engine Monitoring

Monitor essential engine parameters.

Configuration:

Service 0x01:
  - Enabled: Yes
  - PID Discovery: Yes
  - Batch PID Requests: Yes
  - Request Interval: 100ms
  - TX Address: 0x7E0

PIDs:
  PID 0x0C (Engine RPM):
    - Channel ID: 60100
    - Byte Count: 2
    - Formula: (A*256+B)/4

  PID 0x0D (Vehicle Speed):
    - Channel ID: 60101
    - Byte Count: 1
    - Formula: A

  PID 0x05 (Coolant Temp):
    - Channel ID: 60102
    - Byte Count: 1
    - Formula: A-40

  PID 0x11 (Throttle Position):
    - Channel ID: 60103
    - Byte Count: 1
    - Formula: A*100/255

Expected Results:

• Poll Rate: ~10 Hz
• Response Rate: >90%
• 4 parameters updated 10 times per second

Example 2: Performance Logging

High-speed data acquisition for track use.

Configuration:

Service 0x01:
  - Request Interval: 50ms (20 Hz)
  - Batch PID Requests: Yes
  - TX Address: 0x7E0

PIDs (6 max per batch):
  - 0x0C: Engine RPM
  - 0x0D: Vehicle Speed
  - 0x10: MAF Air Flow
  - 0x11: Throttle Position
  - 0x0F: Intake Air Temp
  - 0x0B: Intake Manifold Pressure

Expected Results:

• Poll Rate: 20 Hz
• 6 channels @ 20 Hz = 120 samples/second total
• CAN load: ~2%

Example 3: Diagnostic Scan

Complete vehicle parameter survey.

Configuration:

Service 0x01:
  - PID Discovery: Yes
  - Request Interval: 200ms
  - Batch PID Requests: No (for maximum compatibility)
  - TX Address: 0x7DF (broadcast)

PIDs: All supported PIDs (auto-detected via discovery)

Service 0x09:
  - Request Interval: 5000ms
  - PIDs: 0x02 (VIN), 0x04 (Calibration ID)

Expected Results:

• Automatic detection of 20-40 supported PIDs
• Poll rate: 2-5 Hz depending on PID count
• VIN and calibration data refreshed every 5 seconds

Example 4: Manufacturer-Specific (UDS)

Access extended manufacturer parameters.

Configuration:

Service 0x22 (UDS):
  - PID Width: 2
  - PID Discovery: No
  - Batch PID Requests: No
  - TX Address: 0x7E0

PIDs (manufacturer-specific examples):
  PID 0xF190:
    - Description: "Boost Pressure"
    - Channel ID: 60200
    - Byte Count: 2
    - Formula: (A*256+B)/100

  PID 0xF191:
    - Description: "Fuel Rail Pressure"
    - Channel ID: 60201
    - Byte Count: 2
    - Formula: (A*256+B)*10

Note: Manufacturer PIDs vary by make/model. Consult manufacturer documentation.

Technical Reference

CAN Message Format

OBD2 Request (Single PID):

ID: 0x7DF (broadcast) or 0x7E0 (physical)
Data: [0x02, 0x01, 0x0C, 0x00, 0x00, 0x00, 0x00, 0x00]
       │     │     │
       │     │     └─ PID (0x0C = RPM)
       │     └─────── Service (0x01)
       └───────────── Length (2 bytes)

OBD2 Request (Multi-PID):

ID: 0x7E0 (physical addressing required)
Data: [0x04, 0x01, 0x0C, 0x0D, 0x05, 0x00, 0x00, 0x00]
       │     │     │     │     │
       │     │     │     │     └─ PID 3 (0x05 = Coolant Temp)
       │     │     │     └─────── PID 2 (0x0D = Speed)
       │     │     └───────────── PID 1 (0x0C = RPM)
       │     └─────────────────── Service (0x01)
       └───────────────────────── Length (4 bytes)

OBD2 Response:

ID: 0x7E8 (or 0x7E9-0x7EF for multiple ECUs)
Data: [0x04, 0x41, 0x0C, 0x1A, 0xF8, 0x00, 0x00, 0x00]
       │     │     │     │     │
       │     │     │     └─────┴─ Data bytes (0x1AF8 = 6904 → RPM = 1726)
       │     │     └───────────── PID echo (0x0C)
       │     └─────────────────── Response mode (0x41 = 0x01 + 0x40)
       └───────────────────────── Length (4 bytes)

ISO-TP Multi-Frame

For responses >7 bytes, ISO-TP (ISO 15765-2) is used:

First Frame:

[0x10, 0x14, 0x49, 0x02, 0x01, ...]
  │     │     └─────────────────── Start of data
  │     └───────────────────────── Total length (0x14 = 20 bytes)
  └─────────────────────────────── Frame type (0x1 = First Frame)

Consecutive Frames:

[0x21, data, data, data, ...]
  │
  └─ Sequence number (0x21 = frame 1, 0x22 = frame 2, etc.)

Negative Response Codes

Safety and Compliance

Legal Considerations

• Regional Compliance: OBD2 is mandated for vehicles sold in:

  • USA: 1996+
  • EU: 2001+ (gasoline), 2004+ (diesel)
  • Australia: 2006+
  • Other regions vary

• Emissions Testing: Tampering with OBD2 data may violate emissions regulations

• Warranty: Check vehicle warranty terms regarding aftermarket scanning

Best Practices

1. Non-Intrusive: Read-only monitoring doesn’t affect vehicle operation
2. Passive Scanning: This module only reads data, never writes
3. Standard Compliant: Follows SAE J1979 and ISO 15765-2 specifications
4. ECU Protection: Respects timeouts and retry limits to avoid ECU overload

Limitations

• Manufacturer-Specific Data: Some parameters require proprietary protocols
• Real-Time Constraints: Not suitable for safety-critical applications
• CAN Bus Priority: OBD2 messages are low priority; critical vehicle systems take precedence
• ECU Availability: Some ECUs may be busy and unable to respond immediately

Glossary

Additional Resources

Standards Documents

• SAE J1979: OBD2 Diagnostic Test Modes
• ISO 15765-2: Diagnostic communication over CAN
• ISO 14229-1: Unified Diagnostic Services (UDS)
• SAE J2012: Diagnostic Trouble Code Definitions

Tools and Validation

• Use OBD2 scan tool to verify vehicle responses
• Compare results with known-good scanner
• Monitor CAN bus with analyzer to debug issues
• Test with multiple vehicles for compatibility

Support

For additional help:

1. Check system logs for detailed error messages
2. Review CAN bus statistics for communication issues
3. Verify configuration against examples in this guide
4. Test with minimal configuration first (basic PIDs)

Revision History

PID Controllers

This guide explains how to configure and manage PID (Proportional-Integral-Derivative) controllers for process control. The guide covers how to set up controllers, assign channels, define conditions, adjust limits, configure gain tables, and monitor diagnostics for effective PID control.

Overview

A PID controller adjusts a process by calculating an error (difference between a desired set point and the measured process variable) and applying proportional P, integral I, and derivative D corrections to produce an output. This software allows you to configure multiple PID controllers, each with customizable channels, conditions, limits, and gain tables. Real-time diagnostic plots help monitor and tune controller performance.

Key PID Configuration Features

Adding and Deleting Controllers

• Add a Controller: Use the “Add Controller” button to create a new PID controller with a default name (“New Controller”). This adds a new controller to the system for configuration.
• Delete a Controller: Select a controller and use the “Delete Controller” button. Confirm the action to remove the controller. Ensure you select the correct controller to avoid accidental deletion.

Naming Controllers

• Assign a unique name to each controller in the “Name” field.
• Descriptive names (e.g., “Temperature Control” or “Speed Control”) help identify the controller’s purpose.
• Changes are saved automatically when you finish editing the name.

Input/Output Channels

Each PID controller requires four key channels:

• Input Channel: The measured process variable (e.g., current temperature).
• Set Point Channel: The desired target value (e.g., target temperature).
• Error Channel: The calculated difference between the set point and input.
• Output Channel: The controller’s output to adjust the process (e.g., solenoid duty cycle).
• Use the dropdown menus to assign appropriate channel IDs from your system. Ensure channels are correctly mapped to avoid control errors.

Conditions

Conditions define when the controller is active and how it behaves:

• Enabled When: Set a condition to enable or disable the controller (e.g., enable only when a specific sensor is active). Use the condition editor to define this logic.
• Disabled Output Value: Specify a numeric output value (e.g., 0) for when the controller is disabled, ensuring the system remains in a safe state.
• Integral Reset When: Define a condition to reset the integral term to zero (e.g., when the error exceeds a threshold), preventing integral windup.

Limits and Scaling

Fine-tune the PID terms and output with these settings:

• Proportional (P) Limits: Set positive and negative limits for the proportional term to cap its contribution (e.g., to prevent excessive corrections).
• Integral (I) Limits: Set positive and negative limits for the integral term to control accumulated error corrections.
• Derivative (D) Limits: Set positive and negative limits for the derivative term to manage rate-of-change corrections.
• Output Scalar: Multiply the final output by a scaling factor (default: 1) to adjust its magnitude.
• Output Offset: Add a fixed value (default: 0) to the final output for calibration or bias.
• Output Final Limits: Set positive and negative limits for the controller’s final output to ensure it stays within safe bounds.
• Enter numeric values for all limits and scaling factors, which are validated to ensure they are valid numbers.

Gain Tables

Gain tables allow you to define variable gains for the PID terms based on operating conditions:

• Feed Forward Table: Adjusts the feed-forward term, which provides a baseline output independent of error (e.g., for known system dynamics).
• P Gain Table: Sets the proportional gain P, which scales the error to determine the proportional correction.
• I Gain Table: Sets the integral gain I, which scales the accumulated error over time.
• D Gain Table: Sets the derivative gain D, which scales the rate of change of the error.
• Switch between tabs to edit each table. Enter values to define how gains vary (e.g., based on error magnitude or other parameters).

Derivative Mode

• Choose how the derivative term is calculated:
  • Derivative of Error: Uses the rate of change of the error (set point minus input).
  • Derivative of Measurement: Uses the rate of change of the input directly, which can reduce noise in systems with step changes in the set point.
• Select the mode from the dropdown in the “Miscellaneous” section.

Diagnostic Channels and Monitoring

Monitor controller performance with real-time diagnostic plots:

• Main Plot: Shows the input, set point, output, and error channels over time, helping you visualize the control loop’s behavior.
• Diagnostic Plot: Displays diagnostic channels for:
  • Feed-Forward (FF) Output: The contribution of the feed-forward term.
  • P Output: The proportional term’s contribution.
  • I Output: The integral term’s contribution.
  • D Output: The derivative term’s contribution.
  • P Gain: The current proportional gain value.
  • I Gain: The current integral gain value.
  • D Gain: The current derivative gain value.
• Assign channel IDs for these diagnostics using the dropdown menus in the “Diagnostic Channels” section. Ensure valid channels are selected for accurate monitoring.

Tips for Effective PID Tuning

• Start with Proportional Only: Set I and D to 0, then adjust P to achieve a stable but slightly oscillatory response.
• Add Integral for Steady-State Error: Gradually increase I to eliminate steady-state error, but watch for integral windup (use the “Integral Reset When” condition to mitigate this).
• Use Derivative Sparingly: Increase D to dampen oscillations, but avoid high values to prevent noise amplification. Consider “Derivative of Measurement” mode for noisy systems.
• Tune Gain Tables: Use gain tables to adjust P, I, and D based on operating conditions (e.g., higher P for larger errors).
• Monitor Diagnostics: Use the main and diagnostic plots to observe how each term (P, I, D) affects the output. Adjust limits if any term dominates unexpectedly.
• Test Conditions: Ensure “Enabled When” and “Integral Reset When” conditions are logical to prevent unintended controller behavior.
• Set Safe Limits: Use P, I, D, and final output limits to prevent excessive corrections that could damage the system.
• Iterate Gradually: Make small adjustments and test the system response, using diagnostic plots to guide tuning.

This guide covers the core PID configuration features to help you set up and tune controllers effectively.

Shift Lights

Shift Calculation

The shift calculation writes to the Shift Indication channel. The value progresses from 1 to 99, then 100 when the 100% value is met or exceeded. If you don’t want to use the shift calculation, set the input channel to ‘None’.

Shift Pattern

The shift patterns are selected based on the input channel value. The pattern with the nearest value equal to or less than the input channel value is displayed.

TIP: Drag the LEDs to copy the colours around

Speed Fusion

Speed Fusion

Overview

Speed Fusion combines data from multiple sensors to produce a single, accurate speed measurement that is more reliable than any individual source. It draws on GPS speed, drive speed (from the ECU or CAN bus), wheel speed sensors, and IMU data (accelerometer and gyroscope) to deliver a smooth, low-latency fused speed output.

Speed Fusion continuously monitors for wheel slip and automatically reduces the influence of any sensor that appears unreliable, such as a spinning driven wheel under hard acceleration.

Key Features

• Combines GPS, drive speed, wheel speeds, and IMU data into a single reliable output
• Automatically detects and discounts wheel slip
• Compensates for sensor drift over time
• Works with partial sensor sets — unused inputs can be left unconfigured

Configuration

Enable / Disable

Sensor Inputs

Assign each input to the channel that provides that sensor’s data. Leave a channel unassigned if that sensor is not available — Speed Fusion will simply use whichever sources are connected.

Wheel Drive Configuration

Indicate which wheels are driven (powered) by the motor. Speed Fusion prefers non-driven wheels for speed estimation because driven wheels are more likely to slip under acceleration.

Examples:

• Front-wheel drive: enable Front-Left and Front-Right
• Rear-wheel drive: enable Rear-Left and Rear-Right
• All-wheel drive: enable all four

When all wheels are driven, Speed Fusion still uses wheel speeds but treats them as less reliable and relies more heavily on GPS and drive speed.

Tuning Parameters

These settings control how much Speed Fusion trusts each sensor source, and how aggressively it detects wheel slip. The defaults are appropriate for most vehicles — only adjust these if you observe specific problems.

Sensor Trust

Lower values mean more trust in that source; higher values mean less trust. Think of these as a confidence level for each sensor’s accuracy.

Slip Detection

Tuning Guide

Starting Point

The defaults work well for most vehicles. Before adjusting anything, verify that all configured channels are receiving valid data and that sensor units are correct (speeds in kph, acceleration in m/s²).

Common Adjustments

Driving Style Adjustments

• Street or steady-state driving — use lower (default) responsiveness values for a smooth output
• Motorsport / high-dynamics driving — increase Speed Responsiveness to allow the estimate to change more quickly
• Off-road or rough terrain — increase sensor trust values to tolerate higher sensor noise

Troubleshooting

Switch Logic

Switch Inputs allow any input channel to be used for binary switch logic. The output is either 0 when inactive/off or 1 when active/on.

Input Channel

The channel used as the input value source.

Output Channel

The channel that contains the final result of the switch logic.

Detection Mode

Determines the switches behaviour.

• Active Low: Transitions to ON when the input is less than or equal to Low Threshold. Does not transition back to OFF until the input is greater than or equal to High Threshold. Typical use: Low side switch.
• Active High: Transitions to ON when the input is greater or equal to than High Threshold. Does not transition back to OFF until the input is less than or equal to Low Threshold. Typical use: High side switch.
• Active Inside Range: Transitions to ON while the input is greater than or equal to Low Threshold AND the input is less than or equal to High Threshold. Typical use: Voltage ladder switches such cruise control buttons or other steering wheel controls.
• Active Outside Range: Transitions to ON while the input is less than or equal to Low Threshold AND the input is greater than or equal to High Threshold. Typical use: Inverse voltage ladder. Can determine when single position is not pressed.

Note: Toggle mode will alter the behaviour described here. See below…*

High Threshold

Input comparison high value. Used by all Detection Modes. Must be greater than Low Threshold.

Low Threshold

Input comparison low value. Used by all Detection Modes. Must be less than High Threshold.

Range Hysteresis

Hysteresis value used on both the Low Threshold and High Threshold boundaries. Only applies to Detection Modes Active Inside Range and Active Outside Range.

Active Inside Range: The switch will turn ON when the input is inside the threshold boundaries. In order to turn off, the input must be less than Low Threshold - Range Hysteresis OR greater than High Threshold + Range Hysteresis. The activation window is effectively widend when in the ON state.

Active Inside Range: The switch will turn ON when the input is outside the threshold boundaries. In order to turn off, the input must be greater than Low Threshold + Range Hysteresis AND less than High Threshold - Range Hysteresis. The activation windows are effectively widend when in the ON state.

Toggle

Alters the behaviour of the output. When the input detection is determined to be in the ON state, rather than following that state, the output value will toggle from OFF to ON and ON to OFF with each successive transition. This allows a momentary switch or keypad button to toggle (latch) each time it is pressed.

Invert

Inverts the output result. OFF becomes ON and ON becomes OFF.

Tables

Tables function similarly to ECU tables, featuring an X and Y axis where channels are assigned as inputs.

The system looks up the corresponding table value and outputs it to the assigned channel. Values are interpolated between cells to ensure a smooth output.

There is no limit to the number of tables you can create.

Track Setup

Track Setup determines how GPS based Lap Timing functions.

Lap Timing and Track Setup are separated so that other systems can also generate the lap and sector beacons. This allows the use of other timing systems such as laser beacons.

Location Detection

Each track has a central GPS position. This allows the device to select the track as the active track when it detects itself inside the detection radius of a particular track.

Note: To use automatic track location detection, Startup Track Selection needs to be set to Auto Select Using GPS.

Alternatively, tracks can be selected manually by assigning events to the Select Previous Track Event and/or Select Next Track Event options.

Tracks

Tracks are essentially a collection of GPS coordinates that allow the device to output sector and lap beacons as well as zone detection.

Latitude / Longitude

The track’s Latitude and Longitude values are used to set the position of the map window as well as automatic location detection. To quickly adjust the position, click the Pick Position button and click the new postion in the map window.

Enabled

When the track is Enabled, it is included in the automatic search for the current location. Disabled tracks will be ignored. This allows multiple versions of the same track to exist in the config without confusing the automatic location detection system. For example you may have different versions with different sector or zone setups.

Zoom In / Out

The zoom in and zoom out buttons control the default zoom level of the track map view. The zoom level is stored in the config so unless the user pans or zooms the map with the mouse, the map will recentre on the tracks central GPS position and set zoom level.

Sectors

Sectors are made up of two position coordinates to create an imaginary line. When the device detects that it has crossed this line, it can output an event.

Predefined line types will output specific events:

• Start Finish Line → Lap Beacon
• Start Line → Lap Beacon
• Sector Line → Sector Beacon
• Finish Line → Finish Beacon
• Custom Line → User Defined (any event)

To create a new sector line:

1. Click Add Line.
2. Update the line type and name as needed.
3. Click the Pick Position button for Lat A / Long A.
4. Click the position in the map window for the lines A position.
5. Click the Pick Position button for Lat B / Long B.
6. Click the position in the map window for the lines A position.
7. If you’ve selected a Custom Line type, select the output event.

There are three important events used by the Lap Timing function. Appropriate use of these beacon events will result in accurate lap timing data. Using the preset line types will handle outputting the correct event for you.

Lap Beacon

When the Lap Beacon event is triggered, the Lap Timing function will initiate the start of a new lap.

Sector Beacon

When the Sector Beacon event is triggered, the Lap Timing function will initiate the start of a new sector within the current lap.

Finish Beacon

When the Finish Beacon event is triggered, the Lap Timing function will end the current lap and wait for a new lap to start. This is useful for point to point races or drag racing that do not have a common Start/Finish line.

Zones

Zones are polygonal areas or regions within a track or location.

ID

You can give each zone an ID number. This number does not have to be unique. When the device detects that it is inside a particular zone, it will output the zones ID to value to the Track Zone channel. When not inside a zone, Track Zone will revert to a value of 0. You can assign the same ID to multiple zones accross multiple tracks.

For example: If you wish to create a common pit speed limiter, you can draw a zone around the pit lane of multiple tracks and assign them a common ID number. Inside a conditional Logic function, you can check to see if the current Track Zone value is your designated Pit Lane ID.

You may with to add additional logic checks in the event the GPS fix is poor.

Enter and Exit Events

Optionally, the device can trigger events of your choosing when a zone is entered and/or exited.

Vertices

A zone is made up of a collection of vertices.

CautionZone polygons require at least 3 vertices to be valid

Wi-Fi

Default Network

By default the ED Series Displays will broadcast the following Wi-Fi networks.

Settings

The user can change the SSID and Passphrase freely.

Note: This change is stored in the device, independent of the loaded config.

Constants

Setup → Constants

Constants are fixed values published as channels on the display. Use them for car- or session-specific numbers that functions, gauges, and maths need — for example tyre circumference, gear ratios, or driver preferences — without hard-coding those values into each feature.

Constants are part of the configuration file. They are also written into every onboard log so analysis tools can use the same values that were active during the run.

Sections

Constants are organised into sections (for example Car, Driver, or Event).

1. Open Setup → Constants.
2. Use New section to add a section, and rename it as needed.
3. Select a section, then add channels and set each value.
4. Drag sections or entries to reorder them.

Each entry picks a channel and an explicit value for that channel. Only one constant should write a given channel.

Import and export

Tips

• Prefer clear section names so imports from multiple files stay organised.
• Use constants for values that change between cars or events, and leave function-specific calibration on the feature page itself.
• After changing constants, write the configuration to the display so the device and logs match Studio.

User Channels

Setup → User Channels

User channels let you define custom named channels for data that is not covered by the built-in channel list. They behave like any other channel — functions can read and write them, gauges can display them, and they can be logged.

Creating a Channel

1. Open Setup → User Channels.
2. Click Add to create a new channel.
3. Set the Name and select a Unit type.
4. Optionally assign an Enum to display human-readable text instead of numeric values.

Import and Export

User channel definitions can be exported and imported between configurations using the toolbar buttons. This is useful when sharing a common set of custom channels across multiple vehicle configs.

TIP: Prefer built-in channels where they exist. Built-in channels ensure compatibility when importing sub-configurations from other projects. Contact Emtron support to request addition of commonly needed channels.

See Channels and Events for guidance on when to use custom channels.

User Events

Setup → User Events

User events are discrete triggers — they fire at a point in time rather than holding a continuous value. Other functions listen for events to perform actions such as resetting a counter, switching a screen, or starting a log.

Creating an Event

1. Open Setup → User Events.
2. Click Add to create a new event.
3. Set the Name for the event.

User events can be triggered by conditional logic, switch logic, CAN receive mappings, keypad inputs, and other functions that support event outputs.

Import and Export

Like user channels, event definitions can be exported and imported between configurations.

See Channels and Events for more on how events differ from channels.

User Enums

Setup → User Enums

Enums map numeric values to display text. For example, a gear position channel might map 0 to “N”, 1 to “1st”, and so on. Gauges and live data views use enum labels when a channel is associated with an enum.

Creating an Enum

1. Open Setup → User Enums.
2. Click Add to create a new enum definition.
3. Set the enum Name.
4. Add Values — each entry pairs a numeric value with display text.

Enums are referenced from user channels, built-in channels (via enum associations), and status gauges on the display.

Enum Associations

Setup → Enum Associations

Enum associations connect built-in channels to enum definitions so that numeric values display as text. This is separate from user enums — it applies to the predefined channel list that ships with the display firmware.

Usage

1. Open Setup → Enum Associations.
2. Select a Channel from the built-in channel list.
3. Assign an Enum definition.

When the channel value is displayed in live data, logged data, or on a status gauge, the associated enum text is shown instead of the raw number.

For channels you create yourself, assign the enum directly on the User Channels page instead.

Vehicle Details

Vehicle Details has been replaced by Constants.

Use Setup → Constants to organise fixed channel values into named sections, import or export YAML, and publish those values on the device and into onboard logs.

CAN Bus

Inputs/Outputs → CAN

The ED7 and ED10 displays support multiple CAN bus ports. Each bus can be configured independently for baud rate, termination, and message routing.

Bus Configuration

Each CAN tab (CAN 1, CAN 2, etc.) provides:

Use the Comms Options panel to enable CAN diagnostic streaming, which shows raw bus traffic when a device is connected.

Receive Messages

CAN receive entries map incoming CAN frames to channels or events:

1. Select a bus tab.
2. Add a Receive message definition.
3. Set the CAN ID, byte layout, and scaling.
4. Assign the output Channel or Event.

Multiple receive definitions can exist on each bus. Emtron ECUs typically transmit on standard Emtron CAN IDs — the display ships with default receive templates for Emtron Display Tx Set 1 and Set 2.

Transmit Messages

CAN transmit entries send channel values on the bus at a configured rate:

1. Add a Transmit message definition.
2. Configure the CAN ID and byte packing.
3. Select the source Channel for each signal.

OBD-II

OBD-II scanning is configured as a CAN client on one of the bus ports. See the OBD-II guide for full setup and PID configuration.

Wiring Notes

• Use twisted pair for CAN High and Low.
• Terminate the bus with 120 Ω at each end only.
• Maximum recommended stub length is 0.3 m.

Refer to the ED10M or ED7M datasheet pinout for CAN wiring connections.

RS232

Inputs/Outputs → RS232

The display RS232 port supports serial communication with external devices such as GPS modules, lap timing systems, or custom peripherals.

Settings