Template:FTX Features

Driving behaviour

Crash detection

Introduction

The Crash Scenarios feature detects and logs vehicle crash events using accelerometer data. The device offers two primary crash detection methods:

• Basic Crash Detection – Monitors the X and Y axes for sudden spikes in acceleration.
• Advanced Crash Detection – Builds on Basic Crash but also captures additional metrics (e.g., direction, maximum/average acceleration) and uses all three accelerometer axes.
• A Crash Trace option is also available, which collects high-frequency accelerometer samples and GNSS data before, during, and after a crash, providing detailed insight into the event.

Prerequisites

Onboard IMU/Accelerometer

• The device must have a functioning IMU to measure accelerations accurately.

Firmware/Configuration Support

• Access to parameter configurations (e.g., 1024700 for enabling Basic Crash, 13102 for Advanced Crash) and the ability to enable Crash Trace.

GNSS Functionality (Optional)

• Required if you plan to capture concurrent GNSS data during a crash trace or rely on GNSS-based scenarios.

Parameter Description

Crash Scenario Threshold

• Basic Crash calculates the acceleration magnitude on X and Y axes only (to avoid triggering on gravity).
• Advanced Crash (when enabled) calculates magnitude on all three axes, typically resulting in higher measured values.

Basic Crash Detection

• Crash Event AVL ID: 247
• Crash Detection Priority (Parameter ID 1024700): Set to Low or High to enable/disable the scenario.

Threshold & Duration:

• When the accelerometer magnitude exceeds the configured threshold for the configured duration, the device flags a crash.
• The crash state continues until the acceleration drops 30% below the threshold (hysteresis) to prevent multiple crash events from small fluctuations.

Advanced Crash Detection

• Enabled if Basic Crash is enabled and Parameter ID 13102 is set to “enabled.”
• In addition to basic detection, it:
• Calculates crash duration and direction.
• Captures maximum and average magnitudes, plus amplitudes on each axis.
• These extended metrics are included in the same AVL record (ID 247) once the crash ends.

Crash Trace

• When Crash Trace is enabled, the device collects high-frequency accelerometer data (~400 samples/second) plus GNSS data (1 sample/second).
• Upon a crash event (AVL ID 247 with value = 1), data continues to be collected for a configured period before and after the crash.
• A second crash record (AVL ID 247, “full crash trace” type) is generated once all data is processed, accompanied by AVL ID 257 for accelerometer axis data.
• Crash Trace timestamps match the actual collection times, providing a detailed timeline of the event.

How It Works

Basic Crash Detection Flow

• IMU Reading: Each new acceleration vector is compared against the configured threshold.
• Threshold Exceeded: If the threshold is met or exceeded for the configured duration, the device flags a crash as “ongoing.”
• Hysteresis Check: The crash continues until acceleration falls 30% below the threshold.
• Crash Event: Once the acceleration returns below threshold, a Crash Event (AVL ID 247) is generated, and the crash is marked as ended.

Advanced Crash Detection Flow

• Basic Detection as Trigger: Advanced Crash runs alongside Basic Crash. When Basic Crash sees a threshold exceedance, Advanced Crash also begins data collection on all three axes.
• Extended Metrics: As long as the device is in a crash state, the algorithm accumulates samples to compute maximum and average magnitudes/amplitudes, as well as crash direction.
• Crash End & Record: When the crash ends (per Basic Crash hysteresis), Advanced Crash finalizes its calculations and outputs a single AVL record (ID 247) with the extended data fields.

Crash Trace

• Data Collection: Accelerometer (~400 Hz) and GNSS (1 Hz) data are continuously buffered.
• Crash Start: If a crash is detected, a preliminary Crash Event (AVL ID 247, value=1) is generated. The device continues collecting data for the specified time window after the crash trigger.
• Crash End: The device finalizes the crash trace data and generates a full crash trace record (AVL ID 247), which includes:
  • AVL ID 257: High-frequency accelerometer data.
  • GNSS PVT data.
  • Crash trace event type.
• Logging & Timestamps: The record’s timestamps correspond to the actual collection times, capturing the event’s progression before, during, and after the crash.

Records & Logging

• All crash scenarios culminate in event records with AVL ID 247.
• Advanced Crash adds extended crash metrics into the same event record.
• Crash Trace finalizes with an additional record containing AVL ID 257 for high-frequency accelerometer samples.

Overspeeding

Introduction

The Overspeeding scenario detects when a vehicle exceeds a configured maximum speed and generates a record. Another record is generated when the speed returns to normal.

• Purpose:
  • Promote safe and economic driving.
  • Provide real-time alerts on speed violations.
  • Generate automatic reports for fleet management.

How It Works

Speed Monitoring

• The system continuously monitors vehicle speed.
• If the speed exceeds the configured max speed by an allowed tolerance of 2 km/h, a record is triggered.

Event Recording

• A record is generated when:
  • The vehicle exceeds the max speed + 2 km/h.
  • The vehicle speed returns to normal (below max speed - 2 km/h).

Customization Options

• Max speed limit: Default is 90 km/h, but it can be customized.
• Record priority: Can be set to low or high (adjusted in Telematics Configuration Tool (TCT) under Features → Driving Behavior).
• Feature status: Disabled by default, must be manually enabled.

Prerequisites

To use the Over Speeding Scenario, the following must be met:

Feature Activation

• Enable the feature in Telematics Configuration Tool (TCT) under Driving Behavior.

Speed Configuration

• Configure the max speed limit and record priority as per requirements.

GNSS & Data Connectivity

• The device must have active GNSS tracking to monitor speed accurately.

