Jump to content
  • EN

Test-AC: Difference between revisions

From Teltonika Telematics Wiki
← Older editNewer edit →
VisualWikitext
No edit summary
No edit summary
Line 1: Line 1:
===Firmware versions===
=RTK Coordinate via CAN Integration with FMC650=
==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.


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

RTK Coordinate via CAN Integration with FMC650

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

  1. 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.
  2. 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.
  3. Internal GNSS (GNS) fallback
    • If neither RS232 nor CAN provide valid RTK data, the device uses the internal GNSS receiver (GNS) for coordinates.
  4. 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.

General Information

  • Platform: FM65
  • Device: FMC650
  • Firmware version: 03.01.03.Rev.227
  • Configurator version: B.FMX6_R.192

These versions indicate the minimum firmware and configurator level required to use RTK coordinate acquisition via CAN on FMC650.

Configurator Setup

This section describes how to enable RTK as a location source and configure RS232 and CAN usage through the Configurator. 4.1 Enabling RTK as a location source 1. Open the Configurator and connect to the FMC650 device. 2. Navigate to the System tab. 3. Find the option “Source Location from RTK” 4. 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 o Parameter ID: 55000 o Values: ▪ 0 – Disabled (device uses only internal GNSS) ▪ 1 – Enabled (device uses RTK sources if available) 4.2 Configuring RS232 for RTK use If you plan to use an external RTK receiver via RS232: 1. Open the RS232/RS485 tab in the Configurator. 2. For COM1 or COM2 (or both), set the mode to RTK. Relevant parameter IDs: • COM1 mode – Parameter ID 151 • COM2 mode – Parameter ID 173 • Value for RTK mode – 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. 4.3 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. 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’s documentation. 4.4 ISOBUS data visibility When used in ISOBUS or similar environments: • 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. 5. Monitoring the Active Location Source To understand which source is currently being used for position data, you can check the Location Source parameter. 5.1 Location Source values In the Configurator: 1. Navigate to the I/O tab (or equivalent I/O monitoring view). 2. Find the parameter “Location Source”. Possible values: • 0 – GNS Location is taken from the internal GNSS receiver. o 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. o This helps distinguish normal GNSS use from “RTK expected but not available” situations. This parameter is especially useful for diagnostics and for confirming that your device is using the intended RTK source. 6. Monitoring NMEA Fix Type (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. 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

Retrieved from "https://wiki.teltonika-gps.com/index.php?title=Test-AC&oldid=112107"