CANraw Mode Protocol for the OOBD Firmware

This memo provides information about how to read CANraw data through the OOBD firmware. Distribution of this memo is unlimited.

Copyright (C) OOBD Team (2013). All Rights Reserved.

The CAN Raw mode supports two features:

• sending complex CAN Frame sequences onto the bus
• dumps received frames to the serial port

(example for HS-CAN setup)

Select the CANraw mode protocol

p 1 1 0 0

This activates the CANraw mode protocol, clears the internal PID list and sets the CAN bus into “invisible listen” mode

Select the HS-CAN interface

p 8 4 0

Select HS-CAN bus speed to 500kbit/s (for other bitrates please have a look to the firmware syntax here: The OOBD Firmware Syntax)

p 8 3 3

Set CAN-Transceiver to normal operating mode

p 8 2 3

Set CAN filter Start address

p 8 10 1 $000

Set CAN filter mask (here: all frames $000 - $7FF are enabled)

p 8 11 1 $000

Activate CANraw listen mode

p 7 1 x

where x is one of the output formats of the listen command.

Received CAN Frames will be immediately dumped on the serial output. See the chapter Example for more details.

No configuration

You can send your data, as usual formatted as hexadecimal coded string

 00112233445566.....

The input buffers covers maximal 4095 bytes, which should be sufficient for quite complex CAN telegram sequences.

The OOBD CAN raw format does not only allow single CAN frames, it can also send (if necessary) several telegrams in one go. To do this, the data format is as follow:

The data consists of one or more blocks:

Block_1 [Block_2 .. Block_n]

Each block consists of the following Byte sequence:

CAN-ID_Byte3 (MSB) CAN-ID_Byte2 CAN-ID_Byte1 CAN-ID_Byte0 (LSB)  Nr_Of_Bytes (1-8) Data_Byte_1 .. Data_Byte_nr_of_Bytes Delay_until_next_Frame (x10ms)

so first comes 4 bytes of CAN-ID, then the number of Bytes in that frame, then the Bytes of that frame and finally a delay (as multiplier of 10 ms), how long it should be wait until the next frame of this sequence will be send. When setting delay to 0, all frames will be send in one go.

The number of Bytes must be equal to the data bytes given.

Following the scheme above, there can be so much blocks send in one go as fit into the input buffer of 4095 bytes.

The whole sequence is only sent once. For repetition, the application need to raise the command again.

explain errors

Depending on the parameter x given at the listen format p 7 1 x. the dongle dumps the received frames in different formats (where x=0 means disable listen outputs):

When having x=1, the output is like this

# 170943 0x1f6  0x0  8  00  00  01  49  00  03  00  0a
# 170943 0x91  0x0  7  2e  f4  6f  12  ef  00  00
# 170944 0x2fd  0x0  6  00  e5  e2  00  2e  f0

When having x=2, the output is like 1, but to have higher output performance (if needed), this output is already made in the CAN service routine.

With x=3, the output comes also straight out of the CAN Interrupt service routine, having the so called Lawicel or SLCAN format:

T000007e1801a1a2a3a4a5a6a7deab
T000007e247202700000000000e293
T000007e381010323334353637e67b
T000007e081112131415161718ea63
T000007e1802b1b2b300000000ee4b
T000007e3821363738393a3b3cf233

Which has the following format for 11-bit CAN Identifier

tiiindddddddddddddddd[ssss]\r

or

Tiiiiiiiindddddddddddddddd[ssss]\r

for 29 bit CANIDs, where the meaning is

With x=4 the output is in a binary format for highest throughput. This binary format is unique to OOBD and not supported by other software (yet).

All values are directly transferred in their binary representation, except the value 0xFF (255). If a 0xFF appears in the bytestream, it's written as a sequence of two 0xFF.

On the other hand the 0xFF is used as Sync-Byte, which can optionally mark the start of a frame sequence. Please notice that this Sync-Byte is not mandatory for each frame sequence and might only be sent each few frames to allow the receiving software to sync to the byte stream.

As the Sync Byte is always followed by the Info Byte, which MSB is always set to 0, a sync byte can always be identified.

So a frame sequence consists of

Sending frames:

This RFC raises security issues. Sending frames on the bus might create unexpected reactions .

Steffen Koehler

Phone: +49 172 410 35 98

EMail:steffen@koehlers.de

Copyright (C) OOBD Team (2012). All Rights Reserved.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the OOBD Team organizations, except as needed for the purpose of developing standards in which case the procedures for copyrights defined in the Standards process must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by the OOBD Team or its successors or assigns.

This document and the information contained herein is provided on an “AS IS” basis and THE OOBD TEAM DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.“ Relation to other RFCs

The OOBD-RFC announcements are distributed via the oobd-commit-messages@googlegroups.com mailing list.

To join (or quit) the list goto https://groups.google.com/forum/?hl=de&fromgroups=#!forum/oobd-commit-messages