Trip

Introduction

The Trip feature allows users to track vehicle journeys from start to finish based on a combination of ignition, movement, and speed parameters. During an active trip, the device maintains a running odometer (Trip Odometer), which is reset once the trip ends.

Prerequisites

Ignition and Movement Sources

• You must have proper Ignition and Movement sources configured in the device (e.g., ignition signal, GNSS, accelerometer) so that the device can detect when the vehicle is actually running and moving.

Trip Odometer I/O

• The I/O Trip Odometer must be enabled for the device to log distance traveled during a trip.

GNSS Connectivity

• Since Start Speed is tied to GPS speed, a functioning GNSS module is required for accurate speed measurements.

Parameter Description

Start Speed

• Defines the minimum GPS speed (in km/h) the vehicle must exceed to begin a trip.
• Default: 5 km/h

Ignition OFF Timeout

• Sets the time (in seconds) the system waits after the ignition source turns OFF before officially ending the trip.
• Default: 60 seconds

Trip Odometer

• An internal I/O value that tracks how far the vehicle travels between Trip start and Trip end.
• Automatically resets to 0 when a new trip begins.

How It Works

Trip Start

• The device monitors both Ignition (configured ignition source) and Movement (configured movement source).
• Once Ignition is 'ON', Movement is 'ON', and the vehicle’s GPS speed exceeds the Start Speed (default: 5 km/h), the trip is marked as “started.”

During the Trip

• The Trip Odometer increments continuously to reflect the total distance traveled.
• Any event triggers, such as data logging or notifications, will note that the vehicle is in an active trip state.

Trip End

• When the Ignition source turns OFF, the device starts the Ignition OFF Timeout countdown (default: 60s).
• If the ignition remains OFF for the entire timeout duration, the trip is ended.
• The Trip Odometer value is stored and then reset to 0 before the next trip begins.

Record Generation & Logging

• Depending on the device’s configuration, a record can be generated at Trip start and Trip end to facilitate reporting and analytics.
• Trip distance data is captured in the I/O Trip Odometer field, which is useful for fleet management or mileage reporting.

Odometer

Introduction

The Odometer scenario calculates the total distance traveled by a vehicle using GNSS data. To ensure accuracy and reduce system load, small thresholds are applied to both distance and speed. The device also performs a sanity check to confirm each new distance reading is valid and reasonable.

Prerequisites

GNSS Coverage

• A functioning GNSS module with an active fix is required to measure distance traveled.

Device Configuration Access

• You must be able to configure odometer parameters (e.g., ID 11807) and potentially format or reset the device’s non-volatile memory (NVM).

Parameter Description

Distance and Speed Thresholds

• Minimum distance to update: 2.5 meters
• Minimum ground speed to update: 0.42 m/s
• These thresholds prevent minor fluctuations from inflating the odometer reading.

Sanity Checks

• Timestamp Validation: The current PVT (position, velocity, time) data must be newer than the previous reading.
• Distance Spike Prevention: The device discards any reading suggesting a speed greater than 350 meters/second, as it indicates erroneous data.

Total Odometer Value (ID 11807)

• The total distance traveled is stored internally (in NVM) to preserve the odometer value.
• This value is written to memory every kilometer to reduce flash wear.
• Manually setting or resetting this parameter (via ID 11807) allows the odometer to start from a custom value.
• After formatting or resetting the NVM, the odometer value may be cleared unless reconfigured.

Min/Max Values for ID 11807:

• Minimum: 0
• Maximum: 4,294,967

How It Works

Odometer Updates

• As the vehicle travels, the device checks the GNSS-reported distance in increments. Once the minimum distance (2.5 m) and speed (0.42 m/s) thresholds are exceeded, it updates the total odometer.
• Every 1 km increment, the new odometer value is saved to NVM.

Data Validation

• Each new reading is compared against the previous PVT data. If the time is older or the speed exceeds 350 m/s, the reading is disregarded.
• This ensures only valid and realistic data points are recorded.

Odometer Preservation

• The total odometer value is maintained even if the device reboots or loses power, unless an NVM format or parameter reset occurs.
• To continue from a known distance, set the starting odometer value via ID 11807. The device will then count upward from that point.

Eco driving

Introduction

The Eco Driving scenario is designed to detect and analyze aggressive driving behaviors such as:

• Harsh acceleration
• Harsh braking
• Harsh cornering

It uses data from either an accelerometer or GNSS to track driving patterns. When a threshold is exceeded for a specific duration, the system generates an eventual record to highlight unsafe driving actions.

Prerequisites

Scenario Activation

• Must be enabled via Telematics Configuration Tool (TCT).

Proper Threshold Configuration

• Acceleration limits should be set according to driving policies.

GNSS & Sensor Calibration

• The device needs a stable GNSS fix or properly calibrated accelerometer for accurate event detection.

Parameter Description

Priority

• Defines the importance level of generated Eco Driving events.

Acceleration Source

• Specifies where the acceleration data is taken from:
  • Accelerometer → Uses data from the device’s built-in accelerometer chip.
  • GNSS → Uses speed and heading data from GNSS to calculate acceleration vectors.

Thresholds (Acceleration Limits in m/s²)

• Maximum allowed acceleration values before triggering an event:
  • Acceleration Threshold → Forward acceleration limit.
  • Braking Threshold → Backward acceleration limit.
  • Cornering Threshold → Side (left/right) acceleration limit.

How It Works

An Eco Driving event is triggered when all of the following conditions are met:

