Differences

This shows you the differences between two versions of the page.

--- doc:rfc_canraw-mode [2014/03/02 06:47] – created admin
+++ doc:rfc_canraw-mode [2016/10/30 09:22] (current) – [Initialization] admin
@@ Line 40: / Line 40: @@
   p 8 4 0
-Select HS-CAN bus speed to 500kbit/s (for other bitrates please have a look to the firmware syntax here: [[brokenlink|The OOBD Firmware Syntax]])
+Select HS-CAN bus speed to 500kbit/s (for other bitrates please have a look to the firmware syntax here: [[doc:hw_commands|The OOBD Firmware Syntax]])
   p 8 3 3
@@ Line 58: / Line 58: @@
 Activate CANraw listen mode
-  p 7 1 1
+  p 7 1 x
+where x is one of the output formats of the listen command.
-Hint:
+Received CAN Frames will be immediately dumped on the serial output. See the chapter Example for more details.
-If there are already CAN-Messages received on the HS-CAN interface they will be directly transmitted from the firmware to the serial Bluetooth interface so that they are directly accessible by any application (i.e. OOBD-Android). See the chapter Example for more details.
 ==== Configuration ====
@@ Line 80: / Line 80: @@
-The OOBD CAN raw format does not only allow single CAN frames, it can also send (if necessary) quite long telegram sequences. To do this, the data format is as follow:
+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:
@@ Line 98: / Line 98: @@
 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.
@@ Line 107: / Line 110: @@
 ==== Examples ====
-receiving frames:
+=== Receiving Frames: ===
+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):
+== Vector Style Output (1) ==
+When having x=1, the output is like this
   # 170943 0x1f6  0x0  8  00  00  01  49  00  03  00  0a
@@ Line 113: / Line 123: @@
   # 170944 0x2fd  0x0  6  00  e5  e2  00  2e  f0
-FIXME Sending frames:
+== Vector Style Output from ISR (2) ==
+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.
+== Lawicel Output from ISR (3) ==
+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
+^ Field name  ^ Length (Bytes)  ^ Meaning ^
+|    T / t    |      1          | T= 29 bit CAN ID, t= 11 bit CAN ID |
+|    i        |      2 / 4      | CAN ID either as 2 bytes (=11 bit) or 4 Bytes (=29 bit) |
+|    n        |      1          | DLC (Number of Bytes) in Hex Format ("0".."8") |
+|    d        |     0.. 8       | 0-8 Data Bytes in Hexadecimal writing |
+|    s        |      2          | optional timestamp in hexadecimal writing (0..65535 ms) |
+== Binary Output from ISR (4) ==
+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
+^ Field name  ^ Length (Bytes)  ^ Meaning ^
+|    SB    |      1          | Sync Byte (SB), Value 0xFF, **optional** |
+|    IB    |      1          | Bit 7 (MSB)=0 \\ Bit 6 = Extended CAN-ID \\ Bit 4-5 Errorflags \\ Bit 0-3 DLC |
+|    TS    |      2          | Time Stamp (0..65535 ms) |
+|    ID    |      2 / 4      | Extended / Normal CAN ID |
+|    Data    |    0..8       | Data Bytes |
+FIXME Sending frames:
 ===== Implementation Details =====