a hexidecimal number in a string. Many JSON parser cannot handle 64-bit
integers, which is why we are not using a numerical data type. Each byte in
the string *must* be represented with 2 characters, e.g. `0x1` is `0x01` - the
- complete string must have an even number of characters.
+ complete string must have an even number of characters. The `0x` prefix is
+ optional.
### Diagnostic Messages
#### Requests
-A diagnostic request is created, update and deleted with a JSON object like this
-example:
+A diagnostic request is added or cancelled with a JSON object like this example:
{ "command": "diagnostic_request",
- "action": "create",
+ "action": "add",
"request": {
"bus": 1,
"id": 1234,
* The `command` must be `diagnostic_request.`
* The `action` must be included, and must be one of:
- * `create` - create a new one-off or recurring diagnostic request.
- * `update` - update an existing request.
- * `delete` - delete an existing request.
+ * `add` - create a new one-off or recurring diagnostic request.
+ * `cancel` - cancel an existing request.
* The details of the request must be included in the `request` field, using
the sub-fields defined below.
simple one-time diagnostic request:
{ "command": "diagnostic_request",
- "action": "create",
+ "action": "add",
"request": {
"bus": 1,
"id": 1234,
previous example as a recurring request at 1Hz:
{ "command": "diagnostic_request",
- "action": "create",
+ "action": "add",
"request": {
"bus": 1,
"id": 1234,
To cancel a recurring request, send a `cancel` action with the same key, e.g.:
{ "command": "diagnostic_request",
- "action": "delete",
+ "action": "cancel",
"request": {
"bus": 1,
"id": 1234,
}
}
-To update one of the fields of a recurring request, send an `update` action with
-the same key, plus the field to update. For example, to change the frequency of
-the example request to 2Hz:
-
- { "command": "diagnostic_request",
- "action": "update",
- "request": {
- "bus": 1,
- "id": 1234,
- "mode": 1,
- "pid": 5,
- "frequency": 2
- }
- }
- }
-
Simultaneous recurring requests for the same key at different rates (e.g. 1Hz
*and* 2Hz) is not supported. However, non-recurring ("one-off") requests may
exist in parallel with a recurring request for the same key.
**id** - the CAN arbitration ID for the request.
-**mode** - the OBD-II mode of the request - 1 through 255 (1 through 9 are the
+**mode** - the OBD-II mode of the request - 0x1 through 0xff (1 through 9 are the
standardized modes and 0x22 is a common proprietary mode).
**pid** - (optional) the PID for the request, if applicable.
represented as a hexadecimal number in a string. Many JSON parser cannot
handle 64-bit integers, which is why we are not using a numerical data type.
Each byte in the string *must* be represented with 2 characters, e.g. `0x1`
- is `0x01` - the complete string must have an even number of characters.
+ is `0x01` - the complete string must have an even number of characters. The
+ `0x` prefix is optional.
**name** - (optional, defaults to nothing) A human readable, string name for
this request. If provided, the response will have a `name` field (much like a
{ "command_response": "device_id", "message": "0012345678"}
+#### Passthrough CAN Mode
+
+The `passthrough` command controls whether low-level CAN messages are passed
+through from the CAN bus through the VI to the output stream. If the CAN
+acceptance filter is in bypass mode and passthrough is enabled, the output
+stream will include all received CAN messages. If the bypass filter is enabled,
+only those CAN messages that have been pre-defined in the firmware are
+forwarded.
+
+**Request**
+
+ { "command": "passthrough",
+ "bus": 1,
+ "enabled": true
+ }
+
+**Response**
+
+If the bus in the request was valid and the passthrough mode was changed, the
+`status` field in the response will be `true`. If `false`, the passthrough mode
+was not changed.
+
+ { "command_response": "passthrough", "status": true}
+
+#### Acceptance Filter Bypass
+
+The `af_bypass` command controls whether the CAN message acceptance filter is
+bypassed for each CAN controller. By default, hardware acceptance filter (AF) is
+enabled in the VI - only previously defined CAN message IDs will be received.
+Send this command with `bypass: true` to force the filters to bypassed.
+
+If `passthrough` mode is also enabled, when the AF is bypassed, the output will
+include all CAN messages received.
+
+**Request**
+
+ { "command": "af_bypass",
+ "bus": 1,
+ "bypass": true
+ }
+
+**Response**
+
+If the bus in the request was valid and the AF mode was changed, the `status`
+field in the response will be `true`. If `false`, the passthrough mode was not
+changed.
+
+ { "command_response": "af_bypass", "status": true}
+
### Trace File Format
An OpenXC vehicle trace file is a plaintext file that contains JSON objects,
Code Review / apps / agl-service-can-low-level.git / blobdiff