Jump to content

Template:FTX Features: Difference between revisions

From Teltonika Telematics Wiki
No edit summary
No edit summary
Line 2: Line 2:
==Crash Detection==
==Crash Detection==
[[File:FTX crash detection.png|alt=|right|500px]]
[[File:FTX crash detection.png|alt=|right|500px]]
If ''Crash Detection'' is enabled, it monitors the acceleration on each axis (X,Y,Z) that assists in detecting an accident.


*'''Priority''' – defines the priority of crash detection scenario: 0 disabled, 1 – low, 2 – high.
=== Introduction ===
*'''Crash Duration (ms)''' - Time needed to exceed the accelerometer threshold to trigger the crash event.
 
*'''Crash Threshold (mG)''' - Acceleration threshold that needs to be exceeded for the length of the configured duration to generate a crash event.
The '''Crash Scenarios''' feature detects and logs vehicle crash events using accelerometer data. The device offers two primary crash detection methods:
''Threshold'' and ''Duration'' values are set depending on the impact magnitude that is required to be detected. {{{model}}} can detect events ranging between a slight tapping on the device and a severe accident.
* '''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.
 
=== Expected Behavior ===
 
'''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.


<br />
<br />
<br />
<br />
<br />
<br />
== Overspeeding ==
== Overspeeding ==
[[File:FTX overspeeding.png|alt=|right|500px]]
[[File:FTX overspeeding.png|alt=|right|500px]]
When the vehicle speed exceeds the configured maximum speed value, the scenario is activated, and an event record is generated and digital output status is changed to 1 when configured.<br />Detected speed has to be greater than configured max speed +3% of configured max speed for the overspeeding event to start. To stop the overspeeding event, the detected speed has to be lower than the configured max speed -3% of the configured max speed.
Configurable parameters:
<br />
<br />
<br />
*'''Priority''' – defines the priority of overspeeding scenario: 0 – disabled, 1 – low, 2 – high.
*'''Max speed (km/h)''' – the maximum allowed speed that can be reached. If the speed exceeds the configured value, then the event will be generated.


