## scangauge Xgauge CAN guide

Example from Norm who designed CAN-View:

   As an example, you want to know the engine RPM, which is OBD2 standard
   PID 0C. So you send 7DF 08 02 01 0C 00 00 00 00 00 00 00 plus the CRC
   and a bit later you get back (from the Prius) 7EA 08 04 41 0C and then
   2 bytes of rpm data (rpm in 1/4 rpm steps)

Packet breakdown, with helpful Xgauge programming hints:

   .--------------------  CAN  ---------------.
  /            .----- ISO15765-2  (OBD-II) --. \
              /                               \
   y   y   -   [*1]  y   y   y   y   y   y   y    used in TXD?
  01  02   -    03  04  05  06  07  08  09  0A    SG RXF offset
  00  08   -    10  18  20  28  30  38  40  48    SG RXD offset (bits)
  07  EA  (08)  04  41  0C  25  7D  xx  yy  zz    sample CAN packet, RPM reply
  \____/   |    |   |   |   |   |   \________/
    |      |    |   |   |   \   |        \------  unused data bytes
    |      |    |   |   \    \--*---------------  RPM (16 bits), an example
    |      |    |   \    \----------------------  PID
    |      |    \    \--------------------------  mode, |0x40 == reply
    |      \     \------------------------------  OBD-II data length (PCI byte)
    \       \-----------------------------------  CAN length, always 8 [*2]
     \------------------------------------------  CAN ID (11 bits, really) [*3]

* Note 1: OBD-II payload begins here, with the Protocol Control Information
    byte usually set to data length.  The PCI [e.g. OBD-II length] is inserted
    by the SG automatically, we do NOT specify it in our TXD.  It is set
    based on the rest of the TXD length [minus the leading two CAN ID bytes].
    On responses, it is counted for purposes of RXF and RXD.  Multi-frame
    responses use this byte as a control flag, thus pushing OBD-II length
    and subsequent data farther out by one.

* Note 2: The encapsulating CAN packets have their own length field,
    generally left set to 8 for OBD-II purposes but can vary for other
    running bus traffic.  With Scangauge we don't worry about it at all.
    Norm's example includes it because he's doing his own raw wire protocol.

* Note 3: CAN IDs are 11 bits, but treated as 2 bytes in the Scangauge.
    [29-bit IDs are not supported yet to our knowledge.] Bit 3 [from LSB as 0]
    of the CAN ID is used for pre-filtering: if it was low in a request, it
    should be high in a response.  Example: to talk specifically to a hybrid
    ECU we send with ID 7E2, and answers come back with ID 7EA from the
    hybrid controller.  The "broadcast" ID that all ECUs listen on is 7DF;
    then any [or all!] can reply.

    If TXD is only two bytes, it enables a "passive" data collector with the
    same bit-3 filtering, but doesn't actually transmit anything and simply
    waits for a packet matching the CAN bit-flip and RXF to appear.

XXX: dunno-yet:  is 7DF treated specially to disable the CAN ID pre-filtering,
as that would violate the "flip the bit" method on getting answers??

Multi-frame data:
For tranmitting data blocks longer than 7 bytes, the ISO15765-2 protocol
allows up to 4096 bytes split into multiple CAN frames.  This is often used
for returning manufacturer-specific diagnostic data in cars.  In the first
frame of the block, the PCI is set to $10 and the TOTAL data length to expect
set in the next byte.  The first chunk of data is assembled into the rest of
this first packet and sent, giving the receiver some of the data and a warning
that more is ready.  The receiver then has to send a Flow Control frame to
confirm that it wants the rest, which starts with $30 and at this point it
gets to limit the transmitter's speed with another byte containing the number
of further packets it can accept.  [Zero should be valid to mean "send all";
most cars we've observed use $07.]  The sender can then send the rest of
the data, subject to the receiver's burst-size offered in the interim
flow-control response.  Successive chunks are sent with a PCI of $2 in the
high nibble and a simple 4-bit sequence number in the low one that simply
keeps wrapping around at 16.

Unfortunately, the Scangauge at code rev 3.15 cannot send the Flow
Control frame as it automatically hijacks the first payload byte to
be the OBD-II length for TXD.

References:
   http://www.elmelectronics.com/DSheets/ELM327DS.pdf
   http://tunertools.com/prodimages/DrewTech/Manuals/PassThru_API-1.pdf
   US Patent 7203580
   http://scangauge.com/support/xgauge.shtml

_H*  090902