|
|
| (4 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.
| |
| | |
| 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 [[FMC650 System settings#Records Saving/Sending Without TS|RAM memory]]. recommended for rapid data sending i.e. data saving every second etc. |
| | * 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. |
| | * NEW! [[FMC650 Thermograph#Apach|Apache Thermograph]]. |
| | * NEW! [[FMC650 TrailerCAN|Trailer CAN]] functionality. |
| | * NEW! Implemented [[FMB scanevfms|“scanevfms“]] command for diagnosing electric trucks, providing targeted EV CAN diagnostics. |
| | * NEW! Implemented “[[FMB can＿info|can_info]]“ command that returns details of the CAN bus (baud rates, modes and other key parameters), aiding diagnostics. |
| | * NEW! Updated the “[[FMB tachocheck|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. |
| | </td> |
| </tr> | | </tr> |
