Jump to content
  • EN

Test-AC: Difference between revisions

From Teltonika Telematics Wiki
← Older edit
VisualWikitext
Updating per GTPGTM-11768 - 3 new paragraphs added and existing ones updated or reworded
No edit summary
 
(10 intermediate revisions by one other user not shown)
Line 1: Line 1:
==Introduction==
=External RTK coordinate via CAN/RS232 interface 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. 


With a professional device lineup, telltale information (dashboard indicators) from heavy-duty vehicles can be read remotely to identify a variety of issues. New feature of Diagnostic Trouble Code (DTC) reading will help to narrow down the specific faults happening in vehicles.  
The following specifications indicate the minimum firmware and configurator version requirement to use RTK coordinate acquisition via CAN on FMC650.


With {{{model}}} you can read 2 types of DTC messages based on J1939 protocol:  
*<b>Platform:</b> FM65 
*<b>Device:</b> FMC650 
*<b>Firmware version:</b> 03.01.03.Rev.228 
*<b>Configurator version:</b> B.FMX6_R.192 


*DM1 – Communicates currently present faults
==Method of Operation==
*DM2 – Reports stored faults
When the RTK option is enabled, the device always tries to use RTK sources first and falls back to internal GNSS if needed. 


{{{model}}} is able to read DM codes and pass them to the server in IO element. When active DM1 messages are present on the CAN line, they are broadcast frequently. The {{{model}}} device stores these codes in its internal memory and transmits only newly detected DTC codes.
'''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.  


DM2 messages are not streamed, but instead, they must be requested.
'''RTK data from CAN'''


==Functionality Description==
When CAN is used as the RTK source, the device reads: 
*'''Latitude''' 
*'''Longitude''' 
*'''Altitude''' 
*'''Ground speed''' 
*'''Course'''


This functionality is available from Firmware version '''03.01.02.rev.06''' or higher.
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.


For proper functionality, the device requires ignition to be active. Source of ignition and voltage level can be selected from '''System''' tab.
==Configurator Setup== 
This section describes how to enable RTK as a location source and configure RS232 and CAN usage through the Configurator.


Ignition has to be active for at least 14 sec to start generating the DTC list. If ignition is turned off, the device will clean all DM1 and DM2 codes and functionality will not be working.
'''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'''.


[[File:DTC_Ignition.png]]
When enabled, the device will use RTK data from RS232/CAN if available, with automatic fallback to internal GNSS.


After the device is connected to the Configurator, there will be '''DM1 / DM2''' tab made available. There is a configurable DM1 / DM2 Data source parameter. This parameter selects the CAN source based on which device will parse DM data from. Based on selected data source, device will also call a request for DTCs.
For advanced configuration (e.g. via commands):


'''Note:''' The functionality is completely separated from the FMS source.
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)


[[File:DTC Data source selection.png]]
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.


*NONE – Device will not use any CAN as data source
Relevant parameter IDs: 
*CAN1 – Device will use CAN1 as data source
*'''COM1 mode''' – Parameter ID 151 
*CAN2 – Device will use CAN2 as data source
*'''COM2 mode''' – Parameter ID 173 
*BOTH – Device will use CAN1 and CAN2 as data source
*'''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. 


Bellow '''Data source''' parameters there is a list of configurable IOs
[[File:RS232 settings - RTK.png|right]]


[[File:DTC Configurable IOs.png]]
'''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 


„DTC DM1“ and “DTC DM2“ shows the last DTC that has been detected. „Active DM1 List“ and „Active DM2 List“ provides a list of all active DTCs for a given source.
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.


Example of generating DM1 / DM2 list: To register DM1 code, it is required to send a command using (pgn 0xFEFA). Device will first check if such DTC code exist in the system (MCUID and CAN Source has to be unique for each DTC). Otherwise, DTC will be rejected.
'''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.


[[File:DTC Configurator outputs.png]]
*This allows you to verify that RTK data is being received and interpreted correctly by the device.