<!-- If model is without DOUT, don't show -->
=== Overview ===
{{#ifeq: {{{model}}} | FTC881 ||
 
*'''Output Control''' - Source of digital output (DOUT) for feature activation/deactivation.  
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'''.
''None'' - DOUT is not affected.  
*'''Purpose:'''
''DOUT 1'' - DOUT will activate when the event happens
** Promote '''safe and economic driving'''.
*'''DOUT ON duration (ms)''' - Value in milliseconds, duration for how long DOUT should be active.
** Provide '''real-time alerts''' on speed violations.
*'''DOUT OFF duration (ms)''' - Value in milliseconds, duration for how long DOUT should be inactive.
** 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:


<br />
'''Feature Activation'''
<br />
* Enable the feature in '''Telematics Configuration Tool (TCT)''' under '''Driving Behavior'''.
<br />
'''Speed Configuration'''
<br />
* Configure the '''max speed limit''' and '''record priority''' as per requirements.
<br />
'''GNSS & Data Connectivity'''
<br />
* The device must have '''active GNSS tracking''' to monitor speed accurately.
<br />
<br />


==Trip==
==Trip==
[[File:FTX trip.png|alt=|right|500px]]
[[File:FTX trip.png|alt=|right|500px]]
''Trip'' section offers user to configure the ''Trip'' feature. ''Trip'' starts when Ignition according ''Ignition source'' is ON and Movement according ''Movement source'' is ON and also 'Start Speed' is exceeded. ''Start Speed'' defines the minimum GPS speed in order to detect ''Trip'' start.<br />''Ignition OFF Timeout'' is the timeout value to detect ''Trip'' end once the Ignition (configured ignition source) is off.
 
<br />
=== Introduction ===
<br />
 
<br />
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.
<br />
 
<br />
=== Prerequisites ===
<br />
 
<br />
'''Ignition and Movement Sources'''
<br />
* 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.
<br />
'''Trip Odometer I/O'''
<br />
* The '''I/O Trip Odometer''' must be enabled for the device to log distance traveled during a trip.
<br />
'''GNSS Connectivity'''
<br />
* Since Start Speed is tied to '''GPS speed''', a functioning GNSS module is required for accurate speed measurements.
<br />
 
<br />
=== 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.
 
=== Expected Behavior ===
 
'''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==
== Odometer==
[[File:FTX odometer.png|alt=|right|500px]]
[[File:FTX odometer.png|alt=|right|500px]]
Set the odometer value from which the device will start counting.''Odometer Value'' sets the starting total odometer value. ''Priority'' allows to select how events are being sent to a server.


'''Priority'''
=== Introduction ===
*'''Disable''' - disable scenario.
 
*'''Low Priority''' - when low priority event is triggered, device '''makes additional record''' with indication of event cause.
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.
*'''High Priority''' - module makes additional record with High priority flag and '''sends event packet immediately''' to the server by '''GPRS'''.
 
=== 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
 
=== Expected Behavior ===
 
'''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.
 
 


'''Odometer Value (km)''' - The initial virtual odometer value in kilometers. It can be copied from the vehicle dashboard to synchronize odometer values.
<br>
<br>
==Eco Driving==
==Eco Driving==
[[File:FTX eco driving.png|alt=|right|500px]]
[[File:FTX eco driving.png|alt=|right|500px]]
The feature sends an event when a harsh acceleration, braking, or cornering incident happens. The device continuously monitors and processes accelerometer/GPS data to decide whether a harsh event has occurred. If either one of the three threshold values is exceeded, an event will be generated.
 
=== Overview ===
 
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.
 
=== Configuration Options ===


'''Priority'''
'''Priority'''
*'''Disable''' - disable scenario.
*Defines the '''importance level''' of generated Eco Driving events.
*'''Low Priority''' - when low priority event is triggered, device '''makes additional record''' with indication of event cause.
'''Acceleration Source'''
*'''High Priority''' - module makes additional record with High priority flag and '''sends event packet immediately''' to the server by '''GPRS'''.
*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.


'''Harsh Thresholds'''
=== How the Algorithm Works ===
*'''Acceleration threshold (m/s²)''' - the max allowed acceleration force that can be reached while accelerating without triggering a harsh acceleration event.
*'''Braking threshold (m/s²)''' - the max allowed braking force that can be reached while braking without triggering a harsh braking event.
*'''Cornering threshold (m/s²)''' - the max allowed cornering force which can be reached while cornering without triggering a harsh cornering event.


'''Source'''
An '''Eco Driving event''' is triggered when all of the following conditions are met:
# '''Scenario is enabled'''
# '''Ignition is ON'''
# '''GNSS fix is present'''
# '''Vehicle speed is above 10 km/h''' for the event’s duration
# '''Acceleration exceeds the configured threshold''' and stays above it for at least '''0.5 seconds'''
# Acceleration drops below the threshold and stays there for '''0.5 seconds'''


The data source for the eco-driving feature. The accelerometer source is more accurate compared to GPS but requires tight installation and accelerometer calibration.
Once an event is detected:
*'''GNSS''' - Acceleration data is calculated from GNSS speed and heading using a mathematical model of motion.
* A '''new record is generated''', identifying the type of Eco Driving event.
*'''Accelerometer'''- Acceleration data is taken from the built-in accelerometer sensor chip.
* The following '''IO parameters''' are updated:
NOTE:
**'''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).
 
=== '''Eco Driving State Machine''' ===
 
The system operates as a '''state machine''' with 4 states:
# '''Idle''' → No event detection (vehicle speed too low, no GNSS fix, ignition off, etc.).
# '''Eco''' → Normal driving, acceleration remains within safe thresholds.
# '''Harsh''' → Acceleration exceeds the limit, but event isn't registered yet (prevents false positives).
# '''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.
 
=== Prerequisites for Eco Driving Functionality ===
 
'''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.
 
=== Conclusion ===
 
The '''Eco Driving scenario''' helps businesses '''monitor and reduce aggressive driving behaviors'''<br>
 
By logging '''harsh acceleration, braking, and cornering''', fleet managers can:
* '''Improve driver safety'''
* '''Reduce vehicle wear & tear'''
* '''Lower fuel consumption'''
* ️'''Encourage responsible driving habits'''


When using Accelerometer as the source of eco green driving data, the device should be mounted as per these [[mounting|instructions]]


==Excessive Idling==
==Excessive Idling==
[[File:FTX excessive idling.png|alt=|right|500px]]
[[File:FTX excessive idling.png|alt=|right|500px]]
When the vehicle stops for a specific amount of time, this scenario is activated and a record will be generated.


=== 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.
<!-- If model is without DOUT, don't show -->
<!-- If model is without DOUT, don't show -->
{{#ifeq: {{{model}}} | FTC881 ||
{{#ifeq: {{{model}}} | FTC881 ||  
If the DOUT is configured, it will activate when the event takes place. The scenario remains activated until the vehicle starts moving.
Additionally, this scenario can notify the driver by activating DOUT that this event was activated.  
}}
}}


'''Priority'''
=== Prerequisites ===
*'''Disable''' - disable scenario.
 
*'''Low Priority''' - when low priority event is triggered, device '''makes additional record''' with indication of event cause.
This scenario uses two global configuration parameters to work:
*'''High Priority''' - module makes additional record with High priority flag and '''sends event packet immediately''' to the server by '''GPRS'''.
# '''Ignition source''' – That is used to detect if a vehicle is on or on.
# '''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 Stopped (s)''' - The period for how long the 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.


'''Time to Moving (s)''' - The period for how long the vehicle '''should move''' with the ignition ON (by "Ignition source") to exit the excessive idling state.
'''Output control''' – Digital output selection that will determine which digital output will be enabled.


<!-- If model is without DOUT, don't show -->
'''DOUT ON duration (ms)''' - Time in milliseconds that determines how long DOUT will be in ON state.
{{#ifeq: {{{model}}} | FTC881 ||
'''Output Control''' - Source of digital output (DOUT) for feature activation/deactivation.  


''None'' - DOUT is not affected.
'''DOUT OFF duration (ms) - '''Time in milliseconds that determines how long DOUT will be in OFF state.
''DOUT 1'' - DOUT will activate when the event happens
*'''DOUT ON duration (ms)''' - Value in milliseconds, duration for how long DOUT should be active.
*'''DOUT OFF duration (ms)''' - Value in milliseconds, duration for how long DOUT should be inactive.
}}


=Vehicle protection=
=Vehicle protection=
==Network Jamming Detection==
==Network Jamming Detection==
[[File:FTX network jamming detection.png|alt=|right|500px]]
[[File:FTX network jamming detection.png|alt=|right|500px]]
Detects the GSM jamming and helps to prevent vehicle theft when a jamming tool is used. A low signal level is not equal to GSM jamming, and the device recognizes these events.


'''Priority'''
=== Introduction ===
*'''Disable''' - disable scenario.
 
*'''Low Priority''' - when low priority event is triggered, device '''makes additional record''' with indication of event cause.
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.
*'''High Priority''' - module makes additional record with High priority flag and '''sends event packet immediately''' to the server by '''GPRS'''.
 
=== 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 ===
 
* When the modem senses potential signal jamming, it waits for the specified '''Jamming Detection Delay''' to confirm it.
* If the signal jamming persists for the entire delay period, a '''“Jamming started”''' event record is generated.
* If the jamming ceases after it has started, a '''“Jamming ended”''' event is generated immediately.
 
=== Expected Behavior ===


'''Time until Jamming reporting (s)''' - The period given before a jamming event is generated upon detection of the GSM signal disruption.
'''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).


