Jump to content

Test-AC: Difference between revisions

From Teltonika Telematics Wiki
No edit summary
No edit summary
(8 intermediate revisions by the same user not shown)
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. 
==How It Works==
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===
#<b>RS232 (primary RTK source)</b>
#:*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. 
#<b>CAN RTK (secondary RTK source)</b> 
#:*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.
#<b>Internal GNSS (GNS) fallback</b> 
#:*If neither RS232 nor CAN provide valid RTK data, the device uses the internal GNSS receiver (GNS) for coordinates. 
#<b>RTK disabled</b>
#:*If the RTK option is disabled, coordinates are always taken from the internal GNSS receiver.


===RTK data from CAN=== 
<table class="nd-othertables_2" style="width:100%; border-collapse: collapse;">
When CAN is used as the RTK source, the device reads:
<tr>
*Latitude 
<th style="width:20%; vertical-align: middle; text-align: center;"> '''FIRMWARE VERSION''' </th>
*Longitude 
<th style="width:20%; vertical-align: middle; text-align: center;"> '''RELEASE DATE''' </th>
*Altitude 
<th style="width:60%; vertical-align: middle; text-align: center;"> '''CHANGES''' </th>
*Ground speed 
<tr style="text-align: center; vertical-align: middle;">
*Course 
<td style="vertical-align: middle">''' 03.01.01.rev.15'''</td>
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. 
<td style="vertical-align: middle">2026.03.23</td>
==General Information==
<td style="text-align: left; vertical-align: top">
*<b>Platform:</b> FM65 
'''General Stability / Functionality'''
*<b>Device:</b> FMC650 
*Improved internal device watchdog mechanisms to ensure more stable long-term operation.   
*<b>Firmware version:</b> 03.01.03.Rev.227 
*Fixed inconsistent generation of periodic records so they are now created according  to configuration.   
*<b>Configurator version:</b> B.FMX6_R.192  
*Fixed the record counter IO so that it increments correctly when new records are created and does not reset unexpectedly in specific configurations.
These versions indicate the minimum firmware and configurator level required to use RTK coordinate acquisition via CAN on FMC650.   
*Fixed unnecessary daily activation of a specific event IO. The IO now triggers only on real events instead of once per day.   
==Configurator Setup== 
*Improved GNSS calculation algorithms for more stable, precise and faster coordinate updates.   
This section describes how to enable RTK as a location source and configure RS232 and CAN usage through the Configurator.  
*Fixed issues where idling events were not recorded even when idling detection was configured.   
4.1 Enabling RTK as a location source
*Improved movement detection algorithms for more precise event recording.   
1. Open the Configurator and connect to the FMC650 device.   
*Fixed duplicate or missing “Trip End” status records.   
2. Navigate to the System tab.   
*Fixed DOUT1 behaviour in Geofence scenarios where a non-zero speed was required even when configuration did not require it.   
3. Find the option “Source Location from RTK”  
*Fixed unnecessary immobilizer status change records.  
4. Set this option to Enable.   
*Fixed an issue where the immobilizer scenario could be bypassed under certain conditions and where immobilizer events were generated without values.  
When enabled, the device will use RTK data from RS232/CAN if available, with 
*Fixed incorrect behaviour where the immobilizer scenario was not enforced when no authorization list was configured.  
automatic fallback to internal GNSS.   
*Improved logic for DOUT control in immobilizer scenarios so DOUT states are handled consistently, including across sleep/wake transitions.  
For advanced configuration (e.g. via commands):  
*Fixed mismatches between the device-calculated odometer and tachograph  odometer.   
• Source Location from RTK  
*Fixed issues where fuel data from certain liquid level sensors could be lost, causing incomplete fuel history.  
o Parameter ID: 55000  
*Improved total distance and trip distance counting for more accurate mileage  tracking.   
o Values:  
*Included multiple minor internal stability and bug-fix improvements that collectively improve overall system robustness, logging, and performance.   
▪ 0 – Disabled (device uses only internal GNSS)  
*Fixed an issue where the device did not enter Deep Sleep mode properly.
▪ 1 – Enabled (device uses RTK sources if available)
'''Connectivity & Server Communication'''
4.2 Configuring RS232 for RTK use  
*Fixed an issue where the device did not establish a data connection if the APN field was left blank.   
If you plan to use an external RTK receiver via RS232:  
*Improved modem and network handling, including better operator selection and reconnection behaviour, reducing unexpected data link issues.   
1. Open the RS232/RS485 tab in the Configurator.   
*Fixed behaviour where the device continuously contacted the NTP server when GNSS fix was unavailable.  
2. For COM1 or COM2 (or both), set the mode to RTK.   
*Fixed an issue where incorrect NTP responses could lead to timestamps being set in the future.   
Relevant parameter IDs: 
*Fixed a problem where the device could receive future timestamps when NITZ was used as the time synchronisation source.   
• COM1 mode – Parameter ID 151 
*Fixed an issue where the device did not send records to the configured duplicate server correctly.   
• COM2 mode – Parameter ID 173 
*Fixed failures to send records to the duplicate server in some TCP/UDP scenarios.   
• Value for RTK mode – 60 
*Fixed an issue where records were bundled into a single packet rather than being sent individually as expected.  
If at least one COM port is configured to RTK mode and valid RTK data is received, the  
*Fixed delays in record transmission over UDP.
device will use RS232 as the main coordinate source.   
*Fixed issues where the device could disconnect from the server after executing certain GPRS or configuration commands.   
4.3 Using CAN as the RTK source  
*Fixed internal log download issues via over-the-air tools.   
CAN-based RTK is used in the following cases:  
*Fixed a situation where over-the-air firmware update tasks could remain stuck in “Pending” or “Executing” state.  
• None of the RS232 COM ports are configured in RTK mode, or 
*Fixed occasional failures of firmware updates performed via the configuration tool, reducing the chance of interrupted or failed local updates.   
• RS232 RTK data is not valid or not present.   
*Fixed an issue where the device was not generating Iridium SBD records.   
When those conditions are met and valid CAN RTK data is received: 
*Improved RS232 data sending to the Iridium module to ensure that SBD payloads are delivered reliably and without truncation.  
• The device uses CAN as the coordinate source.   
'''Bluetooth / BLE'''
• The device continuously monitors the time between RTK messages.   
*Fixed cases where the device generated unnecessary beacon records in stop mode.  
• If CAN RTK messages are delayed by more than 2 seconds, the device 
*Fixed issues where advanced beacon packet length information was not generated correctly in advanced beacon mode.
automatically reverts to internal GNSS to avoid stale coordinates.
*Fixed incorrect reading of custom BLE parameter values when the data size was less than three bytes.
RTK data taken from CAN includes:  
'''MQTT'''
• Latitude  
* Fixed incorrect packing of MQTT packets containing multiple JSON objects when sending to cloud platforms.   
• Longitude 
* Fixed an issue where the device did not send data via MQTT to custom cloud endpoints in some configurations.
• Altitude 
* Fixed behaviour where long RS232 messages were not sent correctly via MQTT, which could cause truncation or loss when transmitted as JSON.   
• Ground speed 
* Improved long-term stability of MQTT JSON operation, increasing reliability for continuous cloud integrations and complex payloads.   
• Course 
'''Tachograph, K-Line & Driver/Company Data'''
Configuration of RTK over CAN (e.g. PGN, source address, bitrate) depends on your 
* Implemented separate internal instance IDs for tachograph IO elements and DDD file  downloading to avoid interference between live data and file download.   
external CAN/ISOBUS/RTK infrastructure and should follow that system’s 
* Fixed a problem where tachograph auto address selection did not work correctly.   
documentation.   
* Fixed an issue where the working tachograph address could change unexpectedly after firmware updates, causing DDD download failures.   
4.4 ISOBUS data visibility  
* Fixed errors where remote tachograph file download sessions could be interrupted or not start at all in certain conditions.   
When used in ISOBUS or similar environments:  
* Fixed behaviour where the tachograph company card number continued to be reported even after the card was removed.   
• RTK-related data from CAN is visible in the ISOBUS section of the Configurator.   
* Fixed an issue where the tachograph Driver Name field was missing or incomplete in driver information data.   
• This allows you to verify that RTK data is being received and interpreted correctly 
* Improved character encoding for tachograph Driver Name, including extended and Nordic letters.   
by the device.   
* Fixed an issue where no data was received over K-Line, preventing tachograph and diagnostic data reception.   
5. Monitoring the Active Location Source 
* Improved K-Line detection and privacy mode handling, including explicit privacy status reporting where applicable.   
To understand which source is currently being used for position data, you can check the  
* Enhanced tachograph-related logging and error handling to make diagnostics clearer.
Location Source parameter.
* Fixed transmission of vehicle and driver identification values (such as VIN, VRN and driver identification) so that accurate identification data is always sent.
5.1 Location Source values 
'''FMS / Manual CAN / CAN / Eco Driving & Vehicle Data'''
In the Configurator:  
* Fixed missing or incorrect reading of specific FMS parameters, including version-specific parameter sets.   
1. Navigate to the I/O tab (or equivalent I/O monitoring view). 
* Fixed fluctuating fuel levels when using FMS or CAN sources, improving fuel accuracy for both standard and EV FMS use cases.   
2. Find the parameter “Location Source”.
* Fixed issues where FMS-based speed was not being used correctly as the selected speed source.   
Possible values: 
* Improved overall CAN stability so that tachograph CAN and FMS information is not lost due to CAN bus overflow.   
• 0 – GNS 
* Fixed incomplete or malformed responses to commands that start or stop Manual CAN (MCAN) transmissions, ensuring clear responses and reliable remote control.
Location is taken from the internal GNSS receiver.   
* Ensured that Manual CAN requests and commands are no longer executed when ignition is OFF.   
o This is the default when RTK is disabled or when no valid RTK data is 
'''New Features'''
available.
* 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.  
• 1 – RS232
* 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.
Location is taken from the RTK receiver connected via RS232.   
* NEW! [[FMC650 Thermograph#Apach|Apache Thermograph]].
• 2 – CAN 
* NEW! [[FMC650 TrailerCAN|Trailer CAN]] functionality.  
Location is taken from RTK data arriving over CAN.   
* NEW! Implemented [[FMB scanevfms|“scanevfms“]] command for diagnosing electric trucks, providing targeted EV CAN diagnostics.   
• 3 – Err 
* NEW! Implemented “[[FMB can_info|can_info]]“ command that returns details of the CAN bus (baud rates, modes and other key parameters), aiding diagnostics.
Location is taken from the internal GNSS receiver, but this status indicates that 
* NEW! Updated the “[[FMB tachocheck|tachocheck“]] command to show more detailed information.
RTK data from RS232 and/or CAN is invalid or unavailable.   
'''Configuration, Parameters & Tools'''
o This helps distinguish normal GNSS use from “RTK expected but not  
* Fixed an issue where a single setparam command could not change multiple parameters at once.  
available” situations.   
* Fixed behaviour where the odometer command always returned a GNSS-based odometer value regardless of the configured odometer source.  
This parameter is especially useful for diagnostics and for confirming that your device is 
* Fixed cases where the device disconnected unnecessarily from the configurator.  
using the intended RTK source.   
* Fixed an issue where the SIM PIN was not remembered after soft or hard reset.
6. Monitoring NMEA Fix Type (RS232 RTK Only)  
</td>
When RTK coordinates are received via RS232, you can also monitor the NMEA Fix Type 
</tr>
to understand the quality of the GNSS/RTK fix.   
6.1 Where to find it 
1. Open the Configurator. 
2. Go to the I/O tab (or relevant section).   
3. Locate the parameter “NMEA Fix Type”.   
This parameter is only available when coordinate data is received via RS232 RTK.   
6.2 NMEA Fix Type values  
Value Description 
NotValid No valid GNSS fix is available.   
GPS Standard GPS fix using satellites only.   
DGNSS Differential GNSS fix (e.g. DGNSS, SBAS, etc.).   
NotApplicable Fix quality is not applicable in the current context.   
RTK_Fixed RTK Fixed; high-precision RTK fix (including xFill if 
supported by the receiver).
RTK_Float RTK Float; typically, a converging RTK solution or 
similar intermediate status.   
INS_DR INS Dead Reckoning; position estimated by inertial 
sensors and previous GNSS/RTK data.
This information is helpful for
• Verifying that the external RTK receiver is working correctly 
• Assessing overall RTK performance and stability  
• Logging and diagnostics in advanced deployments 
7. Parameter ID and AVL ID  
Below is a list of AVLID and Configurator ID assigned to specific item 
Name Parameter ID AVL ID 
RTK Longitude 151790 14145  
RTK Latitud 151800 14146  
RTK Altitude 151810 14147  
RTK Speed 151820 14148 
RTK Angle 151830 14149 
Source Location from RTK 55000 - 
Location Source 53050 10919 
NMEA Fix Type 53060 10920

Revision as of 10:40, 26 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.
  • NEW! Implemented a new feature called the “one minute rule” for tachograph driving state, reducing unnecessary state toggling and improving driving/rest detection accuracy.
  • NEW! Apache Thermograph.
  • NEW! Trailer CAN functionality.
  • NEW! Implemented “scanevfms“ command for diagnosing electric trucks, providing targeted EV CAN diagnostics.
  • NEW! Implemented “can_info“ command that returns details of the CAN bus (baud rates, modes and other key parameters), aiding diagnostics.
  • NEW! Updated the “tachocheck“ command to show more detailed information.

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.