Jump to content

TEST-T: Difference between revisions

From Teltonika Telematics Wiki
No edit summary
 
(75 intermediate revisions by 2 users not shown)
Line 1: Line 1:
== Fall Down Detection ==
== Dead Reckoning ==
Fall down detection is a feature which is used to detect when a two-wheeler vehicle has fallen overThe 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.
'''Dead Reckoning''' is a navigation technique used to estimate current position of vehicle   , direction of movement, based on its previous position and known speedIt uses additional sensor data to correct the position received from GNSS receiver.<br>


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.
Usage of Dead Reckoning is essential in scenarios where GNSS signal is weak or unavailable, such as underground parking lots, tunnels or dense forests.<br>


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.
'''Note:''' Dead Reckoning is enabled for all FT platform devices with gyroscope. At the moment, it’s not possible to disable it.<br>


=== <u>Prerequisites and Important Settings </u> ===
Key points to understand before utilizing the Dead Reckoning functionality:
* Installation
* Configuration
* Alignment


* All accelerometer-related features, including fall down detection depend on secure device mounting to function properly. See “Mounting recommendations” [link].
=== <u>Prerequisites and Important Settings</u> ===
* 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.
* Device mounting quality  – Correct device mounting is critical for Dead Reckoning operation. Improper mounting may result in incorrect sensor data and unreliable Dead Reckoning performance.
* 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.
* Dead Reckoning alignment maintenance – If Dead Reckoning alignment parameters are no longer valid, send the DR_RESET command and perform calibration.
* 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'''.
* Electric and hybrid vehicles – For electric and hybrid vehicles, DIN1 should be used for movement detection to ensure correct Dead Reckoning operation.


=== <u> Basic Operation </u> ===
=== <u>Basic Operation</u> ===


* Once the feature is enabled, the device waits until the conditions for base vector calculation are met.
'''<u>Installation</u>'''<br>
* 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>===
The device must be mounted firmly in the vehicle, with good visibility of the sky. Failure to ensure proper mounting will result in inability to calibrate the device or inaccurate position estimation. DIN1 should be connected to the vehicle ignition (''' applicable to trackers with DIN1'''), it will be used to detect both ignition status and movement, ensuring optimal performance. Following examples ensure that the GNSS antenna is facing towards the sky and there are no physical obstacles, like metal plates,  wires, are blocking the GNSS signal.  
''Will be added soon''.  


== Network Jamming Extension with DOUT Control ==
Good '''mounting''' examples ( <span style="color:red">'''If vehicle has a heated windshield, you should look for an alternative mounting location in the trunk, on some sturdy metal closer to backseat window'''</span>):<br>
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.
<div style="display: flex; flex-direction: row;">
[[File:FTC927 under the front dashboard in the middle of the car.jpg|thumb|left|280px|link=Special:Redirect/file/FTC927 under the front dashboard in the middle of the car.jpg|Dashboard in the middle of the car mount]]
[[File:FTC927 beneath the speedometer panel.jpg|thumb|left|300px|link=Special:Redirect/file/FTC927 beneath the speedometer panel.jpg|Beneath the speedometer panel]]
[[File:FTC927 above the glove box.jpg|thumb|left|300px|link=Special:Redirect/file/FTC927 above the glove box.jpg|Above glove box]]
</div>


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.
Bad '''mounting'''  examples:<br>
<div style="display: flex; flex-direction: row;">
[[File:Dead Reckoning Unwanted movements will be detected by the IMU.png|thumb|left|280px|link=Special:Redirect/file/Dead Reckoning Unwanted movements will be detected by the IMU.png|Unwanted movements will be detected by the IMU]]
[[File:Dead Reckoning Metal parts above the mount.png|thumb|left|300px|link=Special:Redirect/file/Dead Reckoning Metal parts above the mount.png|Metal parts above the mount]]
[[File:Dead Reckoning vibration could cause unwanted device movements.png|thumb|left|300px|link=Special:Redirect/file/:Dead Reckoning vibration could cause unwanted device movements.png|Places, where vibration could cause unwanted device movements]]
</div>


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>Configuration</u>'''<br>