1. Scenario is enabled
2. Ignition is ON
3. GNSS fix is present
4. Vehicle speed is above 10 km/h for the event’s duration
5. Acceleration exceeds the configured threshold and stays above it for at least 0.5 seconds
6. Acceleration drops below the threshold and stays there for 0.5 seconds

Once an event is detected:

• A new record is generated, identifying the type of Eco Driving event.
• The following IO parameters are updated:
  • Eco Driving type (AVL ID 253) → Identifies event type:
    • 1 = Harsh acceleration
    • 2 = Harsh braking
    • 3 = Harsh cornering
  • Eco Driving value (AVL ID 254) → Records the peak acceleration value (measured in hundredths of g).

Scenario States

The system operates as a state machine with 4 states:

1. Idle → No event detection (vehicle speed too low, no GNSS fix, ignition off, etc.).
2. Eco → Normal driving, acceleration remains within safe thresholds.
3. Harsh → Acceleration exceeds the limit, but event isn't registered yet (prevents false positives).
4. Cooldown → Acceleration has dropped back but might spike again; prevents rapid, repeated event logging.

If the acceleration remains high beyond the cooldown period, the event is officially recorded.

Additional Notes & Edge Cases

Repeated Accelerations in the Same Direction

• If multiple harsh acceleration spikes occur within 0.5 seconds, they are considered part of the same event rather than separate ones.

Speed Drops Below 10 km/h

• If speed drops below the activation speed during an ongoing event, further acceleration values are ignored until speed increases again.
• This might result in:
  • The peak acceleration not being recorded accurately.
  • No event being logged at all, depending on conditions.

Directional Independence

• Each movement direction (forward, backward, left, right) is analyzed separately.
• Example:
  • A left-turn event does not interfere with acceleration/braking event detection.

Conclusion

The Eco Driving scenario helps businesses monitor and reduce aggressive driving behaviors

By logging harsh acceleration, braking, and cornering, fleet managers can:

• Improve driver safety
• Reduce vehicle wear & tear
• Lower fuel consumption
• ️Encourage responsible driving habits

Identification scenario

Parameter Description

Authorized Devices List

• Maintains a list of devices that have been authenticated and are permitted to connect or be recognized without further checks.
• When a new device is approved, it’s added to this list.

Scenario functionality can be divided into 5 states:

• Idle
  • Waits for detection or expiration events.
  • If a device detected event occurs, transitions to Authorization.
  • If a device expired event occurs, transitions to Device Expired.

• Authorization
  • Triggered when a new device is detected.
  • Checks if the device is authorized:
    • If not authorized, it returns to Idle (no record generated).
    • If authorized and first occurrence, transitions to Device Online.
    • If authorized and subsequent occurrence, transitions to Device Update.

• Device Online
  • Generates a "Device Online” record (e.g., AVL) for an authorized device’s first recognition.
  • Moves the device to the “already authorized devices” list.
  • Returns to Idle.

• Device Update
  • Reached if the device is authorized and not in its first occurrence.
  • Updates the device record to reflect the new detection time or any changes in state.
  • Returns to Idle.

• Device Expired
  • Triggered if the device’s authorization has ended (e.g., time limit expired or device removed from the system).
  • If the device is still in the authorization list, generates a “Device Expired” record and removes the device from the authorized list.
  • Returns to Idle.

Record Generation

• Periodic or Eventual: Records related to device detection can be configured with different priorities—Low (periodic) or High (immediate).
• Record Types:
  • Device Online
  • Device Update
  • Device Expired

Accelerometer calibration scenario

Introduction

The Accelerometer Calibration Scenario is used to determine the tracker’s position and orientation within a vehicle and reorient the tracker to the vehicle’s coordinate system. This ensures that acceleration measurements align correctly with the vehicle’s axes:

• X-axis → Forward/Backward
• Y-axis → Left/Right
• Z-axis → Up/Down

By calibrating the accelerometer, the system can accurately interpret vehicle movements, reducing errors caused by varying device installation orientations.

Accelerometer Calibration Working Principle

The scenario relies on GNSS and accelerometer data. Since most devices do not have a gyroscope, these are the primary sources for orientation detection. The algorithm collects two types of accelerometer data:

Movement with Acceleration:

• When the vehicle moves straight while accelerating or decelerating, this data helps determine the front and back direction.

Movement Without Acceleration:

• When the vehicle moves without acceleration, it allows the system to determine the ground vector.

Because devices can be mounted in various ways, they do not inherently know the directions of the vehicle’s front, back, left, right, up, and down.

The GNSS module helps detect whether the vehicle is moving straight or turning. It provides speed and direction relative to the north. If the vehicle moves straight with an increasing or decreasing speed, the system collects acceleration vectors.

Once a sufficient number of data points are collected:

• The forward vector is calculated.
• The ground vector is determined.
• The device’s orientation in the vehicle coordinate system is established.

This allows for the calculation of quaternions, which express the device’s rotation within the vehicle. These quaternions are then applied to new accelerometer readings, ensuring they align with the vehicle’s coordinate system.

As a result, all future accelerometer data correctly reflect the vehicle’s motion:

• X-axis → Forward/Backward
• Y-axis → Left/Right
• Z-axis → Up/Down

Prerequisites

Before running the Accelerometer Calibration Scenario, ensure the following conditions are met:

Device Compatibility:

• The device must have a built-in accelerometer and GNSS module.
• The scenario must be enabled in the configuration settings.

Firmware & Configuration:

• The device must be running a firmware version that supports accelerometer calibration.
• The calibration process should be properly configured in the device settings.

GNSS Requirements:

