TAT240 System settings

From Teltonika Telematics Wiki
Revision as of 12:47, 11 July 2024 by Irmantas.K (talk | contribs)

(diff) ← Older revision | Approved revision (diff) | Latest revision (diff) | Newer revision → (diff)
Main Page > Autonomous Trackers > TAT240 > TAT240 Configuration > TAT240 System settings

System Settings

Data Protocol

User can choose which protocol version to use for data sending to server.

  • Codec 8 supports up to 255 AVL ID;
  • Codec 8 Extended supports up and above 255 AVL ID.



Location Settings

GNSS Source settings

User can configure which GNSS system(s) to use.
User has a choice to use only one system between GPS, GLONASS, Galileo or Beidou and it is possible to choose two or three systems together. One exception is that you cannot combine BeiDou and GLONASS systems together.

Examples of non-configurable GNSS source combinations are:

  • GLONASS + BeiDou;
  • Galileo + GLONASS + BeiDou;
  • GPS + GLONASS + BeiDou;
  • GPS + Galileo + GLONASS + BeiDou.

List of configurable GNSS sources:

  • GPS only;
  • GPS + BeiDou;
  • GPS + GLONASS;
  • GPS + GLONASS + Galileo.

GNSS control

User can manually turn ON/OFF the GNSS module. For example, if button 'Turn off GNSS' is pressed and device is trying to acquire GNSS fix for a record, it will turn GNSS back on. If GNSS module is turned ON using 'Turn on GNSS' button, it will be active for undefined period of time until USB is disconnected and device is going to sleep, record sending is finished or the 'Turn off GNSS' button is pressed again.

Coordinate acquisition timeout

The configured time adds a delay when the coordinates of the device are taken to stabilize and ensure accuracy. Important thing to note that TAT100 can take up to 180 seconds to get the GPS fix and the configured timeout would only go after the GPS fix timeout has finished or the coordinates were received.

Static Navigation Settings

Static navigation helps to save power by not enabling the GPS module and instantly generating a record if movement was not detected.

When enabled the device monitors the accelerometer and registers movement events by configured movement sensitivity. When the device wakes up to save and send a periodic record, and movement was not registered, the device will use the last known coordinates and will generate a record without turning ON the GPS module. However, if there are no last known coordinates, then the device will enable the GPS module and will try to get a new GPS fix.

The functionality is illustrated in the flowchart below:

Movement sensitivity

This feature sets the sensitivity threshold levels for movement event registration. Higher configured level makes the device “less sensitive” and vice versa. Currently, there are 10 configurable Movement Sensitivity levels. Levels are measured in mG - thousandth parts of the gravitational force equivalent or gravitational acceleration of Earth (9.8 m/s). It means that if Movement Sensitivity is set to 1000 mG, the device has to be free falling, experience fierce stops/accelerations or vibrations to detect movement.

Time Synchronization

User can select which NTP server (it is possible to configure up to two servers) and what time period to use to re-synchronize time.

Configurable NTP server (it is possible to configure up to two servers) and what time period to use to re-synchronize time.

Parameter ID Name Value/Type Min Value Max Value Default Value
901 NTP Resync (hours) uint8 0 24 3
902 NTP Server 1 char 0 55 avl1.teltonika.lt
903 NTP Server 2 char 0 55 pool.ntp.org

Time synchronization works by waiting a minute on startup to acquire fix and consequently synchronizes the time via GNSS. If the firmware acquires the fix, it starts working in the syncing by GNSS state. This state checks the difference of RTC and GNSS times every second. If the difference of at least 3 seconds persists to be for 5 seconds, the firmware triggers a procedure by GNSS.

After that, the the time difference is still calculated, but the difference is expected to persist for at least 5 minutes to trigger a GNSS time resynchronization. This is done to prevent false GNSS timestamps (such as year 2080 and etc.). If there’s no time difference found, the difference is expected to persist again for a period of 5 seconds later on when calculating. In the case that there is no fix or it is lost during the syncing by GNSS state, the firmware goes to state of syncing by NTP.

Entering the state of NTP syncing, the firmware immediately attempts to synchronize the time by triggering NTP and later on, does this periodically every time the configured NTP resynchronization time is reached. If the NTP resynchronization time is set to 0, no periodical resynchronization is done in this state. Time synchronization by NITZ can occur any time.