Jump to content

Test-AC: Difference between revisions

From Teltonika Telematics Wiki
No edit summary
GTPGTM-11785 - Final draft
Line 1: Line 1:
=RTK Coordinate via CAN Integration with FMC650=
===Firmware versions===
==Overview==
Activating '''RTK (Real-Time Kinematic)''' coordinate acquisition enables the FMC650 device to process RTK data from CAN.
When configured, the RTK module can provide high-precision coordinates using: 
*RTK receiver via RS232 
*RTK data via CAN 
*Internal GNSS receiver (GNS) as fallback 
The device automatically chooses the best available source based on configuration and data quality. 
 
The following specifications indicate the minimum firmware and configurator version requirement to use RTK coordinate acquisition via CAN on FMC650.
 
*<b>Platform:</b> FM65 
*<b>Device:</b> FMC650 
*<b>Firmware version:</b> 03.01.03.Rev.227 
*<b>Configurator version:</b> B.FMX6_R.192 
 
==Method of Operation==
When the RTK option is enabled, the device always tries to use RTK sources first and falls back to internal GNSS if needed. 
 
'''Source priority'''
#'''RS232 (primary RTK source)'''
#:*The device checks whether any COM port (COM1 or COM2) is configured in RTK mode. 
#:*If at least one COM port is configured for RTK and valid data is present, coordinates are taken from RS232. 
#'''CAN RTK (secondary RTK source)'''
#:*If RS232 RTK data is not available or is invalid, the device checks the CAN RTK status. 
#:*If valid CAN RTK data is available, coordinates are taken from CAN. 
#:*A timing check is applied if the time difference between received CAN RTK frames is greater than 2 seconds. The device automatically switches to the internal GNSS receiver (GNS) to keep coordinates up to date.
#'''Internal GNSS (GNS) Fallback'''
#:*If neither RS232 nor CAN provide valid RTK data, the device uses the internal GNSS receiver (GNS) for coordinates. 
#'''RTK Disabled'''
#:*If the RTK option is disabled, coordinates are always taken from the internal GNSS receiver.
 
'''RTK data from CAN'''
 
When CAN is used as the RTK source, the device reads: 
*'''Latitude''' 
*'''Longitude''' 
*'''Altitude''' 
*'''Ground speed''' 
*'''Course'''
 
These values are taken from standard CAN messages designed for GNSS/RTK data. Exact PGNs and signal layouts depend on whether external RTK/ECD/ISOBUS system is being used.
 
==Configurator Setup== 
This section describes how to enable RTK as a location source and configure RS232 and CAN usage through the Configurator.
 
'''Enabling RTK as a location source'''
[[File:Source Location from RTK.png|right]]
#Open the Configurator and connect to the FMC650 device.
#Navigate to the System tab. 
#Find the option “Source Location from RTK” in the '''System Settings''' section.
#Set this option to '''Enable'''.
 
When enabled, the device will use RTK data from RS232/CAN if available, with automatic fallback to internal GNSS.
 
For advanced configuration (e.g. via commands):
 
Source Location from RTK <br>
'''Parameter ID:''' 55000 <br>
'''Values:''' 
*'''0''' – Disabled (device uses only internal GNSS) 
*'''1''' – Enabled (device uses RTK sources if available)
 
Configuring RS232 for RTK Use 
If you plan to use an external RTK receiver via RS232: 
#Open the RS232/RS485 tab in the Configurator. 
#For COM1 or COM2 (or both), set the mode to RTK.
 
Relevant parameter IDs: 
*'''COM1 mode''' – Parameter ID 151 
*'''COM2 mode''' – Parameter ID 173 
*'''RTK mode''' – Value 60 
If at least one COM port is configured to RTK mode and valid RTK data is received, the device will use RS232 as the main coordinate source. 
 
[[File:RS232 settings - RTK.png|right]]
 