• A valid GNSS fix is required.
• The GNSS must provide speed and direction relative to the north.

Vehicle Movement Conditions:

• The vehicle must move in a straight line with acceleration to determine the front and back direction.
• The vehicle must also move without acceleration to establish the ground vector.

Data Collection:

• A sufficient number of accelerometer samples must be collected for accurate calculations.
• The calibration process relies on low-angle change movement detected via GNSS.

Environmental Considerations:

• The device should be mounted securely in the vehicle to avoid incorrect readings.
• External interference affecting GNSS or accelerometer accuracy should be minimized.

Excessive idling

Introduction

Scenario used to detect when a vehicle is stopped for a long time with a running engine, which is bad for fuel consumption and environmental effects.

Prerequisites

This scenario uses two global configuration parameters to work:

1. Ignition source – That is used to detect if a vehicle is on or on.
2. Movement source – That is used to detect if a vehicle is moving or not.

Ignition detection is determined by ignition source in system settings. Movement detection is determined by Movement source system settings.

For this scenario ignition is used as is, but there are modifications to the movement parameter. Movement will be also detected when there is GNSS fix and ground speed is more than 5 km/h. This option is not configurable and cannot be turned off.

Scenario can be in 1 of 2 states:

• Moving - inactive state. Vehicle is moving or stopped, but time to stop timeout has not been reached yet. Will also be forced when ignition is OFF;
• Idle - active state. Vehicle is stopped or moving, but time to movement timeout has not been reached yet.

Parameter description

Priority:

• Low – Event will be sent together with periodic records according to data acquisition settings.
• High – Event will be sent immediately not considering for data acquisition settings.

Time to 'stopped' (s) - The time in seconds for how long vehicle should not move with the ignition ON (by "Ignition source") to enter the excessive idling state.

Time to moving – The time in seconds for how long vehicle should move with the ignition ON (by "Ignition source") to exit the excessive idling state.

Vehicle protection

Network Jamming

The Jamming Detection scenario identifies instances of active GSM signal jamming on the device. The modem performs continuous jamming detection and reports any suspicious activity back to the main device.

Network jamming detection serves as a useful tool, which provides the crucial benefits of preventing cargo or vehicle theft, ensuring driver safety, and maintaining uninterrupted data flow.

When GSM signal jamming is detected, Network Jamming scenario activates. Then it starts a configurable jamming detection delay before generating jamming event. It is intended to reduce false positives. After the timeout ends, the device generates an event record. SMS notification Additionally, if digital output is configured, it activates already installed measures to inform driver or disrupt thieves ( like buzzer, LED indication, locking all doors etc. ).

Prerequisites and Important Settings

• The modem has jamming detection enabled at all times.
• Network Jamming won’t work with Deep Sleep and Power off sleep modes turned ON. Make sure to check information in Power saving settings.

Basic operation

• The modem continuously always monitors the network, scanning for potential jamming events.
• Network Jamming detection scenario activates when GSM signal jamming is detected.
• When GSM signal Jamming is detected, Time until jamming reporting (s) counter starts. It can be configured by user. It is intended to reduce false positives of jamming events.
• If detected jamming event lasts after entire delay period, device creates a High or Low priority record labeled “Jamming started”. Additionally, if output control is configured, it will activates already installed measures to inform driver or disrupt thieves (like buzzers, LED indication, locking all doors etc.).
• As soon as jamming stops (after a “Jamming started” record was generated), the device creates a “Jamming ended” record. It is sent immediately if priority level is set to High.
• Eventual records function lets user choose between sending eventual records of Jamming when enabled. And if disabled – eventual and periodic records are being sent bout Jamming.
• After jamming event has ended, modem continues monitoring for further jamming events.

Parameters list

PARAMETER NAME	PARAMETER ID (RELATED AVL ID)	DESCRIPTION	VALUES
Network jamming detection	1024900 (249)	The feature detects GSM jamming, initiates actions using an output, and helps to prevent vehicle theft when jamming devices are used. A low signal level is not equal to GSM jamming, the device recognizes these events.	0 = Disable Disable scenario. 1 = Low priority Device makes an additional record with indication of event cause. 2 = High priority Device makes an additional record with high priority flag and immediately sends an event packet to the server by GPRS.
Time until jamming reporting (s)	11305	Jamming - network signal disruption. Time until jamming reporting is the time between jamming being detected and the record creation. Value in seconds.	Minimum value = 0 Maximum value = 65535 Default value = 60
Eventual records	1024904	Enables feature status sending only when the event happens (an eventual record). When disabled, feature status will be sent with both eventual and periodical records.	0 = Disable 1 = Enable

Unplug detection

Introduction

Unplug Detection is a feature that identifies when a device transitions between being powered by external voltage and running on internal power only. The device generates a record (AVL ID 252) with a configured priority whenever it is plugged in or unplugged.

Prerequisites

External Power Source

• The vehicle or external system must provide a stable voltage supply that can be monitored by the device.

Configuration Access

• You need the ability to configure unplug detection parameters to choose between Simple and Advanced modes and to set the event priority.

Accelerometer (for Advanced Mode)

• If Advanced unplug detection is used, an onboard accelerometer must be present and enabled to combine voltage changes with motion data.

Parameter Description

Unplug Detection Mode

• Simple
  • Monitors external voltage to determine when the device is plugged or unplugged.
  • Recommended for vehicles where power voltage does not depend on ignition status.
• Advanced
  • Monitors both external voltage and accelerometer data.
  • Suitable for vehicles where power voltage is disconnected when ignition is off; the accelerometer helps confirm unplug events more reliably.

AVL ID 252

