Deprecate "translated" and "raw" verbiage.
authorChristopher Peplin <chris.peplin@rhubarbtech.com>
Sun, 21 Sep 2014 21:19:21 +0000 (17:19 -0400)
committerChristopher Peplin <chris.peplin@rhubarbtech.com>
Sun, 21 Sep 2014 21:19:21 +0000 (17:19 -0400)
Partway towards #16 but need to updated the binary format, too.

README.md

index dd5651e..542952d 100644 (file)
--- a/README.md
+++ b/README.md
@@ -40,9 +40,9 @@ to your application. For example:
         }
     }
 
-### Single Valued
+### Simple Vehicle Message
 
-There may not be a 1:1 relationship between input and output signals - i.e. raw
+There may not be a 1:1 relationship between input and output signals - i.e.
 engine timing CAN signals may be summarized in an "engine performance" metric on
 the abstract side of the interface.
 
@@ -50,7 +50,7 @@ The expected format of a single valued message is:
 
     {"name": "steering_wheel_angle", "value": 45}
 
-### Evented
+### Evented Simple Vehicle Message
 
 The expected format of an event message is:
 
@@ -59,7 +59,7 @@ The expected format of an event message is:
 This format is good for something like a button event, where there are two
 discrete pieces of information in the measurement.
 
-### Raw CAN Message format
+### CAN Message
 
 The format for a raw CAN message:
 
@@ -177,7 +177,7 @@ exist in parallel with a recurring request for the same key.
 
 **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
-  normal translated message) with this value in place of `bus`, `id`, `mode` and
+  simple vehicle message) with this value in place of `bus`, `id`, `mode` and
   `pid`.
 
 **multiple_responses** - (optional, false by default) if true, request will stay