Template:FTX Features

Eye-Sensor custom monitoring scenario

Overview

The Custom Monitoring scenario utilizes the Teltonika Telematics EYE Sensor to track device appearance/disappearance events and update selected IO elements. This scenario is based on Bluetooth Low Energy (BLE) advertisement data provided by the EYE Sensor.

Purpose:

• Detect when a device appears or disappears from the monitored area.
• Fill chosen IO elements with relevant data.
• Ensure periodic updates based on user-defined preferences.

Default Behavior:

• The Custom Monitoring scenario is enabled by default but can be manually enabled/disabled by the user.

Functionality

Device Appearance & Disappearance Tracking:

• The scenario continuously monitors BLE advertisement data.
• When a device enters or leaves the monitored area, it logs an event and updates the IO elements.

User-Defined IO Elements:

• The user can select specific IO elements to store data.
• These IO elements are updated when the device is detected or lost.

Periodic Data Updates:

• The scenario ensures regular updates of the chosen IO elements.
• Helps in continuous monitoring and historical analysis of device activity.

Global vs. User Configuration:

• By default, the scenario operates under a global configuration.
• Users have the option to customize the settings or disable the feature if needed.

Prerequisites

To use the Custom Monitoring scenario effectively, the following requirements must be met: Compatible Device:

• The monitoring device must support BLE-based communication with Teltonika EYE Sensors.

Firmware & Configuration:

• The tracking device must be running compatible firmware that supports Custom Monitoring.
• The scenario must be enabled in the device settings (default setting: ON).

IO Element Selection: a. The user must specify which IO elements should be updated when the device appears or disappears. Power & Connectivity:

• The EYE Sensor must be powered and within BLE range of the monitoring device.
• The monitoring device must have Bluetooth enabled to receive BLE advertisements.

Private/Business Scenario

Overview

The Private/Business Mode feature allows users to hide personal information when a business vehicle is used for private purposes. This ensures privacy protection by preventing location tracking and odometer updates when the vehicle is in Private Mode.

• Private Mode: The device will indicate that the vehicle is in private mode and will not send coordinates to the server. Additionally, the odometer can be stopped to prevent distance tracking.
• Business Mode: The device will function normally, with all data being sent and recorded without restrictions.

This feature is crucial for fleet management and business-owned vehicles where employees may use company vehicles for personal use.

Functionality

The Private/Business Mode works as follows: Mode Selection:

• When Private Mode is ON, the vehicle's location is not shared, and optionally, odometer tracking can be disabled.
• When Private Mode is OFF (Business Mode ON), the device works as usual, sending all data to the server.

Triggering Mechanisms:

• Digital Inputs (DINs): A set of configurable digital inputs can trigger Private Mode when activated.
• Weekly Schedule: The system can automatically switch modes based on a configured weekly schedule.
• Special Conditions: Private Mode can also be activated/deactivated by events like towing, unplug detection, crash detection, or auto-geofencing.

GNSS Data Masking:

• The system can mask GPS data in different ways when Private Mode is active:
  • Option 1: No masking (data is still visible).
  • Option 2: GNSS data is replaced with zeros.
  • Option 3: GNSS data remains at the last known good position before Private Mode was enabled.

Odometer Control:

• When Private Mode is ON, odometer tracking can be disabled to prevent distance accumulation during personal use.

DOUT Control:

• The device can trigger an external output (DOUT) when switching modes (e.g., to activate an indicator light showing the current mode).

Daylight Saving Adjustments:

• The system supports automatic daylight saving time adjustments, ensuring that the schedule remains accurate throughout the year.

Prerequisites

To ensure proper operation of the Private/Business Mode, the following conditions must be met: Device Compatibility:

• The tracking device must support Private/Business Mode functionality.
• The device should have digital inputs (DINs) or schedule configuration options enabled.

Firmware & Configuration:

• The device must run a firmware version that supports Private/Business Mode.
• The mode-switching triggers (DINs, schedule, or special conditions) must be properly configured in the device settings.

GNSS & IO Elements Setup:

• If using GPS masking, ensure the appropriate masking option is selected.
• If using odometer stop, confirm that it is enabled in the configuration.

Power & Connectivity:

• The device should be powered on and connected to receive trigger signals.
• If using a weekly schedule, ensure the system's time zone and daylight saving settings are correctly configured.