• The record ID generated when the device is plugged or unplugged.
• The user can configure priority (Low, High, etc.) to decide how the record is reported and logged.

How It Works

Simple Mode

• The device regularly checks the external power line.
• When external voltage is lost (drops below a configured threshold), the device deems itself unplugged and generates a “Power Unplugged” record.
• When external voltage returns (exceeds the threshold), the device deems itself plugged and generates a “Power Plugged” record.

Advanced Mode

• The device monitors both external voltage and the accelerometer.
• If external power is lost but the accelerometer indicates movement or vibration (e.g., ignition turned off in some vehicles), the device can confirm that an unplug event truly occurred.
• When power is restored along with the lack of movement, or once the system stabilizes, a plugged event is generated.

Record Generation & Logging

• Whenever a change in power source state is detected (plugged or unplugged), an AVL ID 252 record is created with the configured priority.
• Depending on the priority level, the device may send the record immediately (High priority) or with the next scheduled data batch (Low priority).

Auto Geofence

The Auto Geofence feature automatically creates a circular geofence zone around a vehicle's last known location after it has been stationary for a specified period. The system then generates alarm events if the vehicle moves outside this zone, or if it moves for a sustained period without a valid GNSS signal.

This functionality offers a dynamic layer of security against theft, particularly unauthorized towing, as it arms itself automatically based on vehicle behavior rather than ignition status. It is highly valuable for asset protection where vehicles make frequent, unscheduled stops. The ability to trigger an alarm even without a GNSS fix provides a crucial advantage in scenarios where a signal might be intentionally jammed or lost.

The feature operates in two main states. In its "Wait State," it monitors for the vehicle to become stationary with a valid GNSS fix. Once this condition is met for a configured timeout, it creates the geofence and enters the "Active State." In the Active State, it monitors for breaches. The feature can be deactivated and returned to the Wait State by various configurable triggers, such as a change in voltage, a digital input, or the presentation of an authorized iButton.

Prerequisites and Important Settings

• The device must have a reliable GNSS signal and be able to detect its movement status for the feature to arm correctly.
• If using a deactivation source such as a Digital Input (DIN) or iButton, the corresponding hardware (e.g., ignition connection, iButton reader) must be properly installed and configured.

Basic Operation

The feature's logic is divided into two distinct operational states: Wait State and Active State.

• Entering the Wait State (Arming Process):
  • The system starts in the Wait State. It continuously checks for two conditions to be met simultaneously: the device must have a valid GNSS fix, and the vehicle must be stationary.
  • Once both conditions are met, an "Activation timeout" timer begins. If the vehicle moves or loses its GNSS fix at any point, the timer resets.
  • When the timer successfully completes, the device creates a circular geofence of a configured "Radius" centered on its current location.
  • Depending on the configuration, an "On Enter" event record can be generated at this point. The system then transitions to the Active State.
• Active State (Monitoring and Alarm Trigger):
  • While in the Active State, the geofence is armed. The system monitors for two primary breach conditions:
    • Condition A: The device has a valid GNSS fix, and its current position is outside the created geofence.
    • Condition B: The device does not have a GNSS fix, but it detects continuous movement for the duration of the "Activation timeout".
  • If either of these conditions is met, an "On Exit" event record is generated (if configured), and the system returns to the Wait State.
• Deactivation:
  • The armed geofence can be deactivated, returning the system to the Wait State without generating an alarm. This is achieved when a configured "Deactivate by" source is triggered (e.g., Digital Input 1 becomes active).

Parameters list

PARAMETER NAME	PARAMETER ID (RELATED AVL ID)	DESCRIPTION	VALUES
Auto geofence	1017500	Disables, or enables and sets priority for record generation.	0 = Disable scenario. 1 = Low priority Device makes an additional record with indication of event cause. 2 = High priority Device makes an additional record with high priority flag and immediately sends an event packet to the server by GPRS.
Generate event	20001	Defines when the event will be generated	0 = On exit 1 = On enter 2 = On both
Activation timeout (s)	20002	Sets the duration in seconds for two conditions: 1. In Wait State: how long the vehicle must be stationary with a GNSS fix before the geofence is armed. 2. In Active State: how long the vehicle must be moving without a GNSS fix to trigger an alarm.	Minimum value = 0 Maximum value = 65535
Radius (m)	20003	Sets the radius of the circular geofence in meters, measured from the vehicle's position when armed.	Minimum value = 0 Maximum value = 1000000

Limitations, Edge Cases & Additional Notes

• Stuck in Wait State: The feature will never arm if the conditions are not met. This can happen if the vehicle is constantly moving or if it is parked in a location with no GNSS signal (e.g., an underground garage).
• Movement without GNSS: A key capability of this feature is generating an "On Exit" alarm if the vehicle moves for a sustained period without a GNSS fix. This is a critical security measure against signal jamming or loss.
• Deactivation Source: The chosen deactivation source is the only way to disarm the feature without triggering an alarm (aside from staying within the geofence). Ensure the source aligns with the intended use case (e.g., using a Digital Input connected to the ignition).

Manual Geofence

Manual geofence is a feature that monitors the location of the vehicle and triggers an event when the vehicle enters or exits any geofence zone, manually created on a map in the TCT.

Manual geofences are useful to get notified when the tracker enters or leaves a certain area, or exceeds a speed limit in such an area. This can help ensure driver compliance with predefined routes and speed limits.

When the vehicle crosses a geofence boundary (enters, exits, or in both cases), or exceeds the pre-defined speed limit, the device generates a record. There can be up to 50 geofence zones. Geofences can be circles or squares, defined by coordinates and border widths.

