Jump to content

Test-AC: Difference between revisions

From Teltonika Telematics Wiki
GTPGTM-11785 - Final draft
No edit summary
Line 1: Line 1:
===Firmware versions===
=Driver Working State Filters=
==Configuration==
[[File:Driver Working State Filters.png|right]]
'''N/A driver state''' – If parameter is disabled, the device will not save data about current minute, if driver information are not available. System bypassed to report incorrect or incomplete data.<br>
(''Parameter ID: 253'')


'''Deny driver working state when ignition off''' – If parameter is disabled, device will reject driver information when vehicle ignition is turned off.<br>
(''Parameter ID: 254'')
'''OneMinute Rule''' -  if parameter is disabled, device will continue analyzing driver data but results will not be saved and records with data will not be generated (enables or disables rule 038).<br>
(''Parameter ID: 252'')
==SMS/GPRS Commands==
*<b>tacho_dbg:x</b>, where x = 0,1
:This command allows to enable or disable basic debug information.
:Response for the command: <b>Set tacho data monitor dbg:0</b>
*<b>getparam x</b>, where x = configurator parameter (252,253,254)
:This command allows to check the value of configured parameters.
:Response for the command: <b>Param ID:252 Value:1</b>
*<b>setparam x:y</b>, where x = configurator parameter (252,253,254), y = value to write
:Command allows to set value to Configurator parameter. Available value 0,1.
:Response for that command:
:<b>Config same for 252: 1</b> – information that parameter was configured before with the same value.
:<b>Failed to update parameters</b> – there was an error during setting parameter. Value of the range.
:<b>New value 252:0</b> – parameter configured successfully. Received information what value has been set to specific parameter.
==One Minute Rule==
The '''One Minute Rule''' is for situations when a driver is on a rest period but needs to move the vehicle briefly, for example, to clear a passage for another vehicle. Under normal circumstances, starting to move the vehicle would '''reset the rest period''', potentially affecting the driver’s working time calculation. The One Minute  Rule allows such short actions '''without interrupting the rest period''', under certain conditions.
<b>How it works:</b>
*The tachograph analyzes the '''entire minute''' and determines which activity occupied the longest duration.
*If the driver moves the vehicle for '''less than 30 seconds within a minute''', the device considers the '''dominant activity''' as rest, not driving.
*As a result, the full minute is counted as part of the '''rest period''', and the driver does not need to restart the break.
<b>Benefits:</b>
*Ensures a realistic recording of the driver’s working and rest times.
*Allows brief vehicle maneuvers during a rest period without formally interrupting it.
*Simplifies activity reporting and prevents unintended violations of driving time regulations.
==Tachograph Functional Rules==
===Rule 038 – One Minute Rule===
Rule 038 defines how tachographs record the driver’s activity in '''1-minute intervals'''. Instead of storing activity changes second-by-second, the tachograph processes all activity signals within the current minute and determines which activity was dominant.
<b>Logic:</b>
#The tachograph counts the number of seconds spent in each activity within the minute:
#*Driving
#*Other Work
#*Availability
#*Rest/Break
#At the end of the minute, the device selects the activity with the longest duration.
#The entire minute is recorded as that dominant activity.
<b>Example:</b>
*22 seconds of driving
*38 seconds of rest
The stored minute will be recorded as '''Rest'''.
This mechanism allows short movements during breaks without resetting the rest period.
===Rule 040 – Priority of Driver Activities===
Rule 040 defines the priority hierarchy of activities when multiple activity inputs or triggers occur at the same time.
It determines which activity should be applied immediately when conflicting signals are detected.
Activity Priority (highest to lowest):
*Driving
*Other Work
*Availability
*Rest/Break
What this means:
*If the tachograph detects vehicle movement, it must switch to Driving, regardless of what the driver selected manually.
*Manual selections can be overridden by activities with a higher priority level.
*This ensures consistent and legally compliant detection of driving activity.
'''Example:'''
The driver sets '''Rest''' manually.
If the vehicle moves for a few seconds, the tachograph will then switch to '''Driving''' (highest priority).
===Rule 041 – Handling Activity Changes Within the Minute===
Rule 041 describes how tachographs monitor, count and buffer all activity transitions occurring within the current minute.
It provides the detailed second-level data needed by Rule 038 to decide the dominant activity.
'''Logic:'''<br>
#The tachograph keeps an internal second-based counter of each activity during the minute.
#It records all transitions, even if they last only a few seconds (e.g., short manoeuvres).
#At the end of the minute, these counters are passed to Rule 038 for dominant-activity evaluation.
'''Example:'''<br>
Within one minute:
*5 s driving
*7 s rest
*3 s driving
*45 s rest
Internal counters (Rule 041) determines:
*Driving = 8 s
*Rest = 52 s
Rule 038 records the minute as '''Rest'''.
===Rule 042 – Special Activity Handling===
Rule 042 defines additional logic for handling special or exceptional driver activities within the tachograph system.
<b>Purpose:</b>
*Handle specific activity scenarios requiring immediate or exceptional processing.
*Override or modify activity states in special cases, such as emergency maneuvers or system-triggered events.
*Ensure accurate reporting in situations not fully covered by standard activity rules.
<b>Logic:</b>
# The tachograph monitors the current driver state and system inputs.
# If a special condition occurs, Rule 042 may:
::*Override the dominant activity determined by other rules.
::*Force a predefined activity to be recorded for the minute or sub-minute interval.
<b>Example:</b>
*The driver is on a rest period, but an emergency maneuver is detected.
*Rule 042 may temporarily record the activity as “Driving” for safety or legal compliance, even if Rule 038 would normally store “Rest” for that minute.
<b>Benefits:</b>
*Ensures critical or exceptional activities are accurately recorded.
*Enhances compliance with regulatory requirements in non-standard situations.
*Provides flexibility for system designers to handle edge cases without impacting the normal minute-by-minute recording logic.
===Summary===
<table class="nd-othertables_2" style="width:100%; border-collapse: collapse;">
<table class="nd-othertables_2" style="width:100%; border-collapse: collapse;">
<tr>
<th style="width:1%; vertical-align: middle; text-align: center;">Rule</th>
<th style="width:1%; vertical-align: middle; text-align: center;">Purpose</th>
</tr>
<tr>
<td style="vertical-align: middle; text-align: center;">038</td>
<td style="vertical-align: middle; text-align: center;"> Selects the dominant activity for the whole minute</td>
</tr>
<tr>
<td style="vertical-align: middle; text-align: center;">040</td>
<td style="vertical-align: middle; text-align: center;">Defines activity priority when signals conflict (Driving > Work > Availability > Rest)</td>
</tr>
<tr>
<td style="vertical-align: middle; text-align: center;">041</td>
<td style="vertical-align: middle; text-align: center;">Counts second-level activity changes inside the minute to support Rule 038</td>
</tr>
<tr>
<tr>
<th style="width:20%; vertical-align: middle; text-align: center;"> '''FIRMWARE VERSION''' </th>
<td style="vertical-align: middle; text-align: center;">042</td>
<th style="width:20%; vertical-align: middle; text-align: center;"> '''RELEASE DATE''' </th>
<td style="vertical-align: middle; text-align: center;">Handles special or exceptional driver activities, overriding normal rules when necessary.  </td>
<th style="width:60%; vertical-align: middle; text-align: center;"> '''CHANGES''' </th>
<tr style="text-align: center; vertical-align: middle;">
<td style="vertical-align: middle">''' 03.01.01.rev.15'''</td>
<td style="vertical-align: middle">2026.03.23</td>
<td style="text-align: left; vertical-align: top">
'''General Stability / Functionality'''
*Improved internal device watchdog mechanisms to ensure more stable long-term operation. 
*Fixed inconsistent generation of periodic records so they are now created according  to configuration. 
*Fixed the record counter IO so that it increments correctly when new records are created and does not reset unexpectedly in specific configurations.
*Fixed unnecessary daily activation of a specific event IO. The IO now triggers only on real events instead of once per day. 
*Improved GNSS calculation algorithms for more stable, precise and faster coordinate updates. 
*Fixed issues where idling events were not recorded even when idling detection was configured. 
*Improved movement detection algorithms for more precise event recording. 
*Fixed duplicate or missing “Trip End” status records. 
*Fixed DOUT1 behaviour in Geofence scenarios where a non-zero speed was required even when configuration did not require it. 
*Fixed unnecessary immobilizer status change records. 
*Fixed an issue where the immobilizer scenario could be bypassed under certain conditions and where immobilizer events were generated without values. 
*Fixed incorrect behaviour where the immobilizer scenario was not enforced when no authorization list was configured. 
*Improved logic for DOUT control in immobilizer scenarios so DOUT states are handled consistently, including across sleep/wake transitions. 
*Fixed mismatches between the device-calculated odometer and tachograph  odometer. 
*Fixed issues where fuel data from certain liquid level sensors could be lost, causing incomplete fuel history. 
*Improved total distance and trip distance counting for more accurate mileage  tracking. 
*Included multiple minor internal stability and bug-fix improvements that collectively improve overall system robustness, logging, and performance. 
*Fixed an issue where the device did not enter Deep Sleep mode properly.
'''Connectivity & Server Communication'''
*Fixed an issue where the device did not establish a data connection if the APN field was left blank. 
*Improved modem and network handling, including better operator selection and reconnection behaviour, reducing unexpected data link issues. 
*Fixed behaviour where the device continuously contacted the NTP server when GNSS fix was unavailable. 
*Fixed an issue where incorrect NTP responses could lead to timestamps being set in the future. 
*Fixed a problem where the device could receive future timestamps when NITZ was used as the time synchronisation source. 
*Fixed an issue where the device did not send records to the configured duplicate server correctly. 
*Fixed failures to send records to the duplicate server in some TCP/UDP scenarios. 
*Fixed an issue where records were bundled into a single packet rather than being sent individually as expected. 
*Fixed delays in record transmission over UDP. 
*Fixed issues where the device could disconnect from the server after executing certain GPRS or configuration commands. 
*Fixed internal log download issues via over-the-air tools. 
*Fixed a situation where over-the-air firmware update tasks could remain stuck in “Pending” or “Executing” state. 
*Fixed occasional failures of firmware updates performed via the configuration tool, reducing the chance of interrupted or failed local updates. 
*Fixed an issue where the device was not generating Iridium SBD records. 
*Improved RS232 data sending to the Iridium module to ensure that SBD payloads are delivered reliably and without truncation.
'''Bluetooth / BLE'''
*Fixed cases where the device generated unnecessary beacon records in stop mode. 
*Fixed issues where advanced beacon packet length information was not generated correctly in advanced beacon mode.
*Fixed incorrect reading of custom BLE parameter values when the data size was less than three bytes.
'''MQTT'''
* Fixed incorrect packing of MQTT packets containing multiple JSON objects when sending to cloud platforms. 
* Fixed an issue where the device did not send data via MQTT to custom cloud endpoints in some configurations. 
* Fixed behaviour where long RS232 messages were not sent correctly via MQTT, which could cause truncation or loss when transmitted as JSON. 
* Improved long-term stability of MQTT JSON operation, increasing reliability for continuous cloud integrations and complex payloads. 
'''Tachograph, K-Line & Driver/Company Data'''
* Implemented separate internal instance IDs for tachograph IO elements and DDD file  downloading to avoid interference between live data and file download. 
* Fixed a problem where tachograph auto address selection did not work correctly. 
* Fixed an issue where the working tachograph address could change unexpectedly after firmware updates, causing DDD download failures. 
* Fixed errors where remote tachograph file download sessions could be interrupted or not start at all in certain conditions. 
* Fixed behaviour where the tachograph company card number continued to be reported even after the card was removed. 
* Fixed an issue where the tachograph Driver Name field was missing or incomplete in driver information data. 
* Improved character encoding for tachograph Driver Name, including extended and Nordic letters. 
* Fixed an issue where no data was received over K-Line, preventing tachograph and diagnostic data reception. 
* Improved K-Line detection and privacy mode handling, including explicit privacy status reporting where applicable. 
* Enhanced tachograph-related logging and error handling to make diagnostics clearer.
* Fixed transmission of vehicle and driver identification values (such as VIN, VRN and driver identification) so that accurate identification data is always sent.
'''FMS / Manual CAN / CAN / Eco Driving & Vehicle Data'''
* Fixed missing or incorrect reading of specific FMS parameters, including version-specific parameter sets. 
* Fixed fluctuating fuel levels when using FMS or CAN sources, improving fuel accuracy for both standard and EV FMS use cases. 
* Fixed issues where FMS-based speed was not being used correctly as the selected speed source. 
* Improved overall CAN stability so that tachograph CAN and FMS information is not lost due to CAN bus overflow. 
* Fixed incomplete or malformed responses to commands that start or stop Manual CAN (MCAN) transmissions, ensuring clear responses and reliable remote control. 
* Ensured that Manual CAN requests and commands are no longer executed when ignition is OFF. 
'''New Features'''
* NEW! Added support for storing and sending records from RAM memory. recommended for rapid data sending i.e. data saving every second etc. ([[FMC650 System settings#Records Saving/Sending Without TS|FMC650 System settings]])
* NEW! Implemented a new feature called the “one minute rule” for tachograph driving state, reducing unnecessary state toggling and improving driving/rest detection accuracy.([[Driver Working State Filters|FMC650 Driver Working State Filters]])
* NEW! Apache Thermograph ([[FMC650 Thermograph#Apache|FMC650 Thermograph]]) 
* NEW! Trailer CAN functionality. ([[FMC650 TrailerCAN]]) 
* NEW! Implemented “scanevfms“ command for diagnosing electric trucks, providing targeted EV CAN diagnostics. ([[FMB scanevfms]]) 
* NEW! Implemented “can_info“ command that returns details of the CAN bus (baud rates, modes and other key parameters), aiding diagnostics. ([[FMB can_info]]) 
* NEW! Updated the “tachocheck“command to show more detailed information. ([[FMB tachocheck]])
'''Configuration, Parameters & Tools'''
* Fixed an issue where a single setparam command could not change multiple parameters at once. 
* Fixed behaviour where the odometer command always returned a GNSS-based odometer value regardless of the configured odometer source. 
* Fixed cases where the device disconnected unnecessarily from the configurator.   
* Fixed an issue where the SIM PIN was not remembered after soft or hard reset.
</td>
</tr>
</tr>

Revision as of 14:01, 25 March 2026

Driver Working State Filters

Configuration

N/A driver state – If parameter is disabled, the device will not save data about current minute, if driver information are not available. System bypassed to report incorrect or incomplete data.
(Parameter ID: 253)

Deny driver working state when ignition off – If parameter is disabled, device will reject driver information when vehicle ignition is turned off.
(Parameter ID: 254)

OneMinute Rule - if parameter is disabled, device will continue analyzing driver data but results will not be saved and records with data will not be generated (enables or disables rule 038).
(Parameter ID: 252)

SMS/GPRS Commands

  • tacho_dbg:x, where x = 0,1
This command allows to enable or disable basic debug information.
Response for the command: Set tacho data monitor dbg:0
  • getparam x, where x = configurator parameter (252,253,254)
This command allows to check the value of configured parameters.
Response for the command: Param ID:252 Value:1
  • setparam x:y, where x = configurator parameter (252,253,254), y = value to write
Command allows to set value to Configurator parameter. Available value 0,1.
Response for that command:
Config same for 252: 1 – information that parameter was configured before with the same value.
Failed to update parameters – there was an error during setting parameter. Value of the range.
New value 252:0 – parameter configured successfully. Received information what value has been set to specific parameter.

One Minute Rule

The One Minute Rule is for situations when a driver is on a rest period but needs to move the vehicle briefly, for example, to clear a passage for another vehicle. Under normal circumstances, starting to move the vehicle would reset the rest period, potentially affecting the driver’s working time calculation. The One Minute Rule allows such short actions without interrupting the rest period, under certain conditions.

How it works:

  • The tachograph analyzes the entire minute and determines which activity occupied the longest duration.
  • If the driver moves the vehicle for less than 30 seconds within a minute, the device considers the dominant activity as rest, not driving.
  • As a result, the full minute is counted as part of the rest period, and the driver does not need to restart the break.

Benefits:

  • Ensures a realistic recording of the driver’s working and rest times.
  • Allows brief vehicle maneuvers during a rest period without formally interrupting it.
  • Simplifies activity reporting and prevents unintended violations of driving time regulations.

Tachograph Functional Rules

Rule 038 – One Minute Rule

Rule 038 defines how tachographs record the driver’s activity in 1-minute intervals. Instead of storing activity changes second-by-second, the tachograph processes all activity signals within the current minute and determines which activity was dominant.

Logic:

  1. The tachograph counts the number of seconds spent in each activity within the minute:
    • Driving
    • Other Work
    • Availability
    • Rest/Break
  2. At the end of the minute, the device selects the activity with the longest duration.
  3. The entire minute is recorded as that dominant activity.

Example:

  • 22 seconds of driving
  • 38 seconds of rest

The stored minute will be recorded as Rest.

This mechanism allows short movements during breaks without resetting the rest period.

Rule 040 – Priority of Driver Activities

Rule 040 defines the priority hierarchy of activities when multiple activity inputs or triggers occur at the same time. It determines which activity should be applied immediately when conflicting signals are detected. Activity Priority (highest to lowest):

  • Driving
  • Other Work
  • Availability
  • Rest/Break

What this means:

  • If the tachograph detects vehicle movement, it must switch to Driving, regardless of what the driver selected manually.
  • Manual selections can be overridden by activities with a higher priority level.
  • This ensures consistent and legally compliant detection of driving activity.

Example: The driver sets Rest manually. If the vehicle moves for a few seconds, the tachograph will then switch to Driving (highest priority).

Rule 041 – Handling Activity Changes Within the Minute

Rule 041 describes how tachographs monitor, count and buffer all activity transitions occurring within the current minute. It provides the detailed second-level data needed by Rule 038 to decide the dominant activity.

Logic:

  1. The tachograph keeps an internal second-based counter of each activity during the minute.
  2. It records all transitions, even if they last only a few seconds (e.g., short manoeuvres).
  3. At the end of the minute, these counters are passed to Rule 038 for dominant-activity evaluation.

Example:
Within one minute:

  • 5 s driving
  • 7 s rest
  • 3 s driving
  • 45 s rest

Internal counters (Rule 041) determines:

  • Driving = 8 s
  • Rest = 52 s

Rule 038 records the minute as Rest.

Rule 042 – Special Activity Handling

Rule 042 defines additional logic for handling special or exceptional driver activities within the tachograph system.

Purpose:

  • Handle specific activity scenarios requiring immediate or exceptional processing.
  • Override or modify activity states in special cases, such as emergency maneuvers or system-triggered events.
  • Ensure accurate reporting in situations not fully covered by standard activity rules.

Logic:

  1. The tachograph monitors the current driver state and system inputs.
  2. If a special condition occurs, Rule 042 may:
  • Override the dominant activity determined by other rules.
  • Force a predefined activity to be recorded for the minute or sub-minute interval.

Example:

  • The driver is on a rest period, but an emergency maneuver is detected.
  • Rule 042 may temporarily record the activity as “Driving” for safety or legal compliance, even if Rule 038 would normally store “Rest” for that minute.

Benefits:

  • Ensures critical or exceptional activities are accurately recorded.
  • Enhances compliance with regulatory requirements in non-standard situations.
  • Provides flexibility for system designers to handle edge cases without impacting the normal minute-by-minute recording logic.

Summary

Rule Purpose
038 Selects the dominant activity for the whole minute
040 Defines activity priority when signals conflict (Driving > Work > Availability > Rest)
041 Counts second-level activity changes inside the minute to support Rule 038
042 Handles special or exceptional driver activities, overriding normal rules when necessary.