Trigger Setup:

• If using digital inputs (DINs) to switch modes, ensure the correct DINs are assigned in the configuration.
• If using a weekly schedule, configure the start and end times for business mode on each required day.

False Mounting Scenario

Introduction

The False Mounting Scenario is designed to detect incorrect device mounting using GNSS and IMU data. Improper mounting can cause false acceleration readings, leading to incorrect scenario triggers and inaccurate data. This feature ensures the device operates correctly by detecting mounting issues and notifying users when adjustments are needed.

Prerequisites

Before enabling the False Mounting Scenario, ensure the following: Device Compatibility:

• The device must support IMU (Inertial Measurement Unit) and GNSS data.
• The scenario should be enabled in the device configuration settings.

Firmware & Configuration:

• Ensure the device firmware supports the False Mounting Scenario.
• The scenario must be properly configured in the device settings.

GNSS & IMU Requirements:

• A valid GNSS fix is required.
• The GNSS speed must be above 10 km/h for accurate detection.
• Accelerometer calibration status must be Full.

Power & Ignition Conditions:

• The ignition must be ON for the scenario to activate.
• If ignition is OFF, the scenario will not run or will reset.

Environmental Factors:

• The device should not be exposed to extreme vibrations outside of normal usage conditions.
• Proper device mounting is required before scenario activation to establish a baseline.

Why It Is Needed

Incorrect mounting can result in:

• Inaccurate IMU data readings
• False acceleration detections
• Incorrect scenario activation
• Unreliable device behavior

By detecting false mounting conditions, the system helps users correct device placement for optimal performance.

How It Works

The scenario follows these steps:

Checks if the scenario is enabled in the configuration.
Verifies all conditions required to run the scenario:

• Ignition is ON
• Accelerometer calibration status is Full
• PVT (Position, Velocity, Time) is valid (GNSS fix and speed above 10 km/h)
• Device is not already flagged for false mounting

Runs the scenario to evaluate mounting conditions.

Uses condition checkers (e.g., High Vibrations Checker) to detect false mounting.

Clears scenario data when the ignition is turned off.

Condition Checkers

The Faulty Device Mounting I/O Element (IOAVL 1452) determines the mounting status:

• 0 → Correctly mounted (No issue detected).
• 1 → High vibrations detected (Possible incorrect mounting).

Currently, the scenario includes the High Vibrations Checker, with more condition checkers planned for future updates.

High Vibrations Checker

This checker detects false mounting by comparing GNSS and IMU acceleration differences over a specific time period. The evaluation period depends on the GNSS fix rate:

GNSS Fix Rate	Evaluation Period (x ms)
1 Hz	1000 ms
2 Hz	500 ms
5 Hz	200 ms
10 Hz	100 ms

False Mounting Triggers When:

• Max difference between GNSS and IMU acceleration on X or Y axis exceeds 400 mg.
• IMU acceleration change on X or Y axis exceeds 500 mg within the evaluation period.

(Thresholds are based on testing and may change over time.)

Expected Behavior

Correct Mounting:

• IOAVL 1452 = 0 → Device is correctly mounted.
  

Incorrect Mounting:

• IOAVL 1452 > 0 → False mounting detected.

Eye-Sensor magnet detection scenario

Introduction

This scenario enables magnet detection using the Teltonika Telematics EYE Sensor, allowing users to track door, gate, or valve openings and closings based on magnet presence. When a magnet is detected or removed, the device generates an I/O event, notifying the user of the state change.

Prerequisites

To use this scenario, the following conditions must be met:

Compatible Hardware – Requires a Teltonika EYE Sensor capable of magnet detection.

BLE Support – The tracking device must support Bluetooth Low Energy (BLE) scanning.

Scenario Activation – The scenario is enabled by default but can be manually enabled/disabled by the user.

How It Works

• The EYE Sensor monitors for the presence or absence of a magnet.
• When the magnet is detected, the scenario registers a closed state (e.g., door closed).
• When the magnet is removed, the scenario registers an open state (e.g., door opened).
• The device generates an I/O event upon any state change.

Scenario States

Magnet Present (Closed State):

• The sensor detects the magnet, indicating that the door, gate, or valve is closed.
• An I/O event is recorded to log the closed state.

