eBUS background

eBUS background

This small tutorial is supposed to give you some background on the eBUS and the messages transmitted on it.

Bits on the wire

The eBUS protocol is byte oriented, which means that 8 bits of data are always transmitted in a row without means of interruption. As everything is based on RS232, there might be some start and stop bits on the wire as well, but these are not relevant for understanding the protocol.

Addresses

The eBUS protocol defines 25 different master addresses, 203 pure slave addresses, a broadcast address, and some special values. Each master also has a dedicated slave address which can be found by simply adding 5 to the master address (wrapping at 256, i.e. 255+5 is 4).
Furthermore, there are two special values needed for synchronization and escaping. In total, this makes 256 different values (that's the point where your first "aha!" should be coming :-) ).

"Why exactly 25 masters?" you might think, and that is a very good question. The answer is pretty simple, because this magical number is directly associated with the arbitration.
"What?" - don't worry, it's just an evil technician word. Arbitration is like a small recipe that tells you what to do to make a good cake - or in the eBUS case: how to access the bus in order to send something on it without interrupting another party.
The receipe looks like that:

• wait for a SYNchronisation symbol to appear
• write your own master address
• read the next byte back from the bus
• if that byte is your own master address, you won!
• otherwise: start over again

Bus state

The eBUS mainly has two different states: an idle state (when currently no message is sent), and an active state (when a message transfer is in progress).
In the idle state, a so called SYNchronisation symbol generator repeatedly sends a SYN symbol on the bus in a certain interval. This is necessary for all participants to know, when access to the bus is granted (see the previous chapter).

Send a message

Once a master has successfully gathered access to the bus, it is supposed to immediately send the message. Consequently, a message starts with the master address which is immediately followed by the destination address. The destination can be one of the 25 master addresses, a slave address, or the broadcast address.

Depending on the destination address, the message structure is slightly different.

In the description of the individual message parts below, the following conventions are made:

• lowercase (and bold) stands for relevant data
• UPPERCASE indicates a constant or values that can be calculated from others

Broadcast message

A broadcast message is sent to all devices on the bus and thus there is no direct answer to it. That's why this message is the easiest one. It consists of the following parts:

source_master BROADCAST primary secondary COUNT [data] CRC

The individual parts of the broadcast message are:

1. source_master: the source master address
2. BROADCAST: the destination address (the singular broadcast address)
3. primary: the primary command
4. secondary: the secondary command
5. COUNT: the number of data bytes following
6. data: COUNT data bytes
7. CRC: the CRC of all previous bytes

Master-Master message

A Master-Master message is sent from one master to another. It consists of the same parts as the broadcast message, but adds some further fields:

source_master destination_master primary secondary COUNT [data] CRC - ACK

The individual parts of the master-master message are:

1. source_master: the source master address
2. destination_master: the destination master address
3. primary: the primary command
4. secondary: the secondary command
5. COUNT: the number of data bytes following
6. data: COUNT data bytes
7. CRC: the CRC of all previous bytes
8. ACK: the acknowledge from the destination master

Master-Slave message

The Master-Slave message is the most complicated one, since the addressed slave device is supposed to send a response back on the bus after receiving the master part. It consists of the same parts as the master-master message, but again adds some further fields:

source_master destination_slave primary secondary COUNT [data] CRC - S_ACK S_COUNT [s_data] S_CRC - ACK

The individual parts of the master-slave message are:

1. source_master: the source master address
2. destination_slave: the destination slave address
3. primary: the primary command
4. secondary: the secondary command
5. M_COUNT: the number of data bytes following
6. m_data: M_COUNT data bytes
7. M_CRC: the CRC of all previous bytes
8. S_ACK: the acknowledge from the destination slave
9. S_COUNT: the number of data bytes following (sent by the slave)
10. s_data: S_COUNT data bytes (sent by the slave)
11. S_CRC: the CRC of the slave bytes (sent by the slave)
12. ACK: the acknowledge from the source master

Relevant data

Now when it comes to using the eBUS, the most important question is:
What is actually relevant data?

In the three message types described above, this is easy to recognize by looking at the lower case bold words.
Most of the messages seen on an eBUS environment are usually Master-Slave messages and thus, the relevant data transmitted by each message is this:

1. source_master: the source master address
2. destination_slave: the destination slave address
3. primary: the primary command
4. secondary: the secondary command
5. m_data: master data bytes
6. s_data: slave data bytes

The other two message types basically provide a sub set of these 6 data values.

This list of fields actually also tells you which data is most important (from top to bottom).
The structure of the data bytes of a message is distinguished either by the primary and secondary command alone, or sometimes also by one or both of the two addresses and/or further bytes part of the master data.

Standard messages

The eBUS specification already defines some messages and the structure of the data bytes by using distinct primary and secondary command bytes. Let's have a look at one of them, the identification message which can either be sent as Master-Slave message, or as Broadcast message:

Master-Slave identification message:

1. source_master: the source master address
2. destination_slave: the destination slave address
3. primary: the primary command 07
4. secondary: the secondary command 04
5. m_data: master data bytes (empty)
6. s_data: slave data bytes, supposed to look like this:

• 5*BYTE: device ID (ASCII)
• BCD: software version
• BCD: software revision
• BCD: hardware version
• BCD: hardware revision

Broadcast identification message:

1. source_master: the source master address
2. primary: the primary command 07
3. secondary: the secondary command 04
4. m_data: master data bytes, supposed to look like this:

• 5*BYTE: device ID (ASCII)
• BCD: software version
• BCD: software revision
• BCD: hardware version
• BCD: hardware revision

The Broadcast identification message might be seen from any master attached to the bus e.g. after powering up the bus.

Manufacturer specific extensions

As the primary and secondary command byte implicitly limit the number of possible messages to around 60000, each manufacturer may define it's own messages by using a designated primary command byte specific for each manufacturer.
Some manufacturers chose to include an additional command byte in the master data as to keep a two-byte message ID (i.e. composed of the secondary command and the first master data byte).