CAN-Interface of the MSRTK-Module

CAN is a robust and widely spread data bus standard which is among other applications also used in almost all modern vehicles for communication between the various controllers in it.

The ANavS Multi-Sensor RTK Module (MSRTK Module) comes with a CAN Interface that allows the user to input wheel odometry values and/or to access the solution data over that interface. When equipped, the Interface can be accessed by the DE-9 connector on the module. The pin assignment is in accordance with CiA® 303-1 and also given below:

[, All Rights Released]

Pin Pin assignment
1 Not connected
4 Not connected
6 Not connected
8 Not connected
9 Not connected


The CAN Interface can be fully configured in the ANavS Wizard, where the whole configuration is done in the second step of the initialization process. The CAN-settings are divided in three categories: the bus settings and the two functions odometry input (CAN-Input) and solution output (CAN-Output). Every section has three buttons to get, set and restore the configurations of the corresponding section. By pressing the GET configuration button the configurations currently stored in the configuration file of the MSRTK module is loaded for this section. By pressing SET configuration, the configurations from this section are written in the configuration file and executed in the system. By pressing RESTORE configuration, the default configurations provided by ANavS gets restored. The configuration process is now explained in more detail:


CAN Bus settings:

In this section, all physical settings of the CAN Interface are configured. These are:

  • Bus-Speed:
    Select the Bit rate of the CAN bus. By default, 500 kBit/s are selected.
  • Termination enabled:
    CAN requires a 120 Ohm hardware termination at the last transceiver. The MSRTK System has a built in switchable 120 Ohm termination which can be enabled by using this slider.
  • Bus mode:
    The normal mode is the default mode in which the CAN Interface is fully operating. In the listen-only mode, the CAN-Controller does not transmit any data and does not acknowledge the received CAN-frames. This mode can be used to monitor the data bus without participate or interfere with the traffic on the bus. In the listen-only mode it is not possible to output solution information.
  • Output enabled:
    This function is intended as an extra security layer to avoid unintentional writing on the CAN bus. It has to be enabled in order to use the solution output functionality of the CAN Interface. Otherwise, it is recommended to switch it off.


Odometry input via CAN:

The ANavS sensor fusion can handle different forms of vehicle odometry. Up to 5 variables can therefore be defined. These are either one, two or four independent wheel speeds, and the steering angle or another heading information of the vehicle in the vehicle frame. The algorithms inside of the sensor fusion software calculate from the different inputs the current velocity and heading information in the body frame of the vehicle for the positioning algorithm.

To adjust the CAN-Interface to your specific messages, see the following guide: Dynamic Decoder – How To

Solution output via CAN:

The CAN Interface can be used to output the solution from the sensor fusion software. The CAN Interface sends for each solution variable a unique message containing the value. The CAN address corresponds to the ID of the variable. The variables are bundled in groups which can be activated or deactivated by checking the corresponding boxes. As standard, each packet has a unique ID which is also shown in the table below. To change the IDs of the CAN messages (e.g. to avoid collisions with the information of other devices on the bus), there is the possibility to add an offset to all messages.  To use the solution output via CAN, the bus must be configured in the normal mode and the output has to be enabled (see also section Bus settings).


ID Format Name Unit Description
1 uint16 resCode Result code bitfield, which keeps the system status and information.
2 uint16 week Week number of the current epoch.
3 double tow s Time of Week of the current epoch.
4 uint16 weekInit Week number of the epoch when the system was started.
5 double towInit s Time of Week of the epoch when the system was started.
7 double lat deg Latitude.
8 double lon deg Longitude.
9 double height m Height
10 double ECEF-X m X-position in ECEF-coordinate frame
11 double ECEF-Y m Y-position in ECEF-coordinate frame
12 double ECEF-Z m Z-position in ECEF-coordinate frame
13 – 15 3*double b m Baseline in NED frame spanned by the position given by lat, lon and height, and by the position of the reference station.
16 – 18 3*double bStdDev m Standard deviation of the baseline.
19 – 21 3*double vel m/s Velocity in NED frame.
22 – 24 3*double velStdDev m/s Standard deviation of the velocity.
25 – 27 3*double acc m/s² Acceleration in body frame.
28 – 30 3*double accStdDev m/s² Standard deviation of the acceleration.
31 – 33 3*double att deg Attitude/Euler angles (heading, pitch, roll).
34 – 36 3*double attStdDev deg Standard deviation of the attitude.
39 – 43 5*double timing-Info s CPU-Load of used sensors. The sum (green line in the GUI) of elapsed time should not over 1 second (–> to slow processor).
First double: Elapsed time GNSS;
Second double: Elapsed time IMU;
Third double: Elapsed time Baro;
Fourth double: Elapsed time Odometry;
Fifth double: Reserved
46 double latency-info s Overall end-to-end positioning latency
49 double gnssReception Scalar, which indicates the GNSS signal reception. The value is between 0 and 20, where 20 is the best, i.e. very good conditions.
50 uint8 numSats Number of satellites.