<span style="color:green;">9D000301:<span style="color:blue;">01:<span style="color:red;">01
==Active Location Source Monitoring==
*<span style="color:green;">9D000301</span> – DTC in hexadecimal format
To understand which source is currently being used for position data, you can check the '''Location Source''' parameter. 
*<span style="color:blue;">01</span> – MCU source that reported the DTC
*<span style="color:red;">01</span> – Device CAN source used (00 - CAN1, 01 - CAN2)


<span style="color:green;">9D000302:<span style="color:blue;">02:<span style="color:red;">01
'''Location Source Values'''
*<span style="color:green;">9D000302</span> – DTC in hexadecimal format
*<span style="color:blue;">02</span> – MCU source that reported the DTC
*<span style="color:red;">01</span> – Device CAN source used (00 - CAN1, 01 - CAN2)


Based on configured „Priority“, „Event Only“ and „Operand“ device will add this parameter to record.
In the Configurator: 
#Navigate to the '''I/O''' tab (or equivalent I/O monitoring view).
#Find the parameter '''Location Source'''.
[[File:Location source.png]]


[[File:DTC Terminal logs.png]]
Possible values:  


To remove one of the DTC from DM1 list, DM2 code (pgn 0xFEFB) is required. Device will check if the sent DTC code exists in the system (MCUID and CAN Source has to be unique for each DTC). If sent DTC does not exist in the system, it will be rejected.
*'''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.


Based on previous example, sending DTC 9D000301 with MCUID 01 on CAN2, device remove this DTC from the system, as the result, this DTC is removed from „Active DM1 List“ and added to the „Active DM2 List“.
*'''1 – RS232'''
Location is taken from the RTK receiver connected via RS232.


[[File:DTC Configurator outputs 2.png]]
*'''2 – CAN'''
Location is taken from RTK data arriving over CAN.  


Log example:
*'''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.


[[File:DTC Terminal logs 2.png]]
This parameter is used for diagnostics and for confirming that your device is using the intended RTK source.


That DTCs will be added to record and would be accessible on server. Data on server need to be converted from HEX to ASCII.
==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.


[[File:DTC Outputs from server.png]]
'''Configurator Steps'''
#Open the Configurator. 
#Go to the I/O tab (or relevant section). 
#Locate the parameter '''NMEA Fix Type'''.  


'''39443030303330323A30323A30313B''' -> (after conversion from hex to ANSCII) '''9D000302:02:01''';
[[File:NMEA Fix Type.png]]


'''39443030303330313A30313A30313B''' -> (after conversion from hex to ANSCII) '''9D000301:01:01''';
'''Note:''' This parameter is '''only available when coordinate data is received via RS232 RTK'''. 


==DM1/DM2 Message Structure==
'''NMEA Fix Type Values'''


'''DM1''' is a J1939 diagnostic message used to broadcast active faults and warning lamp status. Its structure is split into a header (lamp status) followed by one or more diagnostic trouble codes. Unlike most J1939 messages, DM1 has a variable length: if there are 0–1 active DTCs, it fits in a single CAN frame, while 2 or more DTCs require a multi-frame message with additional DTC entries added.  
*'''NotValid''' - No valid GNSS fix is available.<br>


[[File:DM1 and DM2 Message Structure.png]]
*'''GPS''' - Standard GPS fix using satellites only.<br>


The first 2 bytes form the lamp status header, which is shared across all DTCs. Each lamp uses 2-bit values to indicate status (off/on), along with flash signals defining how the lamp blinks (slow or fast). These signals are interpreted collectively across ECUs, with a central controller typically deciding the final lamp behavior based on the most severe reported condition.
*'''DGNSS''' - Differential GNSS fix (e.g. DGNSS, SBAS, etc.).<br>


Each DTC contains four key components:
*'''NotApplicable''' - Fix quality is not applicable in the current context. <br>
*'''SPN(''Suspect Parameter Number)''''' - Identifies the faulty subsystem.
*'''FMI(''Failure Mode Identifier)''''' - Describes the type of failure.
*'''CM(''SPN Conversion Method)''''' - Indicates the encoding method.
*'''OC(''Occurrence Count)''''' - Counts how often the fault has occurred.  