'''Using CAN as the RTK Source'''
CAN-based RTK is used in the following cases: 
*None of the RS232 COM ports are configured in RTK mode, or 
*RS232 RTK data is not valid or not present. 
When those conditions are met and valid CAN RTK data is received: 
*The device uses CAN as the coordinate source. 
*The device continuously monitors the time between RTK messages. 
*If CAN RTK messages are delayed by more than 2 seconds, the device automatically reverts to internal GNSS to avoid stale coordinates.
<br>
RTK data taken from CAN includes: 
*'''Latitude 
*'''Longitude 
*'''Altitude 
*'''Ground speed 
*'''Course 
 
Configuration of RTK over CAN (e.g. PGN, source address, bitrate) depends on your external CAN/ISOBUS/RTK infrastructure and should follow that system’sdocumentation. 
 
'''ISOBUS Data Visibility''' 
When used in ISOBUS or similar environments: 
[[File:ISOBUS - RTK.png]]
*RTK-related data from CAN is visible in the ISOBUS section of the Configurator. 
 
*This allows you to verify that RTK data is being received and interpreted correctly by the device. 
 
==Active Location Source Monitoring==
To understand which source is currently being used for position data, you can check the '''Location Source''' parameter. 
 
'''Location Source Values'''
 
In the Configurator: 
#Navigate to the '''I/O''' tab (or equivalent I/O monitoring view).
#Find the parameter '''Location Source'''.
[[File:Location source.png]]
 
Possible values:
 
*'''0 – GNS'''
Location is taken from the internal GNSS receiver. This is the default when RTK is disabled or when no valid RTK data is available.
 
*'''1 – RS232'''
Location is taken from the RTK receiver connected via RS232.
 
*'''2 – CAN'''
Location is taken from RTK data arriving over CAN.
 
*'''3 – Err'''
Location is taken from the internal GNSS receiver, but this status indicates that RTK data from RS232 and/or CAN is invalid or unavailable. This helps distinguish normal GNSS use from “RTK expected but not available” situations.
 
This parameter is used for diagnostics and for confirming that your device is using the intended RTK source.
 
==NMEA Fix Type Monitoring (RS232 RTK Only)==
When RTK coordinates are received via RS232, you can also monitor the NMEA Fix Type to understand the quality of the GNSS/RTK fix. 
 
'''Configurator Steps'''
#Open the Configurator. 
#Go to the I/O tab (or relevant section). 
#Locate the parameter '''NMEA Fix Type'''.
 
[[File:NMEA Fix Type.png]]
 
'''Note:''' This parameter is '''only available when coordinate data is received via RS232 RTK'''. 
 
'''NMEA Fix Type Values'''
 
*'''NotValid''' - No valid GNSS fix is available.<br>
 
*'''GPS''' - Standard GPS fix using satellites only.<br>
 
*'''DGNSS''' - Differential GNSS fix (e.g. DGNSS, SBAS, etc.).<br>
 
*'''NotApplicable''' - Fix quality is not applicable in the current context. <br>
 
*'''RTK_Fixed''' - RTK Fixed; high-precision RTK fix (including xFill if supported by the receiver).<br>
 
*'''RTK_Float''' - RTK Float; typically, a converging RTK solution or similar intermediate status.<br>
 
*'''INS_DR''' - INS Dead Reckoning; position estimated by inertial sensors and previous GNSS/RTK data.<br> 
 
This information is beneficial for:
*Verifying that the external RTK receiver is working correctly.
*Assessing overall RTK performance and stability.
*Logging and diagnostics in advanced deployments.
 
==Parameter IDs and AVL IDs==
 
Below is a list of AVL IDs and Configurator IDs assigned to a specific item.
 
<table class="nd-othertables_2" style="width:50%; border-collapse: collapse;">
 
<tr>
<th style="width:8%; vertical-align: middle; text-align: left;">Name</th>
<th style="width:15%; vertical-align: middle; text-align: center;">Parameter ID</th>
<th style="width:5%; vertical-align: middle; text-align: center;">AVL ID</th>
</tr>
 
<tr>
<td style="vertical-align: middle; text-align: center;">RTK Longitude</td>
<td style="vertical-align: middle; text-align: center;">151790</td>
<td style="vertical-align: middle; text-align: center;">14145</td>
</tr>
 
<tr>
<td style="vertical-align: middle; text-align: center;">RTK Latitude</td>
<td style="vertical-align: middle; text-align: center;">151800</td>
<td style="vertical-align: middle; text-align: center;">14146</td>
</tr>
 
<tr>
<td style="vertical-align: middle; text-align: center;">RTK Altitude</td>
<td style="vertical-align: middle; text-align: center;">151810</td>
<td style="vertical-align: middle; text-align: center;">14147</td>
</tr>
 
<tr>
<td style="vertical-align: middle; text-align: center;">RTK Speed</td>
<td style="vertical-align: middle; text-align: center;">151820</td>
<td style="vertical-align: middle; text-align: center;">14148</td>
</tr>
 
<tr>
<td style="vertical-align: middle; text-align: center;">RTK Angle</td>
<td style="vertical-align: middle; text-align: center;">151830</td>
<td style="vertical-align: middle; text-align: center;">14149</td>
</tr>
 
<tr>
<td style="vertical-align: middle; text-align: center;">Source Location from RTK</td>
<td style="vertical-align: middle; text-align: center;">55000</td>
<td style="vertical-align: middle; text-align: center;">-</td>
</tr>
 
<tr>
<td style="vertical-align: middle; text-align: center;">Source Location from RTK</td>
<td style="vertical-align: middle; text-align: center;">55000</td>
<td style="vertical-align: middle; text-align: center;">-</td>
</tr>
 
<tr>
<td style="vertical-align: middle; text-align: center;">Location Source</td>
<td style="vertical-align: middle; text-align: center;">53050</td>
<td style="vertical-align: middle; text-align: center;">10919</td>
</tr>


<table class="nd-othertables_2" style="width:100%; border-collapse: collapse;">
<tr>
<tr>
<td style="vertical-align: middle; text-align: center;">NMEA Fix Type</td>
<th style="width:20%; vertical-align: middle; text-align: center;"> '''FIRMWARE VERSION''' </th>
<td style="vertical-align: middle; text-align: center;">53060</td>
<th style="width:20%; vertical-align: middle; text-align: center;"> '''RELEASE DATE''' </th>
<td style="vertical-align: middle; text-align: center;">10920</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 12:54, 25 March 2026

Firmware versions

FIRMWARE VERSION RELEASE DATE CHANGES
03.01.01.rev.15 2026.03.23

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)
  • 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 Driver Working State Filters)
  • NEW! Apache Thermograph (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.