1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
|
# OpenXC Message Format Specification
Version: v0.6.0
This specification is a part of the [OpenXC platform][OpenXC].
An OpenXC vehicle interface sends generic vehicle data over one or more output
interfaces (e.g. USB or Bluetooth) as JSON or Protocol Buffers (protobuf).
## JSON
The JSON format is the most flexible and easiest to use. The format is fully
specified in the [JSON.mkd](JSON.mkd) file in this repository.
a more flexible option than binary, but is less compact and
therefore takes more bandwidth and processing power.
The JSON format is best for most developers, as it is fairly efficient and very
flexible.
## Binary (Protocol Buffers)
The binary format is encoded using [Google Protocol
Buffers](https://code.google.com/p/protobuf/). The format is specified in the
file [openxc.proto](openxc.proto). The descriptions of the messages can be foud
in the JSON specs - the binary format mirrors this.
The binary messages are published by the VI using the standard length-delimited
method (any protobuf library should support this).
The binary format is best if you need to maximize the amount of data that can be
sent from the VI, trading off flexibility for efficiency.
## Message Pack
MessagePack is an efficient binary serialization format. It lets you exchange data
among multiple languages like JSON. But it's faster and smaller. Small integers are
encoded into a single byte, and typical short strings require only one extra byte
in addition to the strings themselves
For protocol specification visit
https://github.com/msgpack/msgpack/blob/master/spec.md
## Trace File Format
An OpenXC vehicle trace file is a plaintext file that contains JSON objects,
separated by newlines (which may be either `\r\n` or `\n`, depending on the
platform the trace file was recorded).
The first line may be a metadata object, although this is optional:
```
{"metadata": {
"version": "v3.0",
"vehicle_interface_id": "7ABF",
"vehicle": {
"make": "Ford",
"model": "Mustang",
"trim": "V6 Premium",
"year": 2013
},
"description": "highway drive to work",
"driver_name": "TJ Giuli",
"vehicle_id": "17N1039247929"
}
```
The following lines are OpenXC messages with a `timestamp` field added, e.g.:
{"timestamp": 1385133351.285525, "name": "steering_wheel_angle", "value": 45}
The timestamp is in [UNIX time](http://en.wikipedia.org/wiki/Unix_time)
(i.e. seconds since the UNIX epoch, 00:00:00 UTC, 1/1/1970).
## Official Signals
These signal names are a part of the OpenXC specification, although some
manufacturers may support custom message names.
* steering_wheel_angle
* numerical, -600 to +600 degrees
* 10Hz
* torque_at_transmission
* numerical, -500 to 1500 Nm
* 10Hz
* engine_speed
* numerical, 0 to 16382 RPM
* 10Hz
* vehicle_speed
* numerical, 0 to 655 km/h (this will be positive even if going in reverse
as it's not a velocity, although you can use the gear status to figure out
direction)
* 10Hz
* accelerator_pedal_position
* percentage
* 10Hz
* parking_brake_status
* boolean, (true == brake engaged)
* 1Hz, but sent immediately on change
* brake_pedal_status
* boolean (True == pedal pressed)
* 1Hz, but sent immediately on change
* transmission_gear_position
* states: first, second, third, fourth, fifth, sixth, seventh, eighth,
ninth, tenth, reverse, neutral
* 1Hz, but sent immediately on change
* gear_lever_position
* states: neutral, park, reverse, drive, sport, low, first, second, third,
fourth, fifth, sixth, seventh, eighth, ninth, tenth
* 1Hz, but sent immediately on change
* odometer
* Numerical, km
0 to 16777214.000 km, with about .2m resolution
* 10Hz
* ignition_status
* states: off, accessory, run, start
* 1Hz, but sent immediately on change
* fuel_level
* percentage
* 2Hz
* fuel_consumed_since_restart
* numerical, 0 - 4294967295.0 L (this goes to 0 every time the vehicle
restarts, like a trip meter)
* 10Hz
* door_status
* Value is State: driver, passenger, rear_left, rear_right.
* Event is boolean: true == ajar
* 1Hz, but sent immediately on change
* headlamp_status
* boolean, true is on
* 1Hz, but sent immediately on change
* high_beam_status
* boolean, true is on
* 1Hz, but sent immediately on change
* windshield_wiper_status
* boolean, true is on
* 1Hz, but sent immediately on change
* latitude
* numerical, -89.0 to 89.0 degrees with standard GPS accuracy
* 1Hz
* longitude
* numerical, -179.0 to 179.0 degrees with standard GPS accuracy
* 1Hz
## Signals from Diagnostic Messages
This set of signals is often retreived from OBD-II requests. The units can be
found in the [OBD-II standard](http://en.wikipedia.org/wiki/OBD-II_PIDs#Mode_01).
* engine_load
* engine_coolant_temperature
* barometric_pressure
* commanded_throttle_position
* throttle_position
* fuel_level
* intake_air_temperature
* intake_manifold_pressure
* running_time
* fuel_pressure
* mass_airflow
* accelerator_pedal_position
* ethanol_fuel_percentage
* engine_oil_temperature
* engine_torque
License
=======
Copyright (c) 2012-2014 Ford Motor Company
Licensed under the BSD license.
[OpenXC]: http://openxcplatform.com
|
