Read-only Raw CAN Configuration Examples¶
If you don’t care about abstracting the details of CAN messages from developers (or perhaps you’re the only developer and you’re working directly with CAN data), you can configure the VI to output full, low-level CAN messages. You can read every message or a filtered subset, but be aware that not every VI has enough horsepower to send every CAN messages through as JSON.
Unfiltered Raw CAN¶
We want to read all raw CAN messages from a bus at full speed. Be aware that the VI hasn’t been optimized for this level of throughput, and it’s not guaranteed at this time that messages will not be dropped. We recommend using rate limiting, which can dramatically decrease the bandwidth required without losing any information.
{ "buses": {
"hs": {
"controller": 1,
"speed": 500000,
"raw_can_mode": "unfiltered"
}
}
}
With this configuration, the VI will publish all CAN messages it receives using the OpenXC raw CAN message format, e.g. when using the JSON output format:
{"bus": 1, "id": 1234, "value": "0x12345678"}
Filtered Raw CAN¶
We want to read only the message with ID 0x21
from a high speed bus on
controller 1.
{ "buses": {
"hs": {
"controller": 1,
"speed": 500000,
"raw_can_mode": "filtered"
}
},
"messages": {
"0x21": {
"bus": "hs"
}
}
}
We added the 0x21
message and assigned it to bus hs
, but didn’t define
any signals (it’s not necessary when using the raw CAN mode).
This configuration will cause the VI to publish using the
OpenXC raw CAN message format, but
you will only received message 0x21
.
Unfiltered Raw CAN with Limited, Variable Data Rate¶
We want to read all raw CAN messages from a bus, but we don’t want the output interface to be overwhelmed by repeated duplicate messages. This is fairly common in vehicles, where a message is sent at a steady frequency even if the value hasn’t changed. For this example, we want to preserve all information - if a message changes, we want to make sure the data is sent.
{ "buses": {
"hs": {
"controller": 1,
"speed": 500000,
"raw_can_mode": "unfiltered",
"max_message_frequency": 1,
"force_send_changed": true
}
}
}
We combine two attributes to both limit the data rate from raw CAN messages, and
also make sure the transfer is lossless. The max_message_frequency
field
sets the maximum send frequency for CAN messages that have not changed to 1Hz.
We also set the force_send_changed
field to true
, which will cause a CAN
message with a new value to be sent to the output interface immediately, even if
it would go above the 1Hz frequency. The default is true
, so we could also
leave this parameter out for the same effect. The result is that each CAN
message is sent at a minimum of 1Hz and a maximum of the true rate of change for
the message.
Unfiltered Raw CAN with Strict, Limited Data Rate¶
We want to read all raw CAN messages as in Unfiltered Raw CAN with Limited, Variable Data Rate but we want to set a strict limit on the read frequency of each CAN message. We don’t care if we skip some CAN messages, even if they have new data - the maximum frequency is the most important thing.
{ "buses": {
"hs": {
"controller": 1,
"speed": 500000,
"raw_can_mode": "unfiltered",
"max_message_frequency": 1,
"force_send_changed": false.
}
}
}
We set the force_send_changed
field to false so the firmware will strictly
enforce the max message frequency.
Simple Messages and CAN Messages Together¶
We want to read the same signal as in the One Bus, One Numeric Signal example, but we also want to receive all unfiltered CAN messages simultaneously.
{ "buses": {
"hs": {
"controller": 1,
"raw_can_mode": "unfiltered",
"speed": 500000
}
},
"messages": {
"0x102": {
"bus": "hs",
"signals": {
"My_Signal": {
"generic_name": "my_openxc_measurement",
"bit_position": 5,
"bit_size": 7
}
}
}
}
}
We added set the raw_can_mode
for the bus to unfiltered
, as in
Unfiltered Raw CAN. No other changes are required - the CAN and simple
vehicle messages
co-exist peacefully. If we set raw_can_mode
to filtered
, it
would only send the raw message for 0x102
, where we’re getting the numeric
signal.
With this configuration, the VI will publish a mixed stream of OpenXC messages, both the CAN message format, and the simple vehicle message format, e.g. when using the JSON output format:
{"bus": 1, "id": 258, "value": "0x12345678"}
{"name": "my_openxc_measurement", "value": 42}