TEST-T

Fall Down Detection

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

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

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

Prerequisites and Important Settings

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

Basic Operation

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

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

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

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

Parameters list

Will be added soon.

Network Jamming Extension with DOUT Control

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

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

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

Prerequisites and Important Settings

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

Basic operation

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

Parameters list

Will be added soon.

Auto Geofence

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

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

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

Prerequisites and Important Settings

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

Basic Operation

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

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

Parameters list

Will be added soon.

Limitations, Edge Cases & Additional Notes

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

Device sleep and wake up on scheduled time to send record

This feature, also known as the Scheduler, allows the device to wake up from a low-power sleep mode at pre-configured times to acquire a GNSS position and send a data record to a server. However, this feature can operate in any power Mode.

This functionality is essential for asset tracking scenarios where power conservation is critical, such as monitoring trailers, containers, or any equipment without a constant power source. By waking up only at specified intervals to report its location, the device can operate on its internal battery for extended periods.

The user can define up to six unique scheduled times for each weekday. At each configured time, the device exits its sleep state, activates its GNSS module to determine its current location, establishes a connection to send the data, and then returns to the same Mode until the next scheduled event. This ensures periodic updates while maximizing battery life.

Prerequisites and Important Settings

• The device must be configured to operate in a sleep mode that supports scheduled wake-ups, such as "Deep Sleep" or "Online Deep Sleep" mode. This is typically configured in System > Power saving settings > Mode.
• Accurate time synchronization is required for the scheduler to function correctly. The device must be able to acquire the current time, either from a GNSS satellite fix or through an NTP server, before the schedules can be reliably executed.
• The device must have a server configured for data sending in Mobile Network > Primary server settings.

Basic Operation

• Entering Sleep Mode:

○ After its initial configuration and data sending, the device enters the selected low-power sleep mode. In this state, most modules, including GNSS and the modem, are powered down to conserve energy.

• Scheduled Wake-up:
  • The device's internal clock continuously runs. When the current time matches one of the configured schedules, the device initiates the wake-up sequence.
  • The main controller powers on the GNSS module to acquire a satellite fix and determine the current coordinates.
• Data Record and Transmission:
  • Once a position fix is obtained, the device powers on the modem.
  • It creates a new data record containing the latest location information and other configured I/O parameters.
  • The device establishes a connection to the server and sends the record.
• Returning to Sleep:
  • After successfully sending the record, the device powers down the GNSS and modem modules.
  • It then returns to the low-power sleep mode, awaiting the next scheduled wake-up time.
  • If the device fails to get a GNSS fix or send the data within a predefined timeout, it will abort the process and return to sleep to prevent battery drain.

Parameters list

Will be added soon.

Note: Wakeup times in configuration are stored as a list of uint16 variables in format HHmm (range from 0 to 2359), for example: 12:00 -> 1200, 01:45 -> 145, 23:59 -> 2359. Default value for unconfigured timestamps is 2500.

Limitations, Edge Cases & Additional Notes

• A maximum of six unique schedules can be configured per weekday.
• The reliability of this feature is dependent on the device's ability to acquire a GNSS signal at the scheduled time. If the device is in a location with poor signal (e.g., indoors, underground garage), it may fail to get a fix and will not send a record.
• If the device's internal battery is completely drained, it will lose time synchronization and will not be able to execute scheduled wake-ups until it is powered on and can sync its clock again.

Ignition ON counter

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

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

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

Prerequisites and Important Settings

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

Basic Operation

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

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

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

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

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

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

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

Parameters list

Will be added soon.

Limitations, Edge Cases & Additional Notes

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

Manual CAN

The user can configure 70 Manual CAN I/O element by setting Priority, CAN Type, CAN ID, Data Mask, Operand. Each CAN I/O has its own parameters and can be configured independentely.

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 1. CAN Type Parameter ID=17,000+(10×MCAN IO number) 2. CAN ID Parameter ID=17,001+(10×MCAN IO number) 3. 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
1. 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.
  

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

3. Plug In the Numbers

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

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

Manual Geofence

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

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

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

Prerequisites and Important Settings

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

Basic Operation

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

• In-Zone: Indicates whether the device is inside the geozone.
• 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. The frame border prevents false exit detections. AVL IDs:

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

Parameters list

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

Will be added soon.

Geozone Parameter ID Calculation

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

Will be added soon.

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

Examples:

• Priority of Geozone 1:

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

• Speed limit threshold of Geozone 2:

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

