Jump to content

Test-AC: Difference between revisions

From Teltonika Telematics Wiki
No edit summary
DM1/DM2 Draft
Line 1: Line 1:
===Firmware versions===
==DM1 Lamp Status and Flash Signals==


<table class="nd-othertables_2" style="width:100%; border-collapse: collapse;">
The '''DM1 (Diagnostic Message 1)''' in the '''J1939''' protocol reports active '''Diagnostic Trouble Codes (DTCs)''' and controls vehicle warning indicators. It defines the behavior of the '''Malfunction Indicator Lamp (MIL)''' and other warning lamps, which can be off, on solid, or flashing, depending on the severity and priority of detected faults. Flashing typically signals a more urgent or severe condition, while a solid light indicates an active but less critical issue.
<tr>
 
<th style="width:20%; vertical-align: middle; text-align: center;"> '''FIRMWARE VERSION''' </th>
*'''PL (Protect Lamp)''' - DTC's indicate non-electronic subsystem issue.
<th style="width:20%; vertical-align: middle; text-align: center;"> '''RELEASE DATE''' </th>
*'''AWL(Amber Warning Light)''' - DTC's indicate a non-critical issue that does not warrant stopping the vehicle.
<th style="width:60%; vertical-align: middle; text-align: center;"> '''CHANGES''' </th>
 
<tr style="text-align: center; vertical-align: middle;">
*'''RSL(Red Stop Lamp)''' - DTC's indicate a critical issue that warrants stopping the vehicle immediately.  
<td style="vertical-align: middle">''' 03.01.01.rev.15'''</td>
 
<td style="vertical-align: middle">2026.03.23</td>
*'''MIL(Malfunction Indicator Lamp)''' - At least one DTC indicates emissions related issue.
<td style="text-align: left; vertical-align: top">
 
'''General Stability / Functionality'''
DM1 encodes warning lamp information in its first 2 bytes, combining both lamp status and flash behavior. Each lamp is represented by two 2-bit fields—one in byte 1 (status) and one in byte 2 (flash).  
*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. 
<b>Status Values:</b>
*Fixed the record counter IO so that it increments correctly when new records are created and does not reset unexpectedly in specific configurations.
*'''0''' = OFF
*Fixed unnecessary daily activation of a specific event IO. The IO now triggers only on real events instead of once per day. 
*'''1''' = ON
*Improved GNSS calculation algorithms for more stable, precise and faster coordinate updates.
*'''2''' = Reserved
*Fixed issues where idling events were not recorded even when idling detection was configured. 
*'''3''' = Not Available
*Improved movement detection algorithms for more precise event recording. 
 
*Fixed duplicate or missing “Trip End” status records. 
<b>Flash Values:</b>
*Fixed DOUT1 behaviour in Geofence scenarios where a non-zero speed was required even when configuration did not require it. 
*'''0''' = Slow Flash (1 Hz).  
*Fixed unnecessary immobilizer status change records. 
*'''1''' = Fast Flash (2 Hz).  
*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. 
To decode, split each byte into 2-bit segments and map each pair to its corresponding lamp. The final behavior is determined by combining status and flash (e.g., ON + fast flash = rapidly blinking warning).
*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.([[FMC650 LVCAN I/O,FMS IO and Tachograph data elements#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>

Revision as of 10:33, 26 March 2026

DM1 Lamp Status and Flash Signals

The DM1 (Diagnostic Message 1) in the J1939 protocol reports active Diagnostic Trouble Codes (DTCs) and controls vehicle warning indicators. It defines the behavior of the Malfunction Indicator Lamp (MIL) and other warning lamps, which can be off, on solid, or flashing, depending on the severity and priority of detected faults. Flashing typically signals a more urgent or severe condition, while a solid light indicates an active but less critical issue.

  • PL (Protect Lamp) - DTC's indicate non-electronic subsystem issue.
  • AWL(Amber Warning Light) - DTC's indicate a non-critical issue that does not warrant stopping the vehicle.
  • RSL(Red Stop Lamp) - DTC's indicate a critical issue that warrants stopping the vehicle immediately.
  • MIL(Malfunction Indicator Lamp) - At least one DTC indicates emissions related issue.

DM1 encodes warning lamp information in its first 2 bytes, combining both lamp status and flash behavior. Each lamp is represented by two 2-bit fields—one in byte 1 (status) and one in byte 2 (flash).

Status Values:

  • 0 = OFF
  • 1 = ON
  • 2 = Reserved
  • 3 = Not Available

Flash Values:

  • 0 = Slow Flash (1 Hz).
  • 1 = Fast Flash (2 Hz).

To decode, split each byte into 2-bit segments and map each pair to its corresponding lamp. The final behavior is determined by combining status and flash (e.g., ON + fast flash = rapidly blinking warning).