1 # Copyright (c) 2018-2020 NVIDIA CORPORATION. All rights reserved.
3 @page dwx_canbus_logger_sample CAN Message Logger Sample
6 @note SW Release Applicability: This sample is available in both **NVIDIA DriveWorks** and **NVIDIA DRIVE Software** releases.
8 @section dwx_canbus_logger_sample_description Description
10 The CAN Message Logger sample is a simple CAN bus listener sample. All
11 messages received over the CAN bus are printed on the console. A valid SocketCAN
12 or AurixCAN device must be present in the system. Please refer to your platform
13 datasheet for a description of the available CAN devices and the corresponding
16 @section dwx_canbus_logger_sample_running Running the sample
18 The CAN Message Logger sample, sample_canbus_logger, accepts the following parameters:
20 ./sample_canbus_logger --driver=[can.virtual|can.socket|can.aurix|can.custom]
21 --params=[comma/separated/key/value/pairs]
22 --filter=[id1:mask1+id2:mask2+..]
24 --send_i_understand_implications=[timeout]
25 --send_id=[message_ID]
29 --driver=[can.virtual|can.socket|can.aurix|can.custom]
30 Allows to specify which CAN interface to use.
31 Default value: can.virtual
33 --params=[comma/separated/key/value/pairs]
34 Different parameters are available for each CAN driver.
35 Default value: file=path/to/data/samples/sfm/triangulation/canbus.can
37 --filter=[id1:mask1+id2:mask2+..]
38 The sample provides support to filter (i.e., pass) messages of certain IDs. A
39 filter can be specified by adding `+` separated `id:mask` values to the
40 `--filter=` argument. A message is considered passing if `<received_can_id> &
42 Example 1 - pass all messages between 201-2FF: `--filter=200:F00`
43 Example 2 - pass only 100,110 and 301-31F: `--filter=100:FFF+110:FFF+300:FE0`
44 Example 3 - Empty filter. Pass all messages: `--filter=000:000`
45 Default value: "" : No filter is applied. Note that filters may still be applied during initilization by `params` messages.
48 DriveWorks supports hardware timestamps of the CAN messages. Xavier provides a hardware-based counter
49 timestamps all CAN messages on arrival directly on the SoC. For the case of AurixCAN,
50 the messages are timestamped by Aurix on arrival and passed together with the CAN messages over UDP
51 to DriveWorks. In order for hardware timestamps to work for SocketCAN, the application must run with
55 --send_i_understand_implications=[timeout]
56 Allows to generate a random CAN message each timeout ms
57 Note that sending might interfere with real hardware; therefore, only
58 use it if you know what you are doing.
61 --send_id=[message_ID]
62 Allows to send message with a custom ID.
63 This is only applicable if --send_i_understand_implications is not 0.
67 What size message should be sent.
68 This is only applicable if --send_i_understand_implications is not 0.
69 This results in sending non CAN FD messages if size is 0-8 and sending CAN FD messages if greater than 8.
73 @note For a full list of key/value pairs that can be passed to --params see @ref dwx_sensor_enum_sample .
75 @subsection dwx_canbus_logger_sample_examples Examples
77 #### Run with a Virtual CAN Device
79 Test the applications using either a real CAN device or a virtual one. Create a
80 virtual device using the following commands:
83 sudo ip link add dev vcan0 type vcan
84 sudo ip link set vcan0 mtu 72 # if want to use Can-FD mode
85 sudo ip link set up vcan0
87 In order to send data from the console to the virtual CAN bus, use the `cansend`
88 tool (from the `can-utils` package).
90 cansend vcan0 30B#1122334455667788
92 This example sends a CAN message with ID 0x30B and with 8-bytes containing:
95 If using the virtual CAN interface, the sample can be started with
96 `--driver=can.socket --params=device=vcan0` to listen on the virtual CAN
97 interface. Any message sent with `cansend vcan0` is displayed on the console.
99 @note the virtual CAN interface is not available on QNX
101 #### Run with Real Hardware
103 If using real-hardware connected to the CAN bus, set the bitrate to 500 KB in
104 order to test the sample. The sample does not support changing of the bitrate.
105 Set the bitrate on the CAN device by executing:
107 sudo ip link set can0 type can bitrate 500000
108 sudo ip link set can0 up
110 @note the steps above are not needed on QNX
112 The CAN interface used to listen on a real CAN bus must have SocketCAN driver
113 implementation in the system. A SocketCAN based driver can be identified easily
114 if `:> sudo ifconfig -a` returns the default network interfaces **and** a CAN
115 based interface (i.e., canX, slcanX, etc).
118 @note the virtual CAN interface is not available on QNX
123 To execute the sample to listen on the SocketCAN connectors, use:
125 --driver=can.socket --params=device=can0
129 On NVIDIA DRIVE<sup>™</sup> platforms, CAN messages can be sent and received by the Xaviers through Aurix.
130 For this to work, a proper setup of the Aurix needs to be made prior to running the application. Please
131 refer to the EasyCAN user guide provided as part of PDK documentation to set up Aurix to filter
132 and pass a selected subset of CAN messages. In order to connect to AurixCAN, use the following arguments:
134 --driver=can.aurix --params=ip=10.42.0.146,bus=a,config-file=/path/to/EasyCanConfigFile.conf
136 Where `ip` is the IP address from which the CAN messages are forwarded, `bus`
137 points to the corresponding CAN bus connector, i.e., CAN-1->a, ..., CAN-4->d, and `config-file`
138 points to an EasyCAN configuration file. An example file is provided in the DriveWorks data folder,
139 under /path/to/data/samples/sensors/can. Refer to the DriveWorks CAN bus documentation for more
140 details on this file.
142 The connection to AurixCAN happens using UDP sockets. Additional arguments for the remote (`aport`) and
143 local (`bport`) UDP port can be specified if AurixCAN is working in a non-default configuration. By
144 default, on DRIVE AGX, AurixCAN is reachable over `aport=50000` and communicates with the Xavier over `bport=60395`.
148 Additionally, the sample can be used as a CAN message generator:
150 ./sample_canbus_logger --send_i_understand_implications=100
152 in this case it generates a random CAN message each 100ms.
153 Note that sending might interfere with real hardware; therefore, only
154 use it if you know what you are doing.
156 @section dwx_canbus_logger_sample_output Output
158 The sample prints on console the received CAN messages:
160 5651471936 -> 100 [5] 7E BB 02 00 00
161 5651471936 (dt=0) -> 200 [5] 80 57 02 00 00
162 5651474567 (dt=2631) -> 100 [5] A0 C1 02 00 00
163 5651474567 (dt=0) -> 200 [5] 80 57 02 00 00
164 5651477205 (dt=2638) -> 100 [5] A0 C1 02 00 00
165 5651477205 (dt=0) -> 200 [5] 80 57 02 00 00
166 5651479850 (dt=2645) -> 100 [5] A0 C1 02 00 00
167 5651479850 (dt=0) -> 200 [5] 80 57 02 00 00
168 5651482733 (dt=2883) -> 100 [5] A0 C1 02 00 00
169 5651482733 (dt=0) -> 200 [5] 80 57 02 00 00
170 5651485391 (dt=2658) -> 100 [5] 02 C9 02 00 00
171 5651485391 (dt=0) -> 200 [5] 11 65 02 00 00
172 5651487984 (dt=2593) -> 100 [5] 02 C9 02 00 00
173 5651487984 (dt=0) -> 200 [5] 11 65 02 00 00
174 5651490645 (dt=2661) -> 100 [5] 02 C9 02 00 00
175 5651490645 (dt=0) -> 200 [5] 11 65 02 00 00
176 5651493322 (dt=2677) -> 100 [5] 02 C9 02 00 00
177 5651493322 (dt=0) -> 200 [5] 11 65 02 00 00
178 5651496024 (dt=2702) -> 100 [5] 5A D0 02 00 00
179 5651496024 (dt=0) -> 200 [5] 11 65 02 00 00
180 5651498602 (dt=2578) -> 100 [5] 5A D0 02 00 00
181 5651498602 (dt=0) -> 200 [5] 11 65 02 00 00
182 5651501306 (dt=2704) -> 100 [5] 5A D0 02 00 00
183 5651501306 (dt=0) -> 200 [5] 11 65 02 00 00
184 5651504039 (dt=2733) -> 100 [5] 5A D0 02 00 00
185 5651504039 (dt=0) -> 200 [5] 11 65 02 00 00
186 5651506639 (dt=2600) -> 100 [5] 7C D6 02 00 00
188 @section dwx_canbus_logger_sample_more Additional Information
190 For more details see @ref canbus_mainsection .