(85 intermediate revisions by the same user not shown)
Line 1:
Line 1:
=== <u>Introduction</u> ===
=External RTK coordinate via CAN/RS232 interface with FMC650=
'''Dead Reckoning''' is a navigation technique used to estimate current position of vehicle , direction of movement, based on its previous position and known speed. It uses additional sensor data to correct the position received from GNSS receiver.<br>
==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:
* External RTK receiver via RS232
* External RTK data via CAN
* Internal GNSS receiver (GNSs) as fallback (does not has RTK)
The device automatically chooses the best available source based on configuration and data quality.
Usage of Dead Reckoning is essential in scenarios where GNSS signal is weak or unavailable, such as underground parking lots, tunnels or dense forests.<br>
The following specifications indicate the minimum firmware and configurator version requirement to use RTK coordinate acquisition via CAN on FMC650.
'''Note:''' Dead Reckoning is enabled for all FT platform devices with gyroscope. At the moment, it’s not possible to disable it.<br>
*Platform: FM65
* '''Device''': FMC650
* '''Firmware version''': 03.01.03.Rev.228
* '''Configurator version''': B.FMX6_R.192
=== <u>Prerequisites</u> ===
==Method of Operation==
Key points to understand before utilizing the Dead Reckoning functionality:
When the RTK option is enabled, the device always tries to use RTK sources first and falls back to internal GNSS if needed.
* Installation
* Configuration
* Alignment
'''<u>Installation</u>'''<br>
'''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.
The device must be mounted firmly in the vehicle, with good visibility of the sky. Failure to ensure proper mounting will result in inability to calibrate the device or inaccurate position estimation. DIN1 should be connected to the vehicle ignition (''' applicable to trackers with DIN1'''), it will be used to detect both ignition status and movement, ensuring optimal performance. Following examples ensure that the GNSS antenna is facing towards the sky and there are no physical obstacles, like metal plates, wires, are blocking the GNSS signal.
'''RTK data from CAN'''
Good '''mounting''' examples ( <span style="color:red">'''If vehicle has a heated windshield, you should look for an alternative mounting location in the trunk, on some sturdy metal closer to backseat window'''</span>):<br>
When CAN is used as the RTK source, the device reads:
<div style="display: flex; flex-direction: row;">
*'''Latitude'''
[[File:FTC927 under the front dashboard in the middle of the car.jpg|thumb|left|280px|Dashboard in the middle of the car mount]]
*'''Longitude'''
[[File:FTC927 beneath the speedometer panel.jpg|thumb|left|300px|Beneath the speedometer panel]]
*'''Altitude'''
[[File:FTC927 above the glove box.jpg|thumb|left|300px|Above glove box]]
*'''Ground speed'''
</div>
*'''Course'''
Bad '''mounting''' examples:<br>
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.
<div style="display: flex; flex-direction: row;">
[[File:Dead Reckoning Unwanted movements will be detected by the IMU.png|thumb|left|280px|Unwanted movements will be detected by the IMU]]
[[File:Dead Reckoning Metal parts above the mount.png|thumb|left|300px|Metal parts above the mount]]
[[File:Dead Reckoning vibration could cause unwanted device movements.png|thumb|left|300px|Places, where vibration could cause unwanted device movements]]
</div>
'''<u>Configuration</u>'''<br>
==Configurator Setup==
This section describes how to enable RTK as a location source and configure RS232 and CAN usage through the Configurator.
#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'''.
''The Dead Reckoning feature is configurable via the Dead Reckoning section in the GNSS settings group under System view in TCT.''
When enabled, the device will use RTK data from RS232/CAN if available, with automatic fallback to internal GNSS.
Parameter list can be found [[Template:FTX_System#Parameter_list|here]].
For advanced configuration (e.g. via commands):
===== Dead Reckoning alignment status =====
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)
The Dead Reckoning alignment status is a 1-byte AVL ID (1433) that indicates the current status of the Dead Reckoning alignment. The possible values are:<br>
Configuring RS232 for RTK Use
* '''0''' - Unknown: Dead Reckoning status is unknown.
If you plan to use an external RTK receiver via RS232:
* '''1''' - Init: Dead Reckoning alignment is initializing.
#Open the RS232/RS485 tab in the Configurator.
* '''2''' - Coarse: Dead Reckoning is in alignment stage.
#For COM1 or COM2 (or both), set the mode to RTK.
* '''3''' - Stable: Dead Reckoning alignment stage has been completed. Estimation stage is in progress.
* '''99''' - Standby: Dead Reckoning is in standby mode ('''NOTE''': this status is availabe with 3.7.X or newer firmware version)
<!--===== Turning alignment =====
The turning alignment is a 1-byte AVL ID ('''1434''') that indicates the current percentage of the turning alignment of the device.
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.
===== Straight alignment =====
[[File:RS232 settings - RTK.png|right]]
The straight alignment is a 1-byte AVL ID ('''1435''') that indicates the current percentage of the straight alignment of the device.
'''Using CAN as the RTK Source'''
'''
CAN-based RTK is used in the following cases:
===== Dead Reckoning realignment reason =====
*None of the RS232 COM ports are configured in RTK mode, or
The Dead Reckoning realignment reason is a 1-byte AVL ID ('''1473''') that indicates the reason for the Dead Reckoning realignment. The possible values are:
*RS232 RTK data is not valid or not present.
* '''-1''' or '''-2:''' GNSS cross check failed. The algorithm detected that the estimated position differs from the GNSS position vastly.
When those conditions are met and valid CAN RTK data is received:
* '''-3''' or '''-4:''' Unexpected vibrations detected.
*The device uses CAN as the coordinate source.
* '''-5:''' Unexpected rotation detected.
*The device continuously monitors the time between RTK messages.
* '''-6:''' GNSS signal quality dropped before the alignment was completed.
*If CAN RTK messages are delayed by more than 2 seconds, the device automatically reverts to internal GNSS to avoid stale coordinates.
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.
'''<u>Alignment</u>'''<br>
'''ISOBUS Data Visibility'''
Once device mounting adheres to the guidelines, alignment can be performed. The device '''must finish''' a specific alignment process to '''determine''' its mounting orientation. During this process, there are specific conditions that must be met:
When used in ISOBUS or similar environments:
# The device must be '''stationary''' with clear sky visibility for at least 3 minutes.
[[File:ISOBUS - RTK.png]]
<!--# A great number of '''left and right''' turns must be performed.-->
*RTK-related data from CAN is visible in the ISOBUS section of the Configurator.
# Vehicle speed during alignment should be between 10 km/h and 100 km/h, with varying speeds preferred over extended constant-speed driving.
# Avoid driving in underground tunnels or areas with poor GNSS signal, otherwise alignment needs to be restarted from the second step.
[[File:Dead Reckoning TCT Swift .png|right|400px]]
We are currently using only the '''Swift''' alignment type. Other types are still unreliable and do not provide better results.
*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.
<!--=== <u>How It Works</u> ===
'''Location Source Values'''
//Dead Reckoning functionality consists of two stages:<br>
//* '''Alignment stage''' - The algorithm tries to find the mounting orientation of the device.
* '''Estimation stage''' - The algorithm estimates the current position of the device based on IMU and ('''if available''') GNSS data.
'''<u>Alignment stage</u>'''
In the Configurator:
Before the algorithm can start estimating the position, it needs to calculate the mounting orientation of the device - this is called the '''alignment''' of IMU and vehicle frames. The result of the alignment is a set of angles that represent the orientation of the device in space, which is used to transform the IMU data into the vehicle frame during Estimation stage.<br>
#Navigate to the '''I/O''' tab (or equivalent I/O monitoring view).
#Find the parameter '''Location Source'''.
[[File:Location source.png]]
Alignment is started automatically and constantly observes following parameters: <br>
Possible values:
* '''GNSS signal quality''' - The algorithm needs to have a good GNSS fix to calculate the mounting orientation. If during the alignment the signal quality drops below a certain threshold, the algorithm will trigger a realignment.
*'''0 – GNS'''
* '''IMU data''' - The algorithm constantly observes the received IMU data. If it detects that the device movement/rotation exceeded a certain threshold, it will trigger a realignment.<br>
Location is taken from the internal GNSS receiver. This is the default when RTK is disabled or when no valid RTK data is available.
'''Note:''' The Dead Reckoning alignment status AVL ID ('''1433''') will change from '''2''' (Coarse) to '''3''' (Stable). Positional data in records will contain Dead Reckoning data.
*'''1 – RS232'''
Location is taken from the RTK receiver connected via RS232.
'''<u>Estimation stage</u>'''
*'''2 – CAN'''
Once the alignment stage is completed, the algorithm enters the estimation stage. The algorithm uses the IMU data to estimate the current position of the device, and if GNSS data is available, it uses it to correct the estimated position. The Dead Reckoning algorithm itself is based on the application of an extended Kalman filter (EKF), which operates in two main states:<br>
Location is taken from RTK data arriving over CAN.
# '''Predict''' - The algorithm predicts the current position of the device using IMU sensor readings and the previously estimated position.
*'''3 – Err'''
# '''Update''' - The predicted position is corrected using the calculated GNSS position from GNSS receiver.-->
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.
=== <u>Limitations</u> ===
This parameter is used for diagnostics and for confirming that your device is using the intended RTK source.
There are some important things to keep in mind when using the Dead Reckoning functionality. The algorithm tries to correct for these issues, but sometimes they can still affect how well Dead Reckoning works.
* '''Position accuracy may decrease''' - If the device cannot receive a GNSS signal for a long time, the estimated position may become less accurate. This is because the sensors inside the device can only estimate the position for a limited time without help from GNSS.
==NMEA Fix Type Monitoring (RS232 RTK Only)==
For example: If a courier spends up to 30 minutes unloading in the underground car park, DR will remain accurate. Otherwise, positioning information will become less accurate.
When RTK coordinates are received via RS232, you can also monitor the NMEA Fix Type to understand the quality of the GNSS/RTK fix.
* '''Temperature effects''' - The accuracy of the position can change if the temperature is very different from when the device was last calibrated.
* '''Alignment reset''' - If the device loses power or goes into sleep mode, it will need to be calibrated again.
'''Tip:''' If alignment auto-save is enabled, realignment will be faster.
'''Configurator Steps'''
#Open the Configurator.
#Go to the I/O tab (or relevant section).
#Locate the parameter '''NMEA Fix Type'''.
* '''Position jumps after GNSS outages''' - After the device has been in an area with no GNSS signal for a while (such as near tall buildings or obstacles), you might notice sudden jumps in the position when the signal returns. This happens because the device uses the GNSS signal to correct its estimated position, and the type of GNSS signal used is more sensitive to interference from nearby objects.
[[File:NMEA Fix Type.png]]
* '''Stand by mode''' - This feature allows calibration data to be stored for unlimited time, meaning that Dead Reckoning will work accurately even if a week has passed while vehicle was left in underground parking. Functionality will be present in 3.7.X firmware version, so current solution is limited and tracker will lose Dead Reckoning alignment after an hour has passed since ignition OFF event. If vehicle was parked for less than 1 hour, track might be slightly tilted, but if parking lasts more than an hour - GNSS fix needs to be re-acquired. This applies for above and underground parking.
'''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>
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:
External RTK receiver via RS232
External RTK data via CAN
Internal GNSS receiver (GNSs) as fallback (does not has RTK)
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
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
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 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:
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.
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:
Navigate to the I/O tab (or equivalent I/O monitoring view).
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
Open the Configurator.
Go to the I/O tab (or relevant section).
Locate the parameter NMEA Fix Type.
Note: This parameter is only available when coordinate data is received via RS232 RTK.
