Protocol

[H. Blemings]

Here is the first revision of the protocol document, please feel free to
comment.

Cheers,
Hugh

---------------------------------------------------------------------------=
----
 Hugh Blemings                         |
  email : hugh at asi1.anutech.com.au     |  phone : 015 485558 / +61 15 48555=
8
---------------------------------------------------------------------------=
----
             (Proverbs 3:5,6 - Read The Book for further details :)
---------------------------------------------------------------------------=
----

---------8< Clip'n' Save or throw away! 8<-------------

Standard Engine Telemetry Protocol.  This is very much  a
draft!!

Hugh Blemings

Revision 0.1 950411

1.0  Introduction

This  document  aims to encourage the  development  of  a
standard  protocol  for use in the remote  monitoring  of
internal  combustion engines both petrol and diesel.   It
is  hoped  that the protocol will prove useful  for  both
real time monitoring and the transfer of logged real time
data.   It  would  be  desirable to  provide  for  remote
programming capability in such a protocol and  discussion
on this aspect is encouraged.

A  primary  design goal is that of an efficient  protocol
which  will  not  place unnecessarily  large  demands  on
system  resources both in terms of processing  power  and
link bandwidth.  To this end only a rudimentary check sum
system  is  proposed with no provision for re-sending  of
erroneous  data when in real time mode.  It is  suggested
that  in  more  mission critical applications,  a  higher
level  link  protocol could be run over the top  of  this
protocol to provide more comprehensive error control.

With the above aim in mind the proposed protocol normally
makes use of the processors native units for most values,
the  local display or monitoring software is charged with
the  task  of converting the data sent into "real  world"
units.

Finally,  recognising the possibility that  the  protocol
would  be  used  as  an overall telemetry  system  for  a
vehicle,  provision is made for data  to  be  sent  which
strictly  speaking  is not related  to  the  engine,  for
example road speed, brake temperature, gear etc.

2.0  Telemetry Data

It   is   suggested  that  the  following  variables   be
incorporated  as  standard inclusions into  the  protocol
with  auxiliary analogue and digital channels being  made
available.  Please note that this list is based  on  what
has  come  to  mind personally and hence  should  not  be
considered  exhaustive,  I would  add  that  I=92m  not  an
automotive expert by any stretch so some of the suggested
parameters may be a little odd :)

     Engine
     RPM,  Coolant temperature, Oil temperature, Manifold
     Air Pressure, Mass Air Flow, Engine position, Firing
     order,  Ignition advance, Dwell angle, Turbo  Boost,
     Wastegate   status  (open/closed  ?),   Intake   air
     temperature,   intercooler  temperature   (is   this
     relevant),   Clutch   position,   Battery   voltage,
     Alternator current
    =20
     Gearbox/Transfer case
     Current  Gear,  Oil temperature, Transfer  case  oil
     temperature
    =20
     General
     Brake status, Brake temperature, Tyre pressure, Tyre
     temperature,  Outside  air  temperature,  Cabin  air
     temperature  (to  check  if  the  airconditioner  is
     working :)  Road speed, X/Y/Z acceleration

3.0  Protocol Structure

This  section  is  by no means complete or  fully  though
through but...

I  envisage the need for two conceptual operating  modes,
one being real time in which the data sent is assumed  to
be  current at that instant minus transmission  and  data
conversion  delays.  The second mode which should  enmesh
closely  with the protocol established for the real  time
mode  would  essentially add some sort of time  stamp  so
that data can be positioned correctly in the time domain.
This  mode  would be used for situations  where  data  is
logged then downloaded when convenient.

The  protocol would make use of a serial link  running  8
bits, no parity (?) and one stop bit, just like a desktop
PC.   Baud rate need not be specified but it is suggested
somewhere  around 9600 would be standard.  The data  will
be  sent in a binary format.  An ASCII mode might be nice
but   this   may   increase  bandwidth   and   processing
requirements unnecessarily.  Any thoughts ?

Individual  messages, which if enabled are  automatically
sent  when a variable changes, would consist of a  single
byte header and a number (typically 1 or 2) of data bytes
followed by a simple checksum.  A maximum update rate for
each  variable would need to be specified along with  the
ability  to  send a command back to the  remote  unit  to
control  whether a particular parameter is to be sent  or
not.   This  would  allow  a  bad  connection  generating
spurious data to be masked for example.

I have in mind to set the header information up in such a
fashion  as  to  allow efficient message  generation  and
subsequent  decoding.  For example, I would  foresee  all
messages that have one data byte would use a header  byte
less  than  say 0x40, over 0x40 indicates two data  bytes
etc.  More detail will follow soon...

Comments invited!

-------------------
END