Magnet Removed (Open State):

• The sensor no longer detects the magnet, indicating that the door, gate, or valve is open.
• An I/O event is recorded to log the open state.

User-Controlled Activation:

• The scenario is enabled by default, but users can manually enable or disable it as needed.

Eye-Sensor Temperature/Humidity monitoring scenario

Introduction

This scenario monitors Bluetooth Low Energy (BLE) temperature and humidity sensors, dynamically tracking detected devices and logging environmental changes.

Prerequisites

To ensure the scenario functions correctly, the following conditions must be met:

BLE Support – The device must support BLE scanning to detect temperature and humidity sensors.

Compatible BLE Sensors – The scenario works with BLE temperature and humidity sensors that broadcast their data.

BLE Event Handling – The device must process the following BLE events:

• ble.device_detected – Triggered when a new BLE sensor is detected.
• ble.device_expired – Triggered when a BLE sensor is no longer detected.

How It Works

• The scenario automatically tracks BLE sensors in real time.
• When a new sensor is detected, the scenario adds it to the monitored list and logs its data.
• If a previously monitored sensor disappears, it is marked as expired, and the scenario updates its status.
• The device updates IO elements to reflect temperature and humidity changes.

Scenario States

Device Detection:

• When a BLE sensor is detected (ble.device_detected), the scenario adds it to the active monitoring list.
• It differentiates between newly detected sensors and those that are already being tracked.

Data Monitoring & Logging:

• The scenario continuously monitors temperature and humidity values.
• If significant changes occur, an event is recorded to log the updated readings.
• The scenario updates IO elements to reflect the latest environmental data.

Device Expiration:

• If a BLE sensor is no longer detected for a configured time (ble.device_expired), the scenario marks it as expired.
• The scenario removes it from the active monitoring list and updates IO elements accordingly.

Continuous Tracking:

• As new BLE sensors appear and old ones expire, the scenario dynamically manages the list of monitored devices.
• This ensures that only currently active sensors are logged and processed.

Expected Behavior

• Real-time monitoring of BLE temperature and humidity sensors.
• Automatic tracking of newly detected and expired sensors.
• Logging of temperature and humidity changes for records and reports.
• IO element updates to reflect the latest sensor readings.

Manual Geofence scenario

Prerequisites

Users can configure up to 50 Manual Geofence scenarios at the same time. Each geozone can be one of two shapes:

• Circle: Defined by center coordinates (Latitude, Longitude) and a radius.
• Rectangle: Defined by two corner coordinates (northwest and southeast).

Configurable Parameters

Each Manual Geofence scenario includes the following settings:
Priority: Enables or disables the scenario.
Shape Type:

• Circle – Requires center coordinates and radius.
• Rectangle – Requires two sets of corner coordinates.

Event Type: Defines when an event is generated:

• On Enter: Event is triggered when the device enters the geozone.
• On Exit: Event is triggered when the device exits the geozone.
• On Both: Events are triggered for both entering and exiting.

Speed Limit Threshold:

• Toggle: Enable or disable speed monitoring.
• Max Speed (km/h): Speed limit for triggering speeding events.

Geozone Parameters:

• Circle Radius (m): Defines the size of a circular geozone.
• Frame Border (m): Expands the geozone slightly when entering to prevent false exit events.

Coordinate Parameters:

• Circle: Requires one set of coordinates (Latitude, Longitude).
• Rectangle: Requires two sets of coordinates (northwest and southeast).

How It Works

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.

Speeding: Indicates whether the device is exceeding the speed limit while inside the geozone.

When a state change occurs (entering/exiting the geozone or starting/stopping speeding), an event is recorded.

Expected Behavior

With these settings, the device will:

Detect and record entry and exit events when a vehicle crosses geozone boundaries. Monitor speed violations inside geozones and generate start/stop speeding events if enabled.

Prevent false exit detections using the frame border setting. This scenario helps track vehicle movements within custom-defined geozones, ensuring compliance with predefined routes and speed limits.

Time synchronization scenarios

Introduction

Accurate system time is essential for proper event logging, record timestamping, and scheduling. The device supports two primary time synchronization sources: GNSS and SNTP. When one source becomes unavailable, the device can fall back to the other to maintain accurate time.