=== <u>Prerequisites and Important Settings </u> ===
[[File:Dead Recknonig TCT panel_2.png|right|500px]]
* 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 Dead Reckoning feature is configurable via the Dead Reckoning section in the GNSS settings group under System view in TCT.''
* 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>===
Parameter list can be found [[Template:FTX_System#Parameter_list|here]].
''Will be added soon''.  


== Auto Geofence ==
===== Dead Reckoning alignment status =====
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 Dead Reckoning alignment status is a 1-byte AVL ID (1433) that indicates the current status of the Dead Reckoning alignment. The possible values are:<br>
* '''0''' - Unknown: Dead Reckoning status is unknown.
* '''1''' - Init: Dead Reckoning alignment is initializing.
* '''2''' - Coarse: Dead Reckoning is in alignment stage.
* '''3''' - Stable: Dead Reckoning alignment stage has been completed. Estimation stage is in progress.
* '''99''' - Standby: Dead Reckoning is in standby mode ('''NOTE''': this status is availabe with 3.7.X or newer firmware version)


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.
===== Turning alignment =====
The turning alignment is a 1-byte AVL ID ('''1434''') that indicates the current percentage of the turning alignment of the device.


=== <u>Prerequisites and Important Settings </u> ===
===== Straight alignment =====
* The device must have a reliable GNSS signal and be able to detect its movement status for the feature to arm correctly.
The straight alignment is a 1-byte AVL ID ('''1435''') that indicates the current percentage of the straight alignment of the device.
* 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>===
'''<u>Alignment</u>'''<br>
''Will be added soon''.  
Once device mounting adheres to the guidelines, alignment can be performed. The device '''must finish''' a specific alignment process to '''determine''' its mounting orientation. During this process, there are specific conditions that must be met:
# The device must be '''stationary''' with clear sky visibility for at least 3 minutes.
<!--# A great number of '''left and right''' turns must be performed.-->
# Vehicle speed during alignment should be between 10 km/h and 100 km/h, with varying speeds preferred over extended constant-speed driving.
# Avoid driving in underground tunnels or areas with poor GNSS signal, otherwise alignment needs to be restarted from the second step.
[[File:Dead Reckoning TCT Swift .png|right|400px]]


'''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>Standby mode</u> ===


=== <u> Limitations, Edge Cases & Additional Notes  </u> ===
Standby Mode preserves Dead Reckoning calibration indefinitely, ensuring accurate position estimation after extended GNSS outages (e.g., a week in underground parking), and supports unlimited duration in this mode while maintaining full calibration integrity.
* 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 ==
Standby Mode has two behavior options:
Ignition ON Counter feature continuously tracks how long a vehicle has spent with the active ignition.  
* '''Realignment''' – Calibration alignment is discarded after the Standby Timeout period.
* '''Preserve alignment''' – Calibration alignment is retained during prolonged stationary periods.


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.  
'''<u>Prerequisites and important Settings</u>'''<br>
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.
* If the device is remounted, send the DR_Reset SMS command and perform a full recalibration. This ensures all orientation- and sensor alignment parameters are refreshed, preventing inaccurate Dead Reckoning calculations after the installation change.
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>Basic Operation</u>'''<br>


=== <u>Prerequisites and Important Settings </u> ===
'''Entering Standby Mode'''
* 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> ===
The device can enter Standby Mode in two scenarios:
* Ignition ON counter scenario starts, when it is enabled in configurator’s Features section.
* No movement detected
* It monitors the state of ignition source.
If the device detects absence of movement, Dead Reckoning enters Standby Mode after the timeout defined by '''Standby timeout (ID 124)''' elapses.
Suitable Ignition source can be set in System settings section, under Ignition settings.
* Device enters sleep mode
* When ignition source state changes to ON, counting of active ignition time starts (in seconds). It increments counter every 500ms.  
When the device transitions into sleep mode, the GNSS receiver is switched to power saving mode.
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.


Before GNSS powers down, Dead Reckoning enters Standby Mode '''immediately''', the scenario is paused, and the device proceeds into sleep mode.


=== <u> Parameters list </u>===
'''Exiting Standby Mode'''
''Will be added soon''.


Standby Mode can be exited in the following cases:
* Movement is detected
When movement is detected, the device exits Standby Mode and resumes normal Dead Reckoning operation. If '''no movement is detected''', Dead Reckoning remains in Standby Mode.


=== <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 ==  
=== <u>Limitations, Edge Cases & Additional Notes</u> ===
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.  
There are some important things to keep in mind when using the Dead Reckoning functionality. The algorithm tries to correct for these issues, but sometimes they can still affect how well Dead Reckoning works.
* '''Loss of alignment during drifting''' – Dead Reckoning alignment may be lost during drifting, when the actual movement vector does not correspond to the vehicle heading. Re‑alignment is required.
* '''Overshooting''' - May occur when the vehicle travels straight for more than 50 m at speeds below 20 km/h. In such cases, positional overshoot may be observed. An example is shown in the attached image.


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.
* '''Position accuracy may decrease''' - If the device cannot receive a GNSS signal for a long time, the estimated position may become less accurate. This is because the sensors inside the device can only estimate the position for a limited time without help from GNSS.
 
For example: If a courier spends up to 30 minutes unloading in the underground car park, DR will remain accurate. Otherwise, positioning information will become less accurate.
==='''Formula:'''===
* '''Temperature effects''' - The accuracy of the position can change if the temperature is very different from when the device was last calibrated.
Parameter_ID = 1,000,000 + (AVL_ID * 100) + OPTION Parameter_ID = 1,000,000 + (AVL_ID * 100) + OPTION
* '''Alignment reset''' - If the device loses power or goes into sleep mode, it will need to be calibrated again.
 
* 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''' ===
'''Tip:''' If alignment auto-save is enabled, realignment will be faster.
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'''''
* '''Position jumps after GNSS outages''' - Multipath occurs when reflected or diffracted GNSS signals reach the receiver, causing position errors. Since Dead Reckoning depends on GNSS for continuous correction, these multipath induced inaccuracies can lead to visible position jumps, especially in urban areas with tall buildings or obstructions.
1. '''CAN Type'''
[[File:GNSS Multipath.png|350px]]
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'''
=== <u>AVL ID list</u> ===
* '''MCAN0''' (IO number = 0):  
<table class="nd-othertables_2" style="width:100%; border-collapse: collapse;">
** '''CAN Type:''' 17000 + (10 × 0) = 17000
<tr>
** '''CAN ID:''' 17001 + (10 × 0) = 17001
<th style="width:8%; vertical-align: middle; text-align: left;">Property ID in AVL packet</th>
** '''Data Mask:''' 17002 + (10 × 0) = 17002
<th style="width:15%; vertical-align: middle; text-align: center;">Property Name</th>
* '''MCAN1''' (IO number = 1):  
<th style="width:5%; vertical-align: middle; text-align: center;">Bytes</th>
** '''CAN Type:''' 17000 + (10 × 1) = 17010
<th style="width:10%; vertical-align: middle; text-align: center;">Min Value</th>
** '''CAN ID:''' 17001 + (10 × 1) = 17011
<th style="width:10%; vertical-align: middle; text-align: center;">Max Value</th>
** '''Data Mask:''' 17002 + (10 × 1) = 17012
<th style="width:5%; vertical-align: middle; text-align: center;">Multiplier</th>
* '''MCAN69''' (IO number = 69):  
<th style="width:5%; vertical-align: middle; text-align: center;">Units</th>
** '''CAN Type:''' 17000 + (10 × 69) = 17690
<th style="width:32%; vertical-align: middle; text-align: left;">Description</th>
** '''CAN ID:''' 17001 + (10 × 69) = 17691
</tr>
** '''Data Mask:''' 17002 + (10 × 69) = 17692
<tr>
<td style="vertical-align: middle; text-align: center;">1433</td>
<td style="vertical-align: middle; text-align: center;">Dead Reckoning alignment status</td>
<td style="vertical-align: middle; text-align: center;">1</td>
<td style="vertical-align: middle; text-align: center;">0</td>
<td style="vertical-align: middle; text-align: center;">99</td>
<td style="vertical-align: middle; text-align: center;">1</td>
<td style="vertical-align: middle; text-align: center;"> </td>
<td style="vertical-align: middle; text-align: center;">[[{{{model}}}_System#Dead_Reckoning_alignment_status|Dead Reckoning alignment status]]</td>
</tr>
<tr>
<td style="vertical-align: middle; text-align: center;">1434</td>
<td style="vertical-align: middle; text-align: center;">Turning alignment</td>
<td style="vertical-align: middle; text-align: center;">1</td>
<td style="vertical-align: middle; text-align: center;">0</td>
<td style="vertical-align: middle; text-align: center;">100</td>
<td style="vertical-align: middle; text-align: center;">1</td>
<td style="vertical-align: middle; text-align: center;">%</td>
<td style="vertical-align: middle; text-align: center;">[[{{{model}}}_System#Turning_alignment|Turning alignment]]</td>
</tr>
<tr>
<td style="vertical-align: middle; text-align: center;">1435</td>
<td style="vertical-align: middle; text-align: center;">Straight alignment</td>
<td style="vertical-align: middle; text-align: center;">1</td>
<td style="vertical-align: middle; text-align: center;">0</td>
<td style="vertical-align: middle; text-align: center;">100</td>
<td style="vertical-align: middle; text-align: center;">1</td>
<td style="vertical-align: middle; text-align: center;">%</td>
<td style="vertical-align: middle; text-align: center;">[[{{{model}}}_System#Straight alignment|Straight alignment]]</td>
</tr>
</table>


'''Putting It All Together'''
=== <u>Parameter list</u> ===
1. '''Check Your AVL ID Range'''  
<table class="nd-othertables_2" style="width:100%; border-collapse: collapse;">
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.
<tr>
2. '''Identify Your MCAN IO Number'''  
<th style="width:8%; vertical-align: middle; text-align: left;">Property ID in AVL packet</th>
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.
<th style="width:15%; vertical-align: middle; text-align: center;">Property Name</th>
3. '''Plug In the Numbers'''  
<th style="width:5%; vertical-align: middle; text-align: center;">Bytes</th>
a. Calculate step by step, ensuring you add the correct base offsets and multipliers.
<th style="width:10%; vertical-align: middle; text-align: center;">Min Value</th>
4. '''Configure Your Device'''
<th style="width:10%; vertical-align: middle; text-align: center;">Max Value</th>
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.
<th style="width:5%; vertical-align: middle; text-align: center;">Multiplier</th>
<th style="width:5%; vertical-align: middle; text-align: center;">Units</th>
<th style="width:32%; vertical-align: middle; text-align: left;">Description</th>
</tr>
<tr>
<td style="vertical-align: middle; text-align: center;">123</td>
<td style="vertical-align: middle; text-align: center;">Alignment auto-save</td>
<td style="vertical-align: middle; text-align: center;">-</td>
<td style="vertical-align: middle; text-align: center;">0</td>
<td style="vertical-align: middle; text-align: center;">1</td>
<td style="vertical-align: middle; text-align: center;">-</td>
<td style="vertical-align: middle; text-align: center;">-</td>
<td style="vertical-align: middle; text-align: center;">This option saves calibration data to device memory, enabling a faster recalibration after device restart. <br> '''0''' = Disable <br> '''1''' = Enable  </td>
</tr>
<tr>
<td style="vertical-align: middle; text-align: center;">124</td>
<td style="vertical-align: middle; text-align: center;">Standby timeout</td>
<td style="vertical-align: middle; text-align: center;">-</td>
<td style="vertical-align: middle; text-align: center;">1</td>
<td style="vertical-align: middle; text-align: center;">65535</td>
<td style="vertical-align: middle; text-align: center;">1</td>
<td style="vertical-align: middle; text-align: center;">(s) seconds</td>
<td style="vertical-align: middle; text-align: center;">The standby timeout is the time after which device will attempt to correct the position based on correction strategy.<br>  Default value = '''1800''' </td>
</tr>
<tr>
<td style="vertical-align: middle; text-align: center;">125</td>
<td style="vertical-align: middle; text-align: center;">Standby mode</td>
<td style="vertical-align: middle; text-align: center;">-</td>
<td style="vertical-align: middle; text-align: center;">0</td>
<td style="vertical-align: middle; text-align: center;">1</td>
<td style="vertical-align: middle; text-align: center;">-</td>
<td style="vertical-align: middle; text-align: center;">-</td>
<td style="vertical-align: middle; text-align: center;">The standby mode is the mode in which the device will attempt to correct the position based on correction strategy. <br>'''0''' = Realignment<br>'''1''' = Preserve alignment</td>
</tr>
</table>

Latest revision as of 15:45, 9 April 2026

Dead Reckoning

Dead Reckoning is a navigation technique used to estimate current position of vehicle , direction of movement, based on its previous position and known speed. It uses additional sensor data to correct the position received from GNSS receiver.

Usage of Dead Reckoning is essential in scenarios where GNSS signal is weak or unavailable, such as underground parking lots, tunnels or dense forests.

Note: Dead Reckoning is enabled for all FT platform devices with gyroscope. At the moment, it’s not possible to disable it.

Key points to understand before utilizing the Dead Reckoning functionality:

  • Installation
  • Configuration
  • Alignment

Prerequisites and Important Settings

  • Device mounting quality – Correct device mounting is critical for Dead Reckoning operation. Improper mounting may result in incorrect sensor data and unreliable Dead Reckoning performance.
  • Dead Reckoning alignment maintenance – If Dead Reckoning alignment parameters are no longer valid, send the DR_RESET command and perform calibration.
  • Electric and hybrid vehicles – For electric and hybrid vehicles, DIN1 should be used for movement detection to ensure correct Dead Reckoning operation.

Basic Operation

Installation

The device must be mounted firmly in the vehicle, with good visibility of the sky. Failure to ensure proper mounting will result in inability to calibrate the device or inaccurate position estimation. DIN1 should be connected to the vehicle ignition ( applicable to trackers with DIN1), it will be used to detect both ignition status and movement, ensuring optimal performance. Following examples ensure that the GNSS antenna is facing towards the sky and there are no physical obstacles, like metal plates, wires, are blocking the GNSS signal.

Good mounting examples ( If vehicle has a heated windshield, you should look for an alternative mounting location in the trunk, on some sturdy metal closer to backseat window):

Dashboard in the middle of the car mount
Beneath the speedometer panel
Above glove box

Bad mounting examples:

Unwanted movements will be detected by the IMU
Metal parts above the mount
Places, where vibration could cause unwanted device movements

Configuration

The Dead Reckoning feature is configurable via the Dead Reckoning section in the GNSS settings group under System view in TCT.

Parameter list can be found here.

Dead Reckoning alignment status

The Dead Reckoning alignment status is a 1-byte AVL ID (1433) that indicates the current status of the Dead Reckoning alignment. The possible values are:

  • 0 - Unknown: Dead Reckoning status is unknown.
  • 1 - Init: Dead Reckoning alignment is initializing.
  • 2 - Coarse: Dead Reckoning is in alignment stage.
  • 3 - Stable: Dead Reckoning alignment stage has been completed. Estimation stage is in progress.
  • 99 - Standby: Dead Reckoning is in standby mode (NOTE: this status is availabe with 3.7.X or newer firmware version)
Turning alignment

The turning alignment is a 1-byte AVL ID (1434) that indicates the current percentage of the turning alignment of the device.

Straight alignment

The straight alignment is a 1-byte AVL ID (1435) that indicates the current percentage of the straight alignment of the device.

Alignment
Once device mounting adheres to the guidelines, alignment can be performed. The device must finish a specific alignment process to determine its mounting orientation. During this process, there are specific conditions that must be met:

  1. The device must be stationary with clear sky visibility for at least 3 minutes.
  2. Vehicle speed during alignment should be between 10 km/h and 100 km/h, with varying speeds preferred over extended constant-speed driving.
  3. Avoid driving in underground tunnels or areas with poor GNSS signal, otherwise alignment needs to be restarted from the second step.

Standby mode

Standby Mode preserves Dead Reckoning calibration indefinitely, ensuring accurate position estimation after extended GNSS outages (e.g., a week in underground parking), and supports unlimited duration in this mode while maintaining full calibration integrity.

Standby Mode has two behavior options:

  • Realignment – Calibration alignment is discarded after the Standby Timeout period.
  • Preserve alignment – Calibration alignment is retained during prolonged stationary periods.


Prerequisites and important Settings

  • If the device is remounted, send the DR_Reset SMS command and perform a full recalibration. This ensures all orientation- and sensor alignment parameters are refreshed, preventing inaccurate Dead Reckoning calculations after the installation change.

Basic Operation

Entering Standby Mode

The device can enter Standby Mode in two scenarios:

  • No movement detected

If the device detects absence of movement, Dead Reckoning enters Standby Mode after the timeout defined by Standby timeout (ID 124) elapses.

  • Device enters sleep mode

When the device transitions into sleep mode, the GNSS receiver is switched to power saving mode.

Before GNSS powers down, Dead Reckoning enters Standby Mode immediately, the scenario is paused, and the device proceeds into sleep mode.

Exiting Standby Mode

Standby Mode can be exited in the following cases:

  • Movement is detected

When movement is detected, the device exits Standby Mode and resumes normal Dead Reckoning operation. If no movement is detected, Dead Reckoning remains in Standby Mode.


Limitations, Edge Cases & Additional Notes

There are some important things to keep in mind when using the Dead Reckoning functionality. The algorithm tries to correct for these issues, but sometimes they can still affect how well Dead Reckoning works.

  • Loss of alignment during drifting – Dead Reckoning alignment may be lost during drifting, when the actual movement vector does not correspond to the vehicle heading. Re‑alignment is required.
  • Overshooting - May occur when the vehicle travels straight for more than 50 m at speeds below 20 km/h. In such cases, positional overshoot may be observed. An example is shown in the attached image.
  • Position accuracy may decrease - If the device cannot receive a GNSS signal for a long time, the estimated position may become less accurate. This is because the sensors inside the device can only estimate the position for a limited time without help from GNSS.

For example: If a courier spends up to 30 minutes unloading in the underground car park, DR will remain accurate. Otherwise, positioning information will become less accurate.

  • Temperature effects - The accuracy of the position can change if the temperature is very different from when the device was last calibrated.
  • Alignment reset - If the device loses power or goes into sleep mode, it will need to be calibrated again.

Tip: If alignment auto-save is enabled, realignment will be faster.

  • Position jumps after GNSS outages - Multipath occurs when reflected or diffracted GNSS signals reach the receiver, causing position errors. Since Dead Reckoning depends on GNSS for continuous correction, these multipath induced inaccuracies can lead to visible position jumps, especially in urban areas with tall buildings or obstructions.

AVL ID list

Property ID in AVL packet Property Name Bytes Min Value Max Value Multiplier Units Description
1433 Dead Reckoning alignment status 1 0 99 1 [[{{{model}}}_System#Dead_Reckoning_alignment_status|Dead Reckoning alignment status]]
1434 Turning alignment 1 0 100 1 % [[{{{model}}}_System#Turning_alignment|Turning alignment]]
1435 Straight alignment 1 0 100 1 % [[{{{model}}}_System#Straight alignment|Straight alignment]]

Parameter list

Property ID in AVL packet Property Name Bytes Min Value Max Value Multiplier Units Description
123 Alignment auto-save - 0 1 - - This option saves calibration data to device memory, enabling a faster recalibration after device restart.
0 = Disable
1 = Enable
124 Standby timeout - 1 65535 1 (s) seconds The standby timeout is the time after which device will attempt to correct the position based on correction strategy.
Default value = 1800
125 Standby mode - 0 1 - - The standby mode is the mode in which the device will attempt to correct the position based on correction strategy.
0 = Realignment
1 = Preserve alignment