Test-AC: Difference between revisions

← Older edit

VisualWikitext

@@ Line 1: / Line 1: @@
-=Driver Working State Filters=
+===Firmware versions===
-==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>
+<table class="nd-othertables_2" style="width:100%; border-collapse: collapse;">
-(''Parameter ID: 254'')
+<tr>
+<th style="width:20%; vertical-align: middle; text-align: center;"> '''FIRMWARE VERSION''' </th>
-'''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>
+<th style="width:20%; vertical-align: middle; text-align: center;"> '''RELEASE DATE''' </th>
-(''Parameter ID: 252'')
+<th style="width:60%; vertical-align: middle; text-align: center;"> '''CHANGES''' </th>
+<tr style="text-align: center; vertical-align: middle;">
-==SMS/GPRS Commands==
+<td style="vertical-align: middle">''' 03.01.01.rev.15'''</td>
-*<b>tacho_dbg:x</b>, where x = 0,1
+<td style="vertical-align: middle">2026.03.23</td>
-:This command allows to enable or disable basic debug information.
+<td style="text-align: left; vertical-align: top">
-:Response for the command: <b>Set tacho data monitor dbg:0</b>
+'''General Stability / Functionality'''
-*<b>getparam x</b>, where x = configurator parameter (252,253,254)
+*Improved internal device watchdog mechanisms to ensure more stable long-term operation.
-:This command allows to check the value of configured parameters.
+*Fixed inconsistent generation of periodic records so they are now created according   to configuration.
-:Response for the command: <b>Param ID:252 Value:1</b>
+*Fixed the record counter IO so that it increments correctly when new records are created and does not reset unexpectedly in specific configurations.
-*<b>setparam x:y</b>, where x = configurator parameter (252,253,254), y = value to write
+*Fixed unnecessary daily activation of a specific event IO. The IO now triggers only on real events instead of once per day.
-:Command allows to set value to Configurator parameter. Available value 0,1.
+*Improved GNSS calculation algorithms for more stable, precise and faster coordinate updates.
-:Response for that command:
+*Fixed issues where idling events were not recorded even when idling detection was configured.
-:<b>Config same for 252: 1</b> – information that parameter was configured before with the same value.
+*Improved movement detection algorithms for more precise event recording.
-:<b>Failed to update parameters</b> – there was an error during setting parameter. Value of the range.
+*Fixed duplicate or missing “Trip End” status records.
-:<b>New value 252:0</b> – parameter configured successfully. Received information what value has been set to specific parameter.
+*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.
-==OneMinute Rule==
+*Fixed an issue where the immobilizer scenario could be bypassed under certain conditions and where immobilizer events were generated without values.
-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.
+*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.
-<b>How it works:</b>
+*Fixed mismatches between the device-calculated odometer and tachograph   odometer.
-*The tachograph analyzes the '''entire minute''' and determines which activity occupied the longest duration.
+*Fixed issues where fuel data from certain liquid level sensors could be lost, causing incomplete fuel history.
-*If the driver moves the vehicle for '''less than 30 seconds within a minute''', the device considers the '''dominant activity''' as rest, not driving.
+*Improved total distance and trip distance counting for more accurate mileage   tracking.
-*As a result, the full minute is counted as part of the '''rest period''', and the driver does not need to restart the break.
+*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.
-<b>Benefits:</b>
+'''Connectivity & Server Communication'''
-*Ensures a realistic recording of the driver’s working and rest times.
+*Fixed an issue where the device did not establish a data connection if the APN field was left blank.
-*Allows brief vehicle maneuvers during a rest period without formally interrupting it.
+*Improved modem and network handling, including better operator selection and reconnection behaviour, reducing unexpected data link issues.
-*Simplifies activity reporting and prevents unintended violations of driving time regulations.
+*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.
-==Tachograph Functional Rules==
+*Fixed a problem where the device could receive future timestamps when NITZ was used as the time synchronisation source.
-===Rule 038 – One Minute Rule===
+*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.
-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.
+*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.
-<b>Logic:</b>
+*Fixed issues where the device could disconnect from the server after executing certain GPRS or configuration commands.
-#The tachograph counts the number of seconds spent in each activity within the minute:
+*Fixed internal log download issues via over-the-air tools.
-#*Driving
+*Fixed a situation where over-the-air firmware update tasks could remain stuck in “Pending” or “Executing” state.
-#*Other Work
+*Fixed occasional failures of firmware updates performed via the configuration tool, reducing the chance of interrupted or failed local updates.
-#*Availability
+*Fixed an issue where the device was not generating Iridium SBD records.
-#*Rest/Break
+*Improved RS232 data sending to the Iridium module to ensure that SBD payloads are delivered reliably and without truncation.
-#At the end of the minute, the device selects the activity with the longest duration.
+'''Bluetooth / BLE'''
-#The entire minute is recorded as that dominant activity.
+*Fixed cases where the device generated unnecessary beacon records in stop mode.
-<b>Example:</b>
+*Fixed issues where advanced beacon packet length information was not generated correctly in advanced beacon mode.
-*22 seconds of driving
+*Fixed incorrect reading of custom BLE parameter values when the data size was less than three bytes.
-*38 seconds of rest
+'''MQTT'''
+* Fixed incorrect packing of MQTT packets containing multiple JSON objects when sending to cloud platforms.
-The stored minute will be recorded as '''Rest'''.
+* 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.
-This mechanism allows short movements during breaks without resetting the rest period.
+* Improved long-term stability of MQTT JSON operation, increasing reliability for continuous cloud integrations and complex payloads.
+'''Tachograph, K-Line & Driver/Company Data'''
-===Rule 040 – Priority of Driver Activities===
+* Implemented separate internal instance IDs for tachograph IO elements and DDD file  downloading to avoid interference between live data and file download.
-Rule 040 defines the priority hierarchy of activities when multiple activity inputs or triggers occur at the same time.
+* Fixed a problem where tachograph auto address selection did not work correctly.
-It determines which activity should be applied immediately when conflicting signals are detected.
+* Fixed an issue where the working tachograph address could change unexpectedly after firmware updates, causing DDD download failures.
-Activity Priority (highest to lowest):
+* Fixed errors where remote tachograph file download sessions could be interrupted or not start at all in certain conditions.
-*Driving
+* Fixed behaviour where the tachograph company card number continued to be reported even after the card was removed.
-*Other Work
+* Fixed an issue where the tachograph Driver Name field was missing or incomplete in driver information data.
-*Availability
+* Improved character encoding for tachograph Driver Name, including extended and Nordic letters.
-*Rest/Break
+* Fixed an issue where no data was received over K-Line, preventing tachograph and diagnostic data reception.
-What this means:
+* Improved K-Line detection and privacy mode handling, including explicit privacy status reporting where applicable.
-*If the tachograph detects vehicle movement, it must switch to Driving, regardless of what the driver selected manually.
+* Enhanced tachograph-related logging and error handling to make diagnostics clearer.
-*Manual selections can be overridden by activities with a higher priority level.
+* Fixed transmission of vehicle and driver identification values (such as VIN, VRN and driver identification) so that accurate identification data is always sent.
-*This ensures consistent and legally compliant detection of driving activity.
+'''FMS / Manual CAN / CAN / Eco Driving & Vehicle Data'''
-'''Example:'''
+* 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.
-The driver sets '''Rest''' manually.
+* Fixed issues where FMS-based speed was not being used correctly as the selected speed source.
-If the vehicle moves for a few seconds, the tachograph will then switch to '''Driving''' (highest priority).
+* 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.
-===Rule 041 – Handling Activity Changes Within the Minute===
+* Ensured that Manual CAN requests and commands are no longer executed when ignition is OFF.
-Rule 041 describes how tachographs monitor, count and buffer all activity transitions occurring within the current minute.
+'''New Features'''
-It provides the detailed second-level data needed by Rule 038 to decide the dominant activity.
+* NEW! Added support for storing and sending records from [[FMC650 System settings#Records Saving/Sending Without TS|RAM memory]]. recommended for rapid data sending i.e. data saving every second etc.
+* NEW! Implemented a new feature called the “[[FMC650 LVCAN I/O,FMS IO and Tachograph data elements#Driver Working State Filters|one minute rule]]” for tachograph driving state, reducing unnecessary state toggling and improving driving/rest detection accuracy.
-'''Logic:'''
+* NEW! [[FMC650 Thermograph#Apach|Apache Thermograph]].
-#The tachograph keeps an internal second-based counter of each activity during the minute.
+* NEW! [[FMC650 TrailerCAN|Trailer CAN]] functionality.
-#It records all transitions, even if they last only a few seconds (e.g., short manoeuvres).
+* NEW! Implemented [[FMB scanevfms|“scanevfms“]] command for diagnosing electric trucks, providing targeted EV CAN diagnostics.
-#At the end of the minute, these counters are passed to Rule 038 for dominant-activity evaluation.
+* NEW! Implemented “[[FMB can＿info|can_info]]“ command that returns details of the CAN bus (baud rates, modes and other key parameters), aiding diagnostics.
-'''Example:'''
+* NEW! Updated the “[[FMB tachocheck|tachocheck“]] command to show more detailed information.
+'''Configuration, Parameters & Tools'''
-Within one minute:
+* Fixed an issue where a single setparam command could not change multiple parameters at once.
-*5 s driving
+* Fixed behaviour where the odometer command always returned a GNSS-based odometer value regardless of the configured odometer source.
-*7 s rest
+* Fixed cases where the device disconnected unnecessarily from the configurator.
-*3 s driving
+* Fixed an issue where the SIM PIN was not remembered after soft or hard reset.
-*45 s rest
+</td>
-Internal counters (Rule 041) determines:
+</tr>
-*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.

Latest revision as of 10:40, 26 March 2026