Prerequisites

Network Connectivity

• To use SNTP, the device must be able to connect to the internet

Configuration Access

• TCT NTP settings (e.g., synchronization interval, NTP server domains) must be accessible for setup or modification.

Parameter Description

GNSS Time Synchronization

• Trigger Condition: If a valid GNSS fix is available and the difference between the GNSS-provided time and the internal RTC is ≥ 3 seconds for a continuous period of 5 seconds, a time correction occurs.
• Subsequent Synchronizations: After the first successful sync, the wait time before the device checks for another 3-second difference increases to 5 minutes to prevent excessive corrections.

SNTP Time Synchronization

• Trigger Condition: If the device lacks a GNSS fix for 60 seconds, it attempts to synchronize time via SNTP.
• Resynchronization Interval: Defined by TCT NTP settings (default is 3 hours).
• NTP Servers: Two servers can be configured; by default, pool.ntp.org is the primary server and time.google.com is the fallback. If the first server is unreachable, the device automatically attempts the second.

Expected Behavior

GNSS Time Sync Process

• When GNSS is active, the device continuously compares GNSS time to the internal clock.
• If the 3-second offset persists for 5 seconds, the clock is updated immediately.
• After the first correction, the device waits 5 minutes before checking for another large time discrepancy.

SNTP Time Sync Process

• If no GNSS fix is available for 60 seconds (e.g., poor satellite signal, modem off, etc.), the device initiates an SNTP request.
• If the primary NTP server is unreachable, it tries the secondary server.
• The device repeats this SNTP synchronization after the configured interval (default 3 hours).

Fallback Mechanism

• GNSS is the first choice for time synchronization.
• When GNSS is not available, SNTP ensures the device clock remains accurate until a valid GNSS fix is restored.

Movement scenarios

Prerequisites

A functional IMU (inertial measurement unit) within the device is required to track and report movement data.

Configuration Tool Access

• You need the ability to enable or configure Instant/Delayed Movement scenarios and link them to Ignition or Movement.

Parameter Description

Instant Movement Scenario

• Processes each sample from the IMU sensor.
• Generates an IO (ID = 303) whenever the movement state changes (from idle to moving or moving to idle).
• Uses internal noise-level estimation; when the vehicle is not moving, the noise level should be minimal.

Delayed Movement Scenario

• Relies on the Instant Movement IO in combination with two delays:
  • Start Movement Delay – Time the IMU signal must show continuous movement before confirming the vehicle is “moving.”
  • Stop Movement Delay – Time the IMU signal must show no movement before confirming the vehicle is “idle.”
• Events generated through the accelerometer can serve as a source for Ignition or Movement, allowing further device logic to depend on the detected state.

Expected Behavior

Instant Movement Detection

• The device continuously monitors each IMU reading.
• Once the noise threshold is exceeded (indicating motion), IO 303 changes from “idle” to “moving.”
• If the motion subsides, IO 303 reverts to “idle.”

Delayed Movement Confirmation

• When Instant Movement reports a change to “moving,” the Start Movement Delay timer begins. If the motion persists for the entire duration, the device confirms it as “moving.”
• Conversely, once motion ceases and the device reports “idle,” the Stop Movement Delay timer begins. After this timer elapses without any further movement, the device confirms it as “idle.”

Integration with Ignition or Movement

• These Instant or Delayed Movement scenarios can be mapped to the device’s Ignition or Movement settings, providing an alternative to traditional ignition detection or GNSS-based movement detection.

Event Generation

• When configured, changes in the movement state (detected by IMU) can trigger records or alerts.
• This data can also be used by the device for status reporting, logging, and various user-defined scenarios.

LED scenarios

Introduction

The device includes Navigation and Status LEDs to provide immediate visual feedback about its operational state. These LEDs inform whether the GNSS is active and acquiring a fix, and whether the device’s GPRS session is established. The feature can be disabled through configuration if a “stealth” mode is required.

Prerequisites

Hardware Support

• The device must have functional Navigation and Status LED indicators.

Configuration Access

• You must be able to enable or disable LED indications through the device’s configuration tool.

Parameter Description

Navigation LED Indications

Behavior	Meaning
Permanently Switched On	GNSS is running, but a fix has not been acquired.
Short Blink Every Second	GNSS is running, and a fix has been acquired.
Off	GNSS is powered off (e.g., device not active or in sleep).

