X-Git-Url: https://gerrit.automotivelinux.org/gerrit/gitweb?a=blobdiff_plain;f=README.md;h=77758b835865fd28d1c877de832125aba5ff7bcb;hb=3fdb20368c293dce5c69911f7024183191f86da2;hp=a56971ea06fefd03317874c9214ebccda4794279;hpb=e9788f71fb5a4be6bc69605539b0135f0ba1829a;p=apps%2Fagl-service-can-low-level.git

diff --git a/README.md b/README.md
index a56971ea..77758b83 100644
--- a/README.md
+++ b/README.md
@@ -1,51 +1,55 @@
 # 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 objects, separated by newlines.
-
-There are two valid message types - single valued and evented.
-
-There may not be a 1:1 relationship between input and output signals - i.e. raw
-engine timing CAN signals may be summarized in an "engine performance" metric on
-the abstract side of the interface.
-
-## Single Valued
-
-The expected format of a single valued message is:
+interfaces (e.g. USB or Bluetooth) as JSON or Protocol Buffers (protobuf).
 
-    {"name": "steering_wheel_angle", "value": 45}
+## JSON
 
-## Evented
+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 expected format of an event message is:
+The JSON format is best for most developers, as it is fairly efficient and very
+flexible.
 
-    {"name": "button_event", "value": "up", "event": "pressed"}
+## Binary (Protocol Buffers)
 
-This format is good for something like a button event, where there are two
-discrete pieces of information in the measurement.
+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.
 
-## Raw CAN Message format
+The binary messages are published by the VI using the standard length-delimited
+method (any protobuf library should support this).
 
-An OpenXC vehicle interface may also output raw CAN messages. Each CAN message
-is sent as a JSON object, separated by newlines. The format of each object is:
+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.
 
-    {"bus": 1, "id": 1234, "value": "0x12345678"}
+## 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
 
-**bus** - the numerical identifier of the CAN bus where this message originated,
-  most likely 1 or 2 (for a vehicle interface with 2 CAN controllers).
+For protocol specification visit:
+https://github.com/msgpack/msgpack/blob/master/spec.md
 
-**id** - the CAN message ID
+We are using the following lib:
+https://github.com/camgunz/cmp
 
-**data** - up to 8 bytes of data from the CAN message's payload, represented as
-  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.
+MessagePack provides a binary alternative to ProtoBuf. There are pros & cons to each 
+so you can decide what works best for your project.
 
 ## Trace File Format
 
 An OpenXC vehicle trace file is a plaintext file that contains JSON objects,
-separated by newlines.
+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:
 
@@ -102,11 +106,11 @@ manufacturers may support custom message names.
     * 1Hz, but sent immediately on change
 * transmission_gear_position
     * states: first, second, third, fourth, fifth, sixth, seventh, eighth,
-      reverse, neutral
+      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
+      fourth, fifth, sixth, seventh, eighth, ninth, tenth
     * 1Hz, but sent immediately on change
 * odometer
     * Numerical, km
@@ -142,10 +146,31 @@ manufacturers may support custom message names.
     * 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-2013 Ford Motor Company
+Copyright (c) 2012-2014 Ford Motor Company
 
 Licensed under the BSD license.