Prerequisites and Important Settings

• In Manual Geofence square and circle shapes can be used for creating a geofence and have their own different parameters.

Basic Operation

Each configured Manual Geofence scenario runs every second and checks if its conditions are met. The geozone tracks two main states:

• In-Zone: Indicates whether the device is inside the geozone. (If "Event type" is configured On Exit|On Entrance|On Both)
• Speeding: Indicates whether the device is exceeding the speed limit while inside the geozone. (If "Speed limit" is configured)

When a state change occurs (entering/exiting the geozone or starting/stopping speeding), an event is recorded. The frame border prevents false exit detections. Eventual record will contain these AVL IDs:

• 155 - used to identify the specific manual geofence scenario, which generated the event:
• 156 - In-zone event. Is added to the record if an in-zone event was captured. Possible values:
  • 0 - Exit event;
  • 1 - Enter event.
• 157 - Speeding event. Is added to the record if a speeding event was captured. Possible values:
  • 0 - Speeding stop event;
  • 1 - Speeding start event.

Parameters list

NOTE: parameter IDs in the table below are given for Geozone 1, as an example. I.e., here some parameter IDs are identical for both circle and rectangle shapes, since geozeone parameter IDs are calculated using formulas, based on the number of a geozone. See below [link] for geofence parameter ID calculation.

Will be added soon.

Geozone Parameter ID Calculation

Geozone-specific parameter IDs start from 900000. Each geozone has 100 reserved parameter IDs, e.g. Geozone 1 parameter ID range is 900000-900099, Geozone 2 – 900100-900199, etc. Parameter IDs have a reserved offset that is used for ID calculation:

Will be added soon.

The formula for a parameter ID is: parameter_id = 900000 + (geozone_number – 1)*100 + id_offset

Examples:

• Priority of Geozone 1:

900000 + (1 - 1) * 100 + 0 = 900000

• Speed limit threshold of Geozone 2:

900000 + (2 – 1) * 100 + 7 = 900107

Towing detection

Introduction

This scenario detects when a vehicle is being towed, whether it is lifted at an angle or as a whole. The detection is based on accelerometer data and external triggers such as ignition and movement.

Prerequisites

To ensure proper operation, the following conditions must be met:

1. Ignition Source – Used to detect whether the vehicle is turned ON or OFF.
2. Movement Source – Used to determine if the vehicle is moving or stationary.
3. Accelerometer Data – The device must have a working accelerometer to detect changes in orientation and movement.

How It Works

• The scenario activates when the ignition is OFF and stops if the ignition turns ON.
• It monitors the accelerometer data for sudden angle changes or movements that indicate towing.
• If the vehicle remains in a towed state for a configured duration, an event is recorded
• Once the towing stops, the scenario logs an event

Scenario States

Waiting for Activation:

• The scenario starts when ignition is OFF.
• It waits for a configured activation delay before monitoring accelerometer data.

Monitoring for Towing:

• When the first valid accelerometer reading is received, the device sets a reference vector (baseline position).
• It continuously checks if an angle or movement threshold is exceeded.

Towing Detection:

• If the threshold is exceeded for the configured duration, the scenario moves to the active towing state and logs an event.

Towing Active State:

• The device waits for movement to stop before resetting.
• If movement resumes, the timer resets, extending the active state.
• If no movement is detected for the configured Movement Stop Delay, the scenario logs a towing end event

Reset & Restart:

• After detecting the end of towing, the scenario resets and returns to the waiting for activation state.

Other features

Fall Down Detection

Fall down detection is a feature which is used to detect when a two-wheeler vehicle has fallen over. The scenario uses a combination of accelerometer sensor and GNSS data to determine whether the physical orientation of the vehicle changed in such a way, that would indicate a fall down event.

The feature allows to improve safety of the end user, by sending events to the fleet tracking platform indicating that the equipment has fallen over. It can help business meet safety regulations while also helping to keep riders and their equipment safe.

This is achieved by the device acquiring a base vector, which will serve as a reference point for when the two-wheeler is upright. This vector is acquired by measuring the accelerometer readings when the GNSS fix is available, GNSS ground speed is 0 and no movement is detected. Once the base vector is acquired, the device will constantly monitor the readings of the accelerometer to calculate the current vector. If the difference in angle between the base vector and the current vector exceed the configured values, a fall down event will be generated and sent to the server.

Prerequisites and Important Settings

• All accelerometer-related features, including fall down detection depend on secure device mounting to function properly. See “Mounting recommendations” [link].
• Movement source settings are vital for proper functioning of the feature, since base vector will only be calculated when movement, according to movement source is not detected.
• It is important to note, that a valid GNSS fix is also neccessery for proper base vector acquiring. Due to this reason, it is not possible for the device to acquire a base vector indoors, for example, inside a garage.
• If the device is remounted to another vehicle, the base vector will have to be recalculated. Base vector recalculation can be initiated via the SMS/GPRS command fall_down_reset.

Basic Operation

• Once the feature is enabled, the device waits until the conditions for base vector calculation are met.
• Once a valid GNSS fix is available, ground speed is 0 m/s and no movement, according to the configured movement source is detected, the device initiates base vector calculation.
• The device continuously reads IMU acceleration vectors, until a sufficient number of measurements have been taken.
• Once the base vector is established, the device will continuously read the current vector and compare it to the base vector.
• Once the base vector is established, the device will continuously read the current vector and compare it to the base vector.

If a the angle difference is greater than the configured Activation Angle for more seconds than the configured Activation Timeout, a fall down event will be generated.