Status LED Indications

Behavior	Meaning
Blinking Every Second	Device is active; GPRS session is established.
On (Solid Light)	Device is active; no GPRS session.
Off	Device is powered off or not operating.

Expected Behavior

Navigation LED Sequence

• When powered and searching for a GNSS fix, the Navigation LED will remain On until a fix is acquired.
• Once a valid fix is found, the LED will blink once every second to indicate successful GNSS positioning.
• If the GNSS module is turned off (due to configuration or sleep mode), the Navigation LED will be Off.

Status LED Sequence

• If the device has an active GPRS connection, the Status LED will blink every second.
• If the device is active but no GPRS session is established, the Status LED will remain On (solid).
• If the device is not powered or is in deep sleep, the Status LED will be Off.

Disabling LED Indications

• If stealth or power savings are desired, the LEDs can be disabled via the configuration tool. This setting will turn both LEDs off, regardless of GNSS or GPRS status.

IMU (Accelerometer) scenarios

Introduction

Two primary scenarios manage IMU-based movement:

Instant Movement:

• Processes every IMU reading and updates an IO (ID = 303) whenever the movement state changes.
• Relies on internal noise-level estimation to decide if the vehicle is truly moving or idle.

Delayed Movement:

• Uses the Instant Movement IO in conjunction with two adjustable delays—Start Movement Delay and Stop Movement Delay—to confirm and stabilize movement or idle states.
• Generates movement or idle events that can be used as ignition or movement sources.

Prerequisites

IMU Hardware Support

• The device must be equipped with an IMU module that is fully functional.

Firmware / Configuration Access

• You need access to the device’s configuration tool to enable and set parameters for both Instant and Delayed Movement scenarios (e.g., Config IDs 19001 and 19002).

Device Firmware Compatibility

• Ensure the firmware supports IMU-based movement detection. Always refer to release notes for any hardware or firmware requirements.

Parameter Description

Parameter	Config ID	Units	Min	Max	Default	Description
Motion start detection delay	19001	Seconds	1	60	2	The algorithm reports motion start only if the IMU detects movement continuously for the entire duration of this delay. If the threshold is exceeded at any point during this time, the vehicle is considered moving.
Motion stop detection delay	19002	Seconds	5	65535	60	The algorithm reports motion stop only if the IMU detects no movement (below threshold) continuously for the entire duration of this delay. If the threshold is not exceeded for this time, the vehicle is considered idle.

Example Configuration Screenshots

• Movement Source Selection: accel-as-movement-source.png
• Delays Configuration: accel-as-movement-params.png

Expected Behavior

Instant Movement Scenario

• The IMU sensor is sampled continuously, and an IO event (ID = 303) is triggered whenever the device transitions from “idle” to “moving” or vice versa.
• A noise threshold helps filter out minor vibrations, ensuring only genuine movement causes a state change.

Delayed Movement Scenario

• Relies on the IO (ID = 303) from the Instant Movement scenario.
• Once Instant Movement indicates activity, the Start Movement Delay (ID 19001) timer begins. Only if movement persists for the entire duration is the vehicle confirmed to be in a “moving” state.
• Likewise, if Instant Movement indicates no activity (idle), the Stop Movement Delay (ID 19002) timer starts. If no motion is detected throughout that delay, the vehicle is confirmed to be idle.

Integration with Ignition/Movement

• When either scenario confirms a state change (e.g., from idle to moving), that event can serve as the Ignition or Movement source in the device’s configuration.
• This enables advanced logic—such as controlling data logging intervals, sending notifications, or updating trip reports—based on accelerometer-driven movement states rather than engine-based signals or GNSS data alone.

Record Generation & Logging

• If configured, the device can generate periodic or event-based records whenever movement states change.
• These records can be transmitted in real time (if high-priority) or included in periodic data (if low-priority), depending on your device settings.

Immobilizer scenario

Introduction

This feature provides an additional layer of vehicle protection by requiring driver authorization after ignition is turned on. The immobilizer ensures that the vehicle starter remains blocked until an approved authorization method—such as an iButton or iBeacon—is detected.

Key Features of the Immobilizer