'''Eventual records''' - Enables feature status sending only when the event happens (an eventual record). When disabled, feature status will be sent along with both the eventual and periodical records.


==Unplug detection==
==Unplug detection==
Line 143: Line 365:
[[File:FTX unplug detection.png|right|500 px]]
[[File:FTX unplug detection.png|right|500 px]]


An event will be generated when is unplugged from external power or plugged back in again.  
=== 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.
 
=== Expected Behavior ===
 
'''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).


'''Priority'''
*'''Disable''' - disable scenario.
*'''Low Priority''' - when low priority event is triggered, device '''makes additional record''' with indication of event cause.
*'''High Priority''' - module makes additional record with High priority flag and '''sends event packet immediately''' to the server by '''GPRS'''.
<br>
<br>


==Auto Geofence==
==Auto Geofence==
Line 156: Line 410:
[[File:FTX auto geofence.png|right|500 px]]
[[File:FTX auto geofence.png|right|500 px]]


The Auto Geofence scenario operates in two states:  
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:
# '''Activation Timeout (s):''' Determines how long specific conditions must be met before creating a geozone. It depends on the current state:
# '''Wait State:''' The duration required to capture the vehicle’s last known location.
# '''Active State:''' The duration the vehicle must be moving without a GNSS fix before triggering an “On Exit” event.
# '''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.
# '''Deactivation Source:''' Specifies how the Auto Geofence scenario can be deactivated. Available options:
# '''Power Voltage:''' If external voltage exceeds 5250 mV.
# '''Digital Inputs (DIN1, DIN2, DIN3):''' If any configured digital input becomes active.
# '''iButton:''' If an authorized iButton is attached.
 
