> ## Documentation Index
> Fetch the complete documentation index at: https://docs.oryx.mechatronstudio.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Serial protocols

> Reading a channel's cells as the bits of a frame.

Oryx draws signals with no time and no voltage: a channel is a row of cells and
every cell is high or low. A serial protocol needs nothing more than that —**one
bit per cell**— so reading a frame means reading that row of zeros and ones and
saying what each stretch means.

<Note>
  Protocols are read **in digital mode only**. In analog the control is disabled:
  *"Protocols are read in digital mode"*.
</Note>

## How a frame is written

<Steps>
  <Step title="Split the steps">
    Every **sub-step is one bit**. With the **Division** tool (`D`) the selected
    steps are split into as many bits as you need.
  </Step>

  <Step title="Draw the bits">
    Click each sub-step to set it high or low.
  </Step>

  <Step title="Pick the protocol">
    With the **Protocol** control in the header: None, UART, CAN, I2C or Modbus.
  </Step>

  <Step title="Read the interpretation">
    A band appears under the channel, with one labelled bar per field.
  </Step>
</Steps>

## A full example: sending the letter "A" over UART

Good for getting the hang of the flow. The letter `A` is `0x41`, that is
`01000001` in binary.

<Steps>
  <Step title="Set the protocol to UART">
    The **Protocol** control in the header. Leave the default format: 8 data
    bits, no parity, 1 stop bit, LSB first, idle high.
  </Step>

  <Step title="Work out how many bits you need">
    With that format, one character takes **10 bits**: 1 start + 8 data + 1 stop.
  </Step>

  <Step title="Select a step and split it into 10">
    Click a step, then **Division** (`D`), go up to 10 with `→` and press
    `Enter`. That step now has 10 cells, one per bit.
  </Step>

  <Step title="Draw the bits, left to right">
    * **Bit 1 — start:** low.
    * **Bits 2 to 9 — data, least significant first:** since `A` is `01000001`,
      reversed it reads `1000 0010`.
    * **Bit 10 — stop:** high.
  </Step>

  <Step title="Look at the reading">
    The bars appear under the channel: *Start*, *Data* and *Stop*. Hovering the
    data bar shows `0x41 · 65 · 01000001 · "A"`.
  </Step>
</Steps>

<Tip>
  If the reading is not what you expected, the most common cause is writing the
  data bits the right way round. UART sends the **least significant bit first**, so
  the byte is drawn backwards from how it is written.
</Tip>

## What you see

### The band under the channel

One bar per frame field, with:

* A **short label**: `SOF`, `ID`, `DLC`, `CRC`.
* The **value** written out to read: `0x1A3`, `8`, `FF`.
* A **color according to the role** the field plays.
* On hover, the **long text** explaining what it is.

<Warning>
  While a protocol is being read, **its reading takes the place of the step
  numbers**.
</Warning>

### The colors

The color does not belong to the protocol but to the **role the stretch plays**,
so two different protocols paint alike what is alike: the start is always the
same color, the data always another.

| Family       | What it groups                                   |
| ------------ | ------------------------------------------------ |
| **Start**    | Beginning of the frame                           |
| **Address**  | Who or what is being addressed                   |
| **Control**  | How the frame is put together                    |
| **Data**     | The payload                                      |
| **Check**    | Checks and acknowledgements                      |
| **End**      | End of frame and the silence after it            |
| **Stuffing** | Bits the protocol adds that carry no information |
| **Error**    | Whatever does not add up                         |

### The status box

A summary appears on the channel's name card: how many frames there are and
whether they are all fine —*"3 frames · all OK"*— or how many failed —*"3 frames
· 1 with errors"*. Expand it to see **the full reading**, frame by frame, with
the problems listed.

When the channel has nothing yet, the box explains how to start, with text of
its own for each protocol.

## The four protocols

<CardGroup cols={2}>
  <Card title="UART" icon="arrow-left-right" href="/en/protocols/uart">
    One channel. Configurable character format: data bits, parity, stop bits, bit
    order and idle level.
  </Card>

  <Card title="CAN" icon="car" href="/en/protocols/can">
    One channel. Standard and extended frames, with the CRC checked, stuff bits
    and error flags.
  </Card>

  <Card title="I2C" icon="cable" href="/en/protocols/i2c">
    Two channels per bus: SDA and SCL. Several buses at once.
  </Card>

  <Card title="Modbus" icon="network" href="/en/protocols/modbus">
    RTU, ASCII and TCP, with the function codes and the exceptions translated.
  </Card>
</CardGroup>

## Where they are configured

The **Protocol** control in the header opens the window with every setting. Each
protocol has its own, and they are stored in the browser with the rest of the
configuration.

<Note>
  The protocol settings belong to **the whole application**, not to each mode:
  since they only apply in digital, they do not need to be repeated per mode.
</Note>