• Configurable ignition timeout: Determines the time after ignition deactivation when the driver is deauthorized.
• Output control: Selects a dedicated relay pin to block or unblock the vehicle starter circuit.
• Record generation: Creates periodic and eventual records with configurable priority.

Immobilizer States

Not Authorized / Waiting for Authorization

• Triggered when the ignition is turned ON.
• If output control is enabled, the device sets the output pin to high, blocking the starter.
• The device waits for an authorization signal (e.g., iButton or iBeacon detection).
• If authorization is confirmed (timestamp of presence check is later than ignition ON timestamp), the output pin is set to low, and the state changes to Authorized.

Authorized

• The vehicle starter is unblocked, allowing the driver to start the vehicle.
• Authorization remains valid as long as the ignition signal stays ON.

Scheduled wakeup scenario

Introduction

The Scheduled Wakeup scenario enables users to configure a device wakeup at specific times to generate and send a record. This feature operates in any power mode, ensuring that the device can wake up and transmit data even when not in sleep mode.

Purpose:

• Schedule periodic wakeups for record transmission.
• Ensure data updates even when the device is in deep sleep.
• Adjust wakeup times based on transmission delays.

Default Configuration:

• o Wakeup times are set using a list of uint16 variables in HHmm format (range: 0000 – 2359).
  • Example:
    • 12:00 → 1200
    • 01:45 → 145
    • 01:45 → 145
• Unconfigured timestamps default to 2500.

Key Features

Wakeup Time Compensation

• Accounts for the time required to wake up, sync time, get GNSS fix, and send data.
• After each record transmission, the device adjusts the next wakeup time based on the time taken.
• If the wakeup process exceeds 10 minutes, the adjustment is ignored, and the next wakeup follows the original schedule.

Finding the Closest Wakeup Time

• The system evaluates all configured wakeup times for the current day.
• If no valid wakeup times remain, it checks the next day's schedule.
• The closest wakeup time is determined by:
  • Calculating the time difference between the current time and the next scheduled wakeup.
  • Adjusting for how many days away the next wakeup occurs.
• If no wakeup times are found for an entire week, the scenario will not set a timer.

Time Synchronization Repeat

• Ensures that the device knows the correct time and day for scheduled wakeups.
• If the device fails to sync time, it will:
  • Attempt to sync time every 15 minutes while in sleep mode.
  • If unsuccessful, it will double the sleep time (e.g., 30 min → 1 hr → 2 hrs, etc.).
  • The sleep duration increases until it reaches a maximum of 24 hours.
  • The process repeats until successful time synchronization, the device is turned off, or the battery dies.

Prerequisites

To use the Scheduled Wakeup Scenario, the following must be met:

Device Compatibility:

• The tracking device must support scheduled wakeups and record transmission.

Time Configuration:

• Wakeup times must be set in the configurator with the correct timezone.

Power & Connectivity:

• If the device is in deep sleep, it must have enough battery to wake up and send records.

GNSS & Modem Activation:

• The device must be able to synchronize time and establish a network connection.

Ignition ON counter

Introduction

The Ignition ON Counter Monitoring feature continuously tracks how long a vehicle’s ignition remains in the ON state. It serves as an invaluable tool for maintenance schedules, driver oversight, and any application where total engine running time matters.

How It Works

Counter Increments

• Every 500 ms (half a second) that the ignition is ON, the counter increases by that same half-second.

Persistent Data

• The ignition-on counter is stored in non-volatile memory (NVM). This ensures the counter’s value remains intact across device restarts and power outages.

Saving Conditions

• The device automatically saves the counter value to NVM whenever:
  • Ignition transitions from ON to OFF.
  • A device restart is about to occur.
  • The counter value is changed via configuration (e.g., a manual reset or preset adjustment).

Manual CAN

When configuring CAN IO elements, each parameter (like priority, operand, CAN type, CAN ID, etc.) requires a unique configuration ID. These IDs follow specific formulas to ensure no overlap with other parameters in the system. This guide explains how to calculate them.

Formula:
Parameter_ID = 1,000,000 + (AVL_ID * 100) + OPTION Parameter_ID = 1,000,000 + (AVL_ID * 100) + OPTION