=== 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'''.
 
=== Expected Behavior ===
 
With these settings, the device will:
# Detect when a vehicle is stationary with a valid GNSS fix and create a geozone at the last known location.
# 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.
# Automatically reset when a configured '''deactivation source''' (e.g., power voltage, digital input, or iButton) is activated.


'''Priority'''
*'''Disable''' - disable scenario.
*'''Low Priority''' - when low priority event is triggered, device '''makes additional record''' with indication of event cause.
*'''High Priority''' - module makes additional record with High priority flag and '''sends event packet immediately''' to the server by '''GPRS'''.
<br>
<br>


==Towing Detection==
==Towing Detection==
[[File:FTX towing detection.png|right|500 px]]
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:
# '''Ignition Source''' – Used to detect whether the vehicle is turned ON or OFF.
# '''Movement Source''' – Used to determine if the vehicle is moving or stationary.
# '''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''', and a '''digital output (DOUT)''' can be triggered.
* Once the towing stops, the scenario '''logs an event''' and cancels the DOUT before resetting.


[[File:FTX towing detection.png|right|500 px]]
=== 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.
* '''DOUT can be activated''' to trigger an alert or external system.
'''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''' and cancels the DOUT.
'''Reset & Restart:'''
* After detecting the end of towing, the scenario resets and returns to the '''waiting for activation''' state.


<!-- TBD
=Other features=
=Other features=
==Fall down detection==
==Fall down detection==
[[File:FTX fall down detection.png|right|500 px]]
[[File:FTX fall down detection.png|right|500 px]]


==Static navigation==
==Static navigation==
Line 180: Line 510:
''Static Navigation Mode'' is a filter, which filters out track jumps when the object is stationary.<br><br>
''Static Navigation Mode'' is a filter, which filters out track jumps when the object is stationary.<br><br>
If the Static navigation filter is disabled, it will apply no changes to GPS data. If the Static navigation filter is enabled, it will filter changes in GPS position if no movement (based on the configured movement source) or ignition (based on the configured ignition source) is detected. The specific filtering behavior depends on the selected static navigation settings, which can be configured to respond to movement, ignition, or both. It allows filtering GPS jumps when an object is parked and GPS position is still traced.<br><br>
If the Static navigation filter is disabled, it will apply no changes to GPS data. If the Static navigation filter is enabled, it will filter changes in GPS position if no movement (based on the configured movement source) or ignition (based on the configured ignition source) is detected. The specific filtering behavior depends on the selected static navigation settings, which can be configured to respond to movement, ignition, or both. It allows filtering GPS jumps when an object is parked and GPS position is still traced.<br><br>
<br />
<br>
<br>
<br />
<br>
<br>


==Custom scenarios==
==Custom scenarios==
[[File:FTX custom scenarios.png|right|500 px]]
[[File:FTX custom scenarios.png|right|500 px]]


==Ignition ON counter==
==Ignition ON counter==
[[File:FTX ignition on counter.png|right|500 px]]
[[File:FTX ignition on counter.png|right|500 px]]
-->

Revision as of 17:41, 28 February 2025

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.

Expected Behavior

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

Overview

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.

Expected Behavior

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

Expected Behavior

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

Overview

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.

Configuration Options

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 the Algorithm 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).

Eco Driving State Machine

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.

Prerequisites for Eco Driving Functionality

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.

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. Additionally, this scenario can notify the driver by activating DOUT that this event was activated.

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.

Output control – Digital output selection that will determine which digital output will be enabled.

DOUT ON duration (ms) - Time in milliseconds that determines how long DOUT will be in ON state.

DOUT OFF duration (ms) - Time in milliseconds that determines how long DOUT will be in OFF 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

  • When the modem senses potential signal jamming, it waits for the specified Jamming Detection Delay to confirm it.
  • If the signal jamming persists for the entire delay period, a “Jamming started” event record is generated.
  • If the jamming ceases after it has started, a “Jamming ended” event is generated immediately.

Expected Behavior

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.

Expected Behavior

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

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. Digital Inputs (DIN1, DIN2, DIN3): If any configured digital input becomes active.
  8. iButton: If an authorized iButton is attached.

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.

Expected Behavior

With these settings, the 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.


Towing Detection

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, and a digital output (DOUT) can be triggered.
  • Once the towing stops, the scenario logs an event and cancels the DOUT before resetting.

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.
  • DOUT can be activated to trigger an alert or external system.

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 and cancels the DOUT.

Reset & Restart:

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