Eye-Sensor activity monitoring scenario

Introduction

The Activity Monitoring Scenario is designed to track the presence of Teltonika Telematics EYE Sensor devices by monitoring their BLE advertisement data. This functionality allows the system to detect when a device appears or disappears from the monitored area, ensuring continuous tracking and logging of sensor activity. When the EYE Sensor is in the field, the scenario updates all IO elements provided by the device and generates periodic records to maintain an accurate activity log.

Functionality

The Activity Monitoring Scenario operates as follows:

Detecting BLE Advertisements:

• The scenario listens for BLE advertisement signals from EYE Sensor devices.
• If a device is detected, it is added to the active monitoring list.

Monitoring Device Presence:

• The system continuously checks for appear/disappear events.
• If a device stops sending signals (disappears), the scenario updates the monitored device list accordingly.

Updating IO Elements:

• When a device is active, the scenario updates all IO elements provided by the EYE Sensor.
• Periodic records are generated to ensure real-time status updates.

Scenario Enable/Disable Option:

• While the scenario is part of the global configuration, users have the option to enable or disable it manually.
• By default, the Activity Monitoring Scenario is always enabled.

Prerequisites

To ensure proper operation of the Activity Monitoring Scenario, the following conditions must be met: Device Compatibility:

• The scenario requires a Teltonika Telematics EYE Sensor with BLE functionality.
• The tracking device must support BLE scanning and advertisement processing.

Firmware & Configuration:

• The device must run a firmware version that supports Activity Monitoring.
• The scenario must be enabled in the device’s configuration settings (if not using the default setting).

BLE Signal Conditions:

• The EYE Sensor must be within range of the tracking device’s BLE receiver.
• BLE signal interference should be minimized to ensure consistent detection.

Power & Connectivity:

• The tracking device should be powered on and capable of processing BLE advertisements.
• A stable power supply is required to maintain continuous monitoring.

Data Collection & Logging:

• The device must be configured to log periodic records for accurate activity tracking.
• Ensure the system has sufficient storage capacity for storing sensor data.

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.

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.

Vehicle Immobilizer Functionality with iButton Integration

The Immobilizer feature provides an additional layer of vehicle security by requiring driver authorization after the ignition is turned on. It is designed to block the vehicle's starter circuit, preventing the engine from being started until an authorized identification element is presented.

This functionality is essential for preventing vehicle theft and ensuring that only permitted individuals can operate a vehicle. By linking vehicle operation to a physical token, it significantly enhances security for fleet management, rental services, and any application where control over vehicle access is a priority.

The feature operates based on the vehicle's ignition status. When the ignition is turned on, the system enters a "Waiting authorization" state, activating a digital output to keep the starter blocked. Upon successful presentation of an authorized element, the system transitions to an "Authorized" state, deactivates the output, and allows the engine to run. The authorization is automatically revoked after the ignition has been off for a configurable period.

Prerequisites and Important Settings

• The vehicle's ignition status must be monitored by one of the device's digital inputs (DIN).
• A relay must be correctly installed to interrupt the vehicle's starter circuit and connected to one of the device's configurable digital outputs (DOUT).
• An iButton reader or a properly configured BLE sensor is required to detect the authorization element.

Basic Operation

The feature's logic is managed through three distinct states: 1. Not Authorized State:

• This is the default, idle state when the vehicle's ignition is OFF. The immobilizer is armed and waiting.

2. Waiting Authorization State:

• When the ignition is turned ON, the system transitions to this state.
• If a Digital Output is configured, it is immediately activated to control the relay and block the starter circuit.
• The device actively waits for an authorization element to be presented.

3. Authorized State:

• Once an ID is detected and confirmed to be authorized, the system transitions to the Authorized state.
• The configured Digital Output is deactivated, which unblocks the starter circuit and allows the vehicle to be started and driven.
• The driver remains authorized as long as the ignition stays ON.

4. De-authorization Process:

• When the ignition is turned OFF, a de-authorization timer begins.
• If the ignition remains off for the entire duration of the configured "Ignition OFF timeout," the system revokes the authorization and returns to the Not Authorized state. If the ignition is turned back on before the timeout expires, the authorization remains active.

Parameters list

Will be added soon.

Limitations, Edge Cases & Additional Notes

• Installation Security: The overall effectiveness of the immobilizer is highly dependent on the secure and discreet installation of the control relay. If the wiring is easily accessible, it can be bypassed.