• 1,000,000: Base offset for CAN-related parameters.
• AVL_ID: The CAN AVL IO element identifier (within certain allowed ranges).
• OPTION: A small integer offset indicating which setting is being adjusted (e.g., priority or operand).

Valid AVL Ranges

• [10216:10235]
• [10298:10347]

Example: If AVL_ID is 10216 and the OPTION for “priority” is 1, then Parameter ID=1,000,000+(10216×100)+1=1,000,000+1,021,600+1=2,021,601

MCAN IO Parameter Calculation

For MCAN IO elements (e.g., MCAN0, MCAN1, MCAN2…), each has three specific parameters: CAN Type, CAN ID, and Data Mask. The MCAN IO number is the index of the MCAN entry (starting at 0, 1, 2, etc.).

Formulas:

CAN Type
Parameter ID=17,000+(10×MCAN IO number)
CAN ID
Parameter ID=17,001+(10×MCAN IO number)
Data Mask
Parameter ID=17,002+(10×MCAN IO number)

Examples:

• MCAN0 (IO number = 0):
  • CAN Type: 17000 + (10 × 0) = 17000
  • CAN ID: 17001 + (10 × 0) = 17001
  • Data Mask: 17002 + (10 × 0) = 17002
• MCAN1 (IO number = 1):
  • CAN Type: 17000 + (10 × 1) = 17010
  • CAN ID: 17001 + (10 × 1) = 17011
  • Data Mask: 17002 + (10 × 1) = 17012
• MCAN69 (IO number = 69):
  • CAN Type: 17000 + (10 × 69) = 17690
  • CAN ID: 17001 + (10 × 69) = 17691
  • Data Mask: 17002 + (10 × 69) = 17692

Putting It All Together

Check Your AVL ID Range

• If your CAN IO element has an AVL ID in [10216–10235] or [10298–10347], use the first formula for Parameter_ID = 1,000,000 + (AVL_ID * 100) + OPTION.

Identify Your MCAN IO Number

• If you have an MCAN entry (e.g., MCAN0, MCAN1), use the second set of formulas to find the corresponding CAN Type, CAN ID, and Data Mask parameter IDs.

Plug In the Numbers

• Calculate step by step, ensuring you add the correct base offsets and multipliers.

Configure Your Device

• Once you have the parameter IDs, set or modify them in your configuration tool to match the desired priority, operand, or other CAN-related settings.

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 off 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.

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.

Fall Down Detection

Introduction

The Fall-Down Detection scenario identifies when a vehicle or piece of equipment has fallen over or is tilted beyond a specified angle. It relies on built-in accelerometer data (IMU) along with information about movement, ground speed, and GPS availability. Once enabled, the scenario calculates a “base vector” to represent the normal upright orientation and raises an alert if the device tilts too far for a set amount of time.

Prerequisites

Scenario Priority

• Must be greater than 0 (i.e., not 0) for the scenario to be active.

Movement Source & Ground Speed

• The device monitors whether the vehicle is moving or stationary, including GNSS ground speed readings.

GNSS Fix

• A valid GNSS fix is required to establish the device’s orientation baseline (the base vector).

IMU (Accelerometer) Data

• The scenario uses linear vector data from the accelerometer to detect tilt.

How It Works

Waiting for a Baseline

• While the vehicle is not moving (movement is “inactive”), ground speed is 0 m/s, and there is a valid GNSS fix, the device calculates a base vector from the IMU. This vector represents the normal, upright orientation.

Monitoring for Tilt

• Once the base vector is set, the scenario continuously compares new IMU readings (the current vector) to the base vector.
• If the angle between these two vectors exceeds the configured Activation Angle for at least the Activation Timeout, a fall-down event is triggered.

Event Generation

• If configured to do so (see Generate event parameter), the device sends a record indicating that a fall-down has been detected. Depending on the Priority setting, this record may be sent immediately (high priority) or follow regular data acquisition intervals (low priority).

Expected Behavior

Base Vector Setup

• When the vehicle/equipment is stationary (movement “off,” speed = 0, GNSS fix valid), the device measures its upright orientation.

Tilt Monitoring

• As soon as the base vector is established, incoming IMU data is compared against that baseline.
• If the tilt exceeds the Activation Angle for the entire Activation Timeout window, the device flags a fall-down event.

Event Response