• Once the base vector is established, the device will continuously read the current vector and compare it to the base vector.

Once the angle difference returns to a value below the configured Activation Angle, the fall down event is considered over. The device returns to the monitoring state.

Parameters list

PARAMETER NAME	PARAMETER ID (RELATED AVL ID)	DESCRIPTION	VALUES
XXX	XXX	XXX	XXX
Eventual Records	1024400	Defines whether eventual records are generated (Disable) or whether the status of the fall down event is sent with each periodic record	0 = Disable 1 = Enable
Activation angle (deg)	12102	Sets the angle difference, which should be detected between the base vector and the current vector in order to generate a fall down event.	Minimum value = 30 Maximum value = 180 Default value = 30
Activation timeout	12103	Sets the timeout, for how many seconds the difference in angle between the base and current vector should be exceeded before generating a fall down event.	Minimum value = 0 Maximum value = 3600 Default value = 3
Generate event	12110	The parameter defines under what condition (operand) the event will be generated.	0 = On exit Fall down event will be generated once the fall down event ends. 1 = On enter Fall down event will be generated once the fall down event begins. 2 = On both Fall down events will be generated once the event begins and when it ends.

Static navigation

Introduction

Static Navigation helps eliminate minor “jumps” in GNSS data when the vehicle or device is actually stationary. Because GNSS signals can fluctuate, your device might appear to move slightly even when it’s not moving at all. With Static Navigation, speed and position changes are filtered out to provide a more accurate representation of a stationary vehicle.

How It Works

Check Movement Status

• The device looks at its movement source (e.g., built-in accelerometer, speed reading from GNSS, etc.).
• If this source indicates the device is not moving, the system enables Static Navigation (assuming you’ve enabled it in the configurator).

Filter GNSS Fluctuations

• With Static Navigation on, the device discards small, spurious position changes from the GNSS.
• The internal angle and speed are treated as 0 until genuine movement is detected again.

GNSS Data vs. Device State

• When movement is detected, Static Navigation disables itself, allowing normal GNSS position updates.
• If the device becomes stationary once more, Static Navigation re-enables to filter out jitter.

Ignition ON counter

Ignition ON Counter feature continuously tracks how long a vehicle has spent with the active ignition.

It serves as an useful tool for maintenance schedules, driver oversight, and any application where total engine running time matters.

When Ignition ON counter feature is enabled, it starts to monitor the ignition source. The moment ignition value changes to ON, it starts to count the actvie ingnition time (in seconds). SMS nofications about the event status will be sent to predefined number, if it was configured in Input/output and SMS/call settings. Additionally, Ignition ON counter default value can be set to specific number, other than zero. In that way, when ignition value changes to ON, counting adds the active ignition time to the already predefiend value. Once Ignition source state changes to OFF, it saves the last value to Ignition on counter value field and will start counting from this exact saved value if Ignition source changes again.

Prerequisites and Important Settings

• For the functionality to work properly and to achieve the desired results, it's recommended to check the Ignition settings Source section in configurator.
• To ensure proper and desired notification of functionality status changes, check if it's enabled and configured in the configurator's SMS / call settings and Input / output (I/O) sections.
• To avoid incorrect value calculations, always check the set value in the configurator's Ignition on counter value (s).

Basic Operation

• Ignition ON counter scenario starts, when it is enabled in configurator’s Features section.
• It monitors the state of ignition source.

Suitable Ignition source can be set in System settings section, under Ignition settings.

• When ignition source state changes to ON, counting of active ignition time starts (in seconds). It increments counter every 500ms.

SMS notifications about scenario state changes are sent, according to configured settings. Notification settings can be set in SMS/call settings section under SMS events and in Input /output (I/O) settings under Permanent I/O.

• When ignition source state changes to OFF, counter value is saved to device’s memory.

Also, counter value is saved before device restarts and when counter value is changed in configurator.

• After the ignition is turned OFF and later turned ON again, "Ignition on counter" value will continue counting from the last saved value.

Parameters list

PARAMETER NAME	PARAMETER ID (RELATED AVL ID)	DESCRIPTION	VALUES
Ignition ON counter	1044900 (449)	The feature counts the time spent with the active ignition and the counter value can be set according to your needs. After the ignition is turned OFF and later turned ON again, "Ignition on counter" value will continue counting (from the last saved value).	0 = Disable Disable scenario. 1 = Low priority Device makes an additional record with indication of event cause. 2 = High priority Device makes an additional record with high priority flag and immediately sends an event packet to the server by GPRS.
Ignition on counter value (s)	13501	Ignition on counter value to be used initially.	Minimum value = 0 Maximum value = 4294967295 Default value = 0

Limitations, Edge Cases & Additional Notes

• When manually setting a new counter value via the TCT configurator, the counter increment parameter may override the new value. This can cause the update to be ignored. This issue only occurs when the value is set manually.
• On rare occasions the counter value may not be saved to the device's flash memory due to a sudden software crash or a power cut.

Custom scenarios

Introduction

The Custom Scenarios feature empowers you to define custom rules (conditions) using existing IO parameters. When those rules are met, the device can generate an event record and/or toggle a digital output (DOUT). Think of it as a flexible, user-configurable “if-this-then-that” system on your tracking device.

Use Cases

• Immobilizer-Style Control – Turn on a vehicle’s starter if certain conditions are met.
• Immobilizer-Style Control – Turn off a vehicle’s starter if certain conditions are met.
• iButton Authorization – Generate a record when an authorized driver inserts an iButton, or beep a buzzer if unauthorized.

Key Features

