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.
  • ID Filter mask/Tag:
    The ID Filter checks all received packets at the transceiver if they fulfill the filter condition. The filter works as follow: For all received CAN messages, each received ID bit is compared with the corresponding bit in the ID tag only if the corresponding bit in the ID mask is set. Otherwise, the received bit is considered as don’t care. The filtering result is true if all comparisons are true and only then the packet gets processed in the MSRTK module.
    The filter should be set as selective as possible for avoiding unnecessary load in the module. The filter is by default disabled (Both fields set to 0). The best way to set the filter is by setting the fields with the following rule:

    • ID mask = (ID from message 0) XNOR (ID from message 1) XNOR (ID from message 2) XNOR …
      XNOR designates the Exclusive NOR bit operation
    • ID tag = (ID from message 0)


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. Each sensor information has a unique sensor index which is given by the following table:

Sensor-Index Corresponding Value
0 Front left wheel speed or speed of the vehicle in m/s (if it is the only used speed value)
1 Front right wheel speed in m/s
2 Rear left wheel speed in m/s
3 Rear right wheel speed in m/s
4 Steering angle or moving direction in the body frame in deg


To get the best result, it is recommended to provide as many parameters to the MSRTK system as possible. The sensor fusion software has algorithm support for the following combinations to calculate the heading and the absolute velocity of the vehicle. The combinations are illustrated in the table below with the provided values colored:

Sensor Index Possible combinations


The wheel speed is processed as a signed value. A negative speed means thereby that the wheel is turning backward. It is possible to define the sign on a different CAN message. This could be used if the turning direction of a wheel is encoded in another message or position than the speed. This can also be done with the steering angle if needed.

In the table in the Wizard are for each used Sensor-Index the value and the sign independently defined by the following parameter:

Name Range Description
Sensor-Index 0-4 Defines for which sensor index the configuration line is. It can be defined only once for a value and sign for the same index.
Value/Sign Value, Sign For each used value must be defined one Value field. It is possible to specify in addition to that a Sign field, defined in a separate message.
Message-Id 0-0x7FF This field defines the identifier of the CAN message containing the Value/Sign. Currently, the MSRTK Module supports only standard frame addressing, so enter maximal a 11-bit identifier.
Bit-Offset 0-64 The Bit-Offset indicates the starting position of the encoded information inside the CAN message.
Bit-Count 0-64 The Bit-Count indicates for how many bits the information is encoded in the message, starting at Bit-Offset.
Is Signed 0, 1 Indicates if the information is encoded as a signed or unsigned value.
Scale Specify here the multiplication factor that allows to get from the raw-value encoded in the CAN-Message to a speed information in m/s or angular information in rad.
Offset This field allows to add an offset to the Information, according to the following formula:
Y = [Raw-value from CAN-Message]*Scale + Offset
Min  Value The Min and Max values can be used to check the Information (already corrected by Scale and Offset) at plausibility. If the Information is not inside of these barriers, it gets dropped. If both Min- and Max- value are configured to 0, the information would not be checked.
Max Value See description of Min Value
Filter Mask The Payload Filter can be used if the described value is encoded in a packet structure that is also used for other values. This can be useful if, for example, the message looks for all wheels the same (with the same ID) but another wheel indicator given inside the payload.
The filter works as follow: For all received CAN messages each received payload bit is compared with the corresponding bit in the Filter Tag only if the corresponding bit in the Filter Mask is set. Otherwise the received bit is considered as don’t care. The filtering result is true if all comparisons are true. Only then the Value is used for that sensor.
Filter Tag See description of Filter Mask



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