Jump to content

Template:FTX Tracking settings: Difference between revisions

From Teltonika Telematics Wiki
mNo edit summary
FTXXXX WIKI sync with 3.7.x Stage 2 - Resync
 
(4 intermediate revisions by 2 users not shown)
Line 14: Line 14:
'''Possible options:'''
'''Possible options:'''


'''After Position Fix''' - records will be saved and sent only after position fix.
'''After Position Fix''' - records will be saved and sent only after position fix. Coordinate acquisition time is configured via the "GNSS position fix search timeout" parameter.


'''After Time Sync''' - records will be saved and sent only after time synchronization.
'''After Time Sync''' - records will be saved and sent only after time synchronization. “GNSS position fix search timeout” is not used here; therefore, records may lack GNSS location data.


'''Always''' - records will always be saved and sent even if there is no time synchronization.
'''Always''' - records will always be saved and sent even if there is no time synchronization. “GNSS position fix search timeout” is not used here; therefore, records may lack GNSS location data.


'''Note''': If the record is without valid coordinates – (there were no GPS fix at the moment of data acquisition) – Longitude, Latitude and Altitude values are sent as per the last valid fix, and Angle, Satellites and Speed will be 0. However, if there is a reboot then it will send zero coordinates.  
'''Note''': If the record is without valid coordinates – (there were no GPS fix at the moment of data acquisition) – Longitude, Latitude and Altitude values are sent as per the last valid fix, and Angle, Satellites and Speed will be 0. However, if there is a reboot then it will send zero coordinates.  
Line 219: Line 219:
* The available I/O triggers depend on the hardware of your device.  
* The available I/O triggers depend on the hardware of your device.  
* The priority of the I/O trigger must be set at least to Low (see [[{{{model}}} Input/output (I/O)]]).  
* The priority of the I/O trigger must be set at least to Low (see [[{{{model}}} Input/output (I/O)]]).  
* On-demand tracking interacts with periodic record acquisition ([[{{{model}}} Tracking settings]]):  
* On-demand tracking interacts with periodic record acquisition (see [[#Records profile settings]]):  
** If the on-demand tracking “Period” is '''longer''' than the periodic record “Send period” - on-demand records will be generated '''in parallel''' with the regular periodic records.  
** If the on-demand tracking “Period” is '''longer''' than the periodic record “Send period” - on-demand records will be generated '''in parallel''' with the regular periodic records.  
** If the on-demand tracking “Period” is '''shorter or equal''' than the periodic record “Send period” - periodic record acquisition will be '''suspended''' until on-demand tracking duration elapses or on-demand tracking stop command is received.  
** If the on-demand tracking “Period” is '''shorter or equal''' than the periodic record “Send period” - periodic record acquisition will be '''suspended''' until on-demand tracking duration elapses or on-demand tracking stop command is received.  
Line 267: Line 267:
</tr>  
</tr>  
</table>
</table>
 
| FTC305
| FTM305
| ATM700
| ATM700
| ATC700 =  
| ATC700 =  
Line 282: Line 283:


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.
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.
When GNSS data is saved and transmitted according to the configured Scheduler, GNSS FIX acquisition for the next record is started earlier than the scheduled time.
The advance start time is dynamically calculated based on the GNSS FIX acquisition duration of the previous record.
Key points:
* The advance time cannot exceed the configured GNSS FIX search timeout.
* The maximum allowed advance offset is up to 10 minutes.


=== <u>Prerequisites and Important Settings </u> ===
=== <u>Prerequisites and Important Settings </u> ===

Latest revision as of 09:15, 30 April 2026