Record Generation

• Generate records when a scenario activates (goes from inactive to active) and deactivates (goes from active to inactive).
• You can set the priority of these records so they either send immediately (high priority) or follow normal data acquisition intervals (low priority).

Flexible IO Conditions

• Each custom scenario can use up to three IO elements (“sources”) to build an activation condition.
• You define thresholds and how the data is evaluated: “OnEnter,” “OnExit,” “Is,” etc.
• Activation Delay can replace older “averaging” logic—this ensures the condition remains valid for a set time before it triggers.

DOUT Control

• A scenario can switch a device’s DOUT on and off in a timed pattern.
• Infinite Mode: Repeat ON/OFF until the scenario becomes inactive.
• Finite Mode: Repeat ON/OFF for a configured number of cycles, then stop.

DOUT Deactivation

• You can specify an extra IO element to forcibly turn off the active DOUT.
• Useful when you want a driver or operator to silence a buzzer (via, for example, pressing a button linked to a digital input).

Logic Operands & Activation

• When using multiple sources, you can combine them with AND/OR logic.
• For example, “Source 2 AND Source 3” must both be active, or “Source 2 OR Source 3” can trigger a condition.

How It Works: Flow Overview

Enable the Scenario

• Set the Scenario Priority to a value greater than 0 (1 = low priority, 2 = high priority). Zero disables the scenario.
  

Define Up to Three Sources

• Source 1 is always evaluated.
• Source 2 and Source 3 can be turned on/off and combined via AND/OR logic with the previous source.
• Each source has:
  • IO Element (AVL ID)
  • Operand (OnEnter, OnExit, Is, etc.)
  • Low/High Threshold
  • Activation Delay (seconds)

Scenario Activation

• The scenario becomes active if all selected sources meet their conditions simultaneously (based on the chosen logic AND/OR).
• A record is generated if the scenario transitions from inactive → active, unless the operand is “Is” (which remains constantly active while the condition is true).

DOUT Behavior

• If configured, the device toggles DOUT ON/OFF according to:
  • DOUT ON Duration (ms)
  • DOUT OFF Duration (ms)
  • DOUT Repeat CountBold text (0 for infinite).

DOUT Deactivation

• If a deactivation source is set, that IO can forcibly turn off the DOUT even if the scenario is still active.
• The DOUT will remain off until the scenario becomes inactive (or conditions change).

Scenario Deactivation

• If any source condition fails (e.g., threshold not met), the scenario goes back to inactive and a record is generated indicating this change (unless using “Is,” which ends immediately when condition fails).

Configuration Parameters

Scenario & Priority

• Scenario AVL IDs:
  • Scenario 1 → AVL ID 358 (Priority config: 1035800)
  • Scenario 2 → AVL ID 359 (Priority config: 1035900)
  • Scenario 3 → AVL ID 360 (Priority config: 1036000)

• Priority Values & Meaning

Value	AVL Priority	Scenario Enabled?
0	None	No
1	Low	Yes
2	High	Yes

Source Configuration

• Source (AVL ID) – Which IO to monitor (e.g., digital input, sensor reading).
• Operand – “OnEnter,” “OnExit,” “Is,” etc.
• Low/High Level – Numeric threshold range for the IO value.
• Delay – Time in seconds the condition must stay valid (for “Is,” “OnEnter,” “OnExit”).
• Active – For Source 2 and 3, whether to include them in the logic.
• Logic – How Source 2 or 3 combines with the previous source: AND (0) or OR (1).

DOUT Configuration

• DOUT Control – Which DOUT to activate (0 = none).
• DOUT ON Duration (ms) – How long DOUT stays ON each cycle (0 or 100–5000 ms).
• DOUT OFF Duration (ms) – How long DOUT stays OFF each cycle (0 or 100–5000 ms).
• DOUT Repeat – Number of ON/OFF cycles (0 = infinite).

DOUT Deactivation

• Source (AVL ID) – Which IO can force DOUT off.
• Operand – Condition on that IO (similar to source operand).
• Low/High Level – Thresholds for that IO.
• Set the source to 0 to disable DOUT deactivation.

Expected Behavior: Simple Example

Scenario Setup

• Priority: 2 (High, scenario enabled)
• Source 1 (AVL ID = 21, e.g., Speed):
  • Operand: OnEnter
  • Low: 0, High: 5 (speed range)
  • Delay: 3 s
• DOUT Control:
  • DOUT = 1
  • ON Duration = 500 ms, OFF Duration = 500 ms, Repeat = 0 (infinite)

Activation

• If the vehicle’s speed stays between 0 and 5 km/h for at least 3 seconds, the scenario becomes active.
• The device generates an “active” event record.
• DOUT 1 starts toggling: ON for 500 ms, OFF for 500 ms.

Deactivation

• If speed goes above 5 km/h or drops below 0 for even a moment, the scenario becomes inactive.
• A “deactivated” event record is generated, and DOUT stops toggling.

Optional DOUT Deactivation

• If configured, an extra input (e.g., driver-pressed button) could turn DOUT off instantly, even while the scenario remains active.

Conclusion

The Custom Scenarios feature offers unparalleled flexibility for creating user-defined logic based on any available IO parameters. By mixing thresholds, delays, operands (“OnEnter,” “OnExit,” “Is”), and logic (AND/OR), you can tailor the device’s behavior to your exact operational needs—all without extra firmware modules.

Whether you need a simple record when a door opens or a complex multi-condition alert that flashes lights and logs data, Custom Scenarios gives you the tools to build it.

[[Category:{{{model}}} Configuration]]