These elements provide detailed, structured information about vehicle faults while supporting both standardized and proprietary diagnostics.
*'''RTK_Fixed''' - RTK Fixed; high-precision RTK fix (including xFill if supported by the receiver).<br>


==DM1 Lamp Status and Flash Signals==
*'''RTK_Float''' - RTK Float; typically, a converging RTK solution or similar intermediate status.<br>


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.
*'''INS_DR''' - INS Dead Reckoning; position estimated by inertial sensors and previous GNSS/RTK data.<br> 


The first byte represents the status of four indicator lamps:
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.


*'''PL (Protect Lamp)''' - DTC's indicate non-electronic subsystem issue.
==Parameter IDs and AVL IDs==
*'''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.  
Below is a list of AVL IDs and Configurator IDs assigned to a specific item.


*'''MIL(Malfunction Indicator Lamp)''' - At least one DTC indicates emissions related issue.
<table class="nd-othertables_2" style="width:50%; border-collapse: collapse;">


Each lamp is encoded using 2 bits, allowing four possible states: '''off, on, slow flash, and fast flash'''. This compact encoding means all lamp states are conveyed within a single byte, with each pair of bits mapped to a specific lamp in a fixed order. These lamp states directly inform the operator about the severity and urgency of active faults.
<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>


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).
<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>


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).
<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>


==Global and Manufacturer SPN Codes==
<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>


===Global-Level SPN codes===
<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>


Standard codes are defined by the SAE J1939 standards and are recognized across all compliant vehicles and equipment. The SPNs for these codes fall within the range of '''1 to 24,324''' representing widely used parameters such as engine speed, coolant temperature, or oil pressure. FMI values are standardized, describing specific failure patterns such as high voltage, circuit open, or out-of-range conditions.
<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>


Because they are standardized, these codes are universally interpretable by any compliant diagnostic tool without requiring manufacturer-specific references.
<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>


===Manufacturer-Level SPN codes===
<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>


Manufacturer-level or proprietary codes are reserved for OEM-specific faults that are not defined in the J1939 standard. These allow manufacturers to monitor unique components, systems, or operational conditions that are specific to their equipment.
<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>


The SPNs for proprietary codes typically occupy the high end of the 19-bit field, ranging from '''516,096 to 524,287'''. FMI values may be standard or custom, but the meaning of the SPN is defined by the manufacturer. Accurate interpretation requires access to OEM documentation, as these codes are not universally defined or interpretable.
<tr>
 
<td style="vertical-align: middle; text-align: center;">NMEA Fix Type</td>
==Functionality Block Diagram==
<td style="vertical-align: middle; text-align: center;">53060</td>
Graphic representation of '''DM1''' and '''DM2''' functionality:
<td style="vertical-align: middle; text-align: center;">10920</td>
 
</tr>
[[File:DTC Functionality blok diagram.png]]

Latest revision as of 14:46, 14 April 2026

External RTK coordinate via CAN/RS232 interface 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.

The following specifications indicate the minimum firmware and configurator version requirement to use RTK coordinate acquisition via CAN on FMC650.

  • Platform: FM65
  • Device: FMC650
  • Firmware version: 03.01.03.Rev.228
  • Configurator version: 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

  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.

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

  1. Open the Configurator and connect to the FMC650 device.
  2. Navigate to the System tab.
  3. Find the option “Source Location from RTK” in the System Settings section.
  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
Parameter ID: 55000
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:

  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
  • 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.

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’sdocumentation.

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.

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:

  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. 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

  1. Open the Configurator.
  2. Go to the I/O tab (or relevant section).
  3. Locate the parameter NMEA Fix Type.

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.
  • 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 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.

Name Parameter ID AVL ID
RTK Longitude 151790 14145
RTK Latitude 151800 14146
RTK Altitude 151810 14147
RTK Speed 151820 14148
RTK Angle 151830 14149
Source Location from RTK 55000 -
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=112659"