|
|
| (33 intermediate revisions by 2 users not shown) |
| Line 1: |
Line 1: |
| == Fall Down Detection ==
| | {{Template:Test-A|model=FTC305}} |
| 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.
| |
| | |
| === <u>Prerequisites and Important Settings </u> ===
| |
| | |
| * 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'''.
| |
| | |
| === <u> Basic Operation </u> ===
| |
| | |
| * 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.
| |
| | |
| === <u> Parameters list </u>===
| |
| ''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. ).
| |
| | |
| === <u>Prerequisites and Important Settings </u> ===
| |
| * 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.
| |
| | |
| === <u> Basic operation </u> ===
| |
| * 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.
| |
| | |
| === <u> Parameters list </u>===
| |
| ''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.
| |
| | |
| === <u>Prerequisites and Important Settings </u> ===
| |
| * 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.
| |
| | |
| === <u> Basic Operation </u> ===
| |
| 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).
| |
| | |
| | |
| === <u> Parameters list </u>===
| |
| ''Will be added soon''.
| |
| | |
| === <u> Limitations, Edge Cases & Additional Notes </u> ===
| |
| * '''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.
| |
| | |
| === <u>Prerequisites and Important Settings </u> ===
| |
| * 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.
| |
| | |
| === <u> Basic Operation </u> ===
| |
| * 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.
| |
| | |
| === <u> Parameters list </u>===
| |
| ''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.
| |
| | |
| === <u> Limitations, Edge Cases & Additional Notes </u> ===
| |
| * 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.
| |
| | |
| | |
| === <u>Prerequisites and Important Settings </u> ===
| |
| * 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)'''.
| |
| | |
| === <u> Basic Operation </u> ===
| |
| * 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.
| |
| | |
| | |
| === <u> Parameters list </u>===
| |
| ''Will be added soon''.
| |
| | |
| | |
| === <u> Limitations, Edge Cases & Additional Notes </u> ===
| |
| * 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'''
| |
| a. 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'''
| |
| a. 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'''
| |
| a. Calculate step by step, ensuring you add the correct base offsets and multipliers.
| |
| 4. '''Configure Your Device'''
| |
| a. 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.
| |