• Depending on Priority and Generate Event settings, the fall-down event is either sent right away (if high priority) or included with the next scheduled data record (if lower priority).
• If Eventual Records is enabled, a detailed record is saved for later review.

Example Configuration & Outcome

• Scenario Priority: 1 (scenario enabled)
• Activation Angle: 45°
• Activation Timeout: 5 seconds
• Generate Event: 1 (immediate)
• Eventual Records: 1 (yes)

What Happens?

• The device calculates a base vector when the vehicle is parked (no movement, 0 m/s, valid GNSS).
• If the vehicle tilts more than 45° for over 5 seconds, the device immediately generates a fall-down event record, indicating a possible tip-over.
• The fall-down condition remains active until either reset manually or until conditions change (e.g., the vehicle is returned upright, and the device recalibrates).

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.

Driving behaviour scenarios

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

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 detection

Introduction

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. This feature is enabled by default in modems that support it.

Prerequisites

Modem Compatibility

• The jamming detection feature operates only with certain modems and firmware versions. Known compatible models include:
  • EG915U-EU (from EG915UEUABR03A01M08_01.002.01.001)
  • EG915-LA (from EG915ULAABR03A01M08_01.001.01.001)

Scenario Enablement

• The modem has jamming detection enabled at all times.
• The device must be configured to create records upon detecting a jamming event.

How It Works

Initial Jamming Detection

• The modem continuously monitors the network. If jamming is detected, the timer for Jamming Detection Delay (e.g., 60 seconds) starts.

Jamming Started

• If the detected jamming lasts for the entire delay period (e.g., 60 seconds), the device creates a High or Low priority record (depending on 1024900 setting) labeled “Jamming started.”
• If configured for immediate reporting, the record is sent right away, bypassing periodic data acquisition intervals.

Jamming Ended

• As soon as jamming stops (after a “Jamming started” record was generated), the device creates a “Jamming ended” record.
• This record is typically sent immediately if the scenario’s priority level is set to High.

Monitoring Resumes

• The modem continues monitoring for further jamming events. If another jamming incident occurs, the same process repeats (steps 1–3).

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

Introduction

This scenario automatically creates a geozone around a vehicle’s last known location when certain conditions are met. It also detects when a vehicle is moving without a GNSS fix for a configured amount of time and records this as an event.

Prerequisites

This scenario relies on several key parameters to function properly:

1. Activation Timeout (s): Determines how long specific conditions must be met before creating a geozone. It depends on the current state:
2. Wait State: The duration required to capture the vehicle’s last known location.
3. Active State: The duration the vehicle must be moving without a GNSS fix before triggering an “On Exit” event.
4. Geozone Radius (m): Defines the size of the geozone created after the activation timeout. The center of the geozone is based on the vehicle’s last known location.
5. Deactivation Source: Specifies how the Auto Geofence scenario can be deactivated. Available options:
6. Power Voltage: If external voltage exceeds 5250 mV.
7. iButton: If an authorized iButton is attached.

How It Works

According to configuration settings device will:

1. Detect when a vehicle is stationary with a valid GNSS fix and create a geozone at the last known location.
2. Monitor movement without a GNSS fix and generate an exit event if the vehicle moves outside the geozone or moves for too long without GNSS.
3. Automatically reset when a configured deactivation source (e.g., power voltage, digital input, or iButton) is activated.

Scenario States

The Auto Geofence scenario operates in 2 states:

1. Wait State

In this state, the scenario waits for specific conditions to be met before creating a geozone and moving to the Active State.

Conditions for activation:

• GNSS fix is valid.
• Vehicle is not moving.

Once these conditions are met, the scenario starts the Activation Timeout countdown. If any condition is broken (e.g., movement is detected), the countdown resets.

After the timeout:

• A geozone is created at the vehicle’s last known location.
• If configured, an “On Enter” event is generated.
• The scenario transitions to Active State.

2. Active State

Once in Active State, the scenario monitors for movement without a GNSS fix or movement outside the geozone.

Exit conditions:

• The configured deactivation source is triggered.
• The vehicle moves without a GNSS fix for the Active State timeout.
• The vehicle moves outside the geozone with a valid GNSS fix.

When an exit event is triggered:

• If configured, an “On Exit” event is generated.
• The scenario returns to Wait State.

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.

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