VBus Protocol Specification

Published by RESOL - Elektronische Regelungen GmbH.

Main contact: VBus Development Group (EMail: vbus@resol.de)

Revision History
Version Date Author Changes
10 2015-10-20 Daniel Wippermann Added VBus protocol specification 3.0
11 2015-10-26 Daniel Wippermann Added VBus master schematic
12 2016-01-28 Daniel Wippermann Fixed error in "Physical layer" section about "MARK" and "SPACE"
Authors

Introduction

The RESOL VBus is a half-duplex bus system used by RESOL electronic controllers to communicate with each other and – e.g. using a PC interface – with external components.

One module on the bus system is the master, all other modules are slaves.

Physical layer

The VBus physical interface comes in two flavors:

  • a 2-wire connection providing the bus signal and partial power supply over the same wires
  • a 4-wire connection providing separate wire pairs for the bus signal and power supply

The master supplies the bus system with electric energy using a constant current source. This allows partial power supply of slave modules as well.

For the 2-wire connection the maximum current can vary from 35 mA (older products) to 62 mA (newer products) and the maximum votage is capped at approx. 8,2 V.

For the 4-wire connection the maximum current is 35 mA and the maximum voltage is capped at approx. 5,5 V.

During transmission a module pulls the bus voltage to ground level (GND) using a transistor in order to send a logical „0“ (SPACE). To send a logical „1“ (MARK) the bus voltage has to be kept at the specified maximum level.

During reception a module uses an analog comparator to distinguish between the two states MARK and SPACE (see below for details). The voltage difference between MARK and SPACE is used as a hysteresis.

Most slave modules rectify the bus voltage to ensure reverse-polarity protection. Due to the voltage drop over the rectifier diodes the master and slave modules use different trigger voltages for MARK and SPACE detection.

Trigger voltages at the comparator input:

Master Slave
MARK: U >= 3,25 V 2,25 V
SPACE: U <= 3,00 V 2,00 V

Appendix A contains several VBus schematics for both master and slave.

This schemetic is designed for use with a supply voltage of VCCL = 3,3 V. To use a supply voltage of VCCL = 5.0 V the following resistor values have to be adjusted:

R205 R207
3,3 V 820 Ω 1600 Ω
5,0 V 2200 Ω 1600 Ω

The 4-wire connection uses a JST connector with a pitch of 2.00 mm. The pinning is:

VBus Pinning JST

VBus Protocol

For data transmission and reception a UART is used in half-duplex mode with 9600 bits per second, 1 start bit, 8 data bits and one stop bits. Neither parity nor handshakes are used.

1 data byte = 1 start bit + 8 bit data + 1 stop bit = 10 bits must be transmitted to send 1 data byte

Timing for different baud rates:

Baud rate Time per data byte
9600 (default) 1041,67 µs
19200 520,83 µs
38400 260,42 µs
57600 173,61 µs
115200 86,80 µs

Since the VBus is a single-master-system the communication timing is controlled by the master. The master pauses for short moments during the transmission to ensure that all bus-powered slaves have enough time to recharge. In addition to that slaves are only allowed to send data after they have been requested to do so by the master. After a master's request an appropriate time frame is reserved for the answer.

SYNC-Byte

Every VBus data stream starts with a synchronisation byte (SYNC-Byte):

0xAA or 170 decimal

The reception of a SYNC-Byte starts a new data stream. If the current reception was incomplete it will be cancelled and discarded. This happens as well whenever a byte is received that has its MSB (Most Significant Bit) set (its value is greater than 0x7F or 127 decimal). All received bytes up to the next SYNC-Byte are ignored.

Reception is complete if the data stream reaches its announced length without MSB or checksum errors. The data stream is then processed and reception starts with next SYNC-Byte.

Checksums

To detect communication errors the data stream is protected by one or more checksums. The data stream's length and amount of checksums are depending on several factors:

  • protocol version
  • announced amount of payload

Checksums can be calculated using the following C function:

unsigned char VBus_CalcCrc(const unsigned char *Buffer, int Offset, int Length)
{
    unsigned char Crc;
    int i;

    Crc = 0x7F;
    for (i = 0; i < Length; i++) {
        Crc = (Crc - Buffer [Offset + i]) & 0x7F;
    }
    return Crc;
}

Septet-Bytes

During transmission of payload data care must be taken that no byte is transmitted with its MSB set. To ensure this the MSBs of up to seven payload bytes are extracted for the duration of the transmission into an addition MSB collection byte (called „Septet-Byte“) and transmitted separately. The extraction and re-injection are handled by the following C functions:

void VBus_ExtractSeptett(unsigned char *Buffer, int Offset, int Length)
{
    unsigned char Septett;
    int i;

    Septett = 0;
    for (i = 0; i < Length; i++) {
        if (Buffer [Offset + i] & 0x80) {
            Buffer [Offset + i] &= 0x7F;
            Septett |= (1 << i);
        }
    }
    Buffer [Offset + Length] = Septett;
}

void VBus_InjectSeptett(unsigned char *Buffer, int Offset, int Length)
{
    unsigned char Septett;
    int i;

    Septett = Buffer [Offset + Length];
    for (i = 0; i < Length; i++) {
        if (Septett & (1 << i)) {
            Buffer [Offset + i] |= 0x80;
        }
    }
}

A payload data block of four bytes would be transformed like this:

Before After Description
0xE8 0x68 First payload byte, MSB (=1) is extracted to Septet-Bit 0
0x03 0x03 Second payload byte, MSB (=0) is extracted to Septet-Bit 1
0xF4 0x74 Third payload byte, MSB (=1) is extracted to Septet-Bit 2
0x01 0x01 Fourth payload byte, MSB (=0) is extracted to Septet-Bit 3
0x05 Septet-Byte

Beginning of a VBus data stream

The first 6 bytes of a VBus data stream (starting with the SYNC-Byte) share the same structure for all protocol versions:

Offset Description
0 SYNC-Byte (0xAA or 170 decimal)
1 Destination address (low-byte)
2 Destination address (high-byte)
3 Source address (low-byte)
4 Source address (high-byte)
5 Protocol version

Addresses are assigned by RESOL. Every module on the VBus has at least one address. Modules that have an adjustable sub-address use the four least significant bits for that. See VBus Packet List for a list of known addresses.

The remaing data stream structure differs depending on the „Protocol version“ byte. The following values are valid:

Value Description
0x10 or 16 decimal Protocol version 1.0
0x20 or 32 decimal Protocol version 2.0
0x30 or 48 decimal Protocol version 3.0
0x31 or 49 decimal Protocol version 3.1

Protocol version 1.0

VBus data streams of protocol version 1.0 (called „packets“ for short) are used for continous data exchange of measurement, control and balance values between a master and its slaves. Packets start with a 10 byte header that can announce a variable amount frames containing additional payload.

Offset Description
0 SYNC-Byte (0xAA or 170 decimal)
1 Destination address (low-byte)
2 Destination address (high-byte)
3 Source address (low-byte)
4 Source address (high-byte)
5 Protocol version (0x10 or 16 decimal)
6 Command (low-byte)
7 Command (high-byte)
8 Number of payload frames
9 Checksum for offset 1-8

The payload is split into blocks of four bytes and transmitted together with its Septet-Byte and a checksum as a „frame“.

Offset Description
i + 0 First payload byte, MSB is extracted to Septet-Bit 0
i + 1 Second payload byte, MSB is extracted to Septet-Bit 1
i + 2 Third payload byte, MSB is extracted to Septet-Bit 2
i + 3 Fourth payload byte, MSB is extracted to Septet-Bit 3
i + 4 Septet-Byte for offset (i + 0) to (i + 3)
i + 5 Checksum for offset (i + 0) to (i + 4)

The header field „Command“ can be one of the following values:

Command Explanation
0x0100 Packet contains data for destination
0x0200 Packet contains data for destination, answer required
0x0300 Request answer of destination

The contents of the payload is is depending on three header fields:

  • Source address
  • Destination address
  • Command

After the header was received without errors the contents of the payload is known. See VBus Packet List for a list of known packets (address / command combinations).

A short packet may look like this:

Offset Value Description
0 0xAA SYNC-Byte
1 0x11 Destination address (low-byte)
2 0x44 Destination address (high-byte)
3 0x10 Source address (low-byte)
4 0x66 Source address (high-byte)
5 0x10 Protocol version
6 0x00 Command (low-byte)
7 0x02 Command (high-byte)
8 0x01 Number of payload frames
9 0x21 Checksum for offset 1-8
10 0x07 First payload byte
11 0x04 Second payload byte
12 0x0F Third payload byte
13 0x00 Fourth payload byte
14 0x00 Septett for offset 10-13
15 0x65 Checksum for offset 10-14

This packet is sent by module 0x6610 (RESOL Midi Pro) and is directed to module 0x4411 (RESOL HKM1) including command 0x0200 (Packet contains data for destination, answer required). These three components define the payload contents.

Protocol version 2.0

VBus data streams of protocol version 2.0 (called „datagrams“ for short) allow access to all values that can be adjusted using the module's menu system. It's primarily used for remote parameterization.

Each datagram has a length of 16 bytes and allows to access a single data point (adjustable value). Every data point has an ID. IDs are module and version dependant. A complete list of IDs would go far beyond the scope of the document.

Offset Explanation
0 SYNC-Byte (0xAA or 170 decimal)
1 Destination address (low-byte)
2 Destination address (high-byte)
3 Source address (low-byte)
4 Source address (high-byte)
5 Protocol version (0x20 or 32 decimal)
6 Command (low-byte)
7 Command (high-byte)
8 ID of data point (low-byte)
9 ID of data point (high-byte)
10 Value of data point (low-byte)
11 Value of data point
12 Value of data point
13 Value of data point (high-byte)
14 Septet for offset 8-13
15 Checksum for offset 1-14

The header field „Command“ can be one of the following values:

Command Explanation
0x0100 Answer from module with requested value
0x0200 Write value, acknowledgement required
0x0300 Read value, acknowledgement required
0x0400 Write value, acknowledgement required
0x0500 VBus clearance by master module
0x0600 VBus clearance by slave module

In regular intervals the master broadcasts a datagram containing command 0x0500. This allows slave modules to temporarily take over the bus timing. A PC issuing a parameterization has to wait for such a clearance datagram before starting to send datagrams to read or write the master's data points. On completion of the parameterization the PC sends a datagram containing command 0x0600 to return the bus timing control back to the previous master.

Destination Source Command ID Value Description
0x0000 0x7210 0x0500 0 0 Broadcast for clearance
0x7210 0x0020 0x0300 0x1234 0 PC reads value for ID 0x1234
0x0020 0x7210 0x0100 0x1234 750 Master sends value 750 for ID 0x1234
0x7210 0x0020 0x0300 0x1235 0 PC reads value for ID 0x1235
0x0020 0x7210 0x0100 0x3456 12 Master sends value 12 for ID 0x3456
0x7210 0x0020 0x0600 0 0 PC returns bus timing to master

Protocol version 3.x

VBus data streams of protocol version 3.x (called "telegrams" for short) are used to manage and evaluate digital sensors and actors. Telegrams start with a 8 byte header that can annouce a variable amout of additional payload.

Offset Description
0 SYNC-Byte (0xAA or 170 decimal)
1 Destination address (low-byte)
2 Destination address (high-byte)
3 Source address (low-byte)
4 Source address (high-byte)
5 Protocol version (0x30 or 48 decimal)
6 Command
7 Checksum for offset 1-6

The payload is split into blocks of seven bytes and transmitted together with its Septet-Byte and a checksum as a „frame“.

Offset Description
i + 0 First payload byte, MSB is extracted to Septet-Bit 0
i + 1 Second payload byte, MSB is extracted to Septet-Bit 1
i + 2 Third payload byte, MSB is extracted to Septet-Bit 2
i + 3 Fourth payload byte, MSB is extracted to Septet-Bit 3
i + 4 Fifth payload byte, MSB is extracted to Septet-Bit 4
i + 5 Sixth payload byte, MSB is extracted to Septet-Bit 5
i + 6 Seventh payload byte, MSB is extracted to Septet-Bit 6
i + 7 Septet-Byte for offset (i + 0) to (i + 6)
i + 8 Checksum for offset (i + 0) to (i + 7)

Since the "Command" also determines the number of payload frames and their structure, the value of the corresponding header field "Command" contains an indication on how many frames are transmitted after the header, using the following structure:

Bit Description Range
0-4 Command number 0x00 - 0x1F
5-6 Number of payload frames 0 - 3
7 Always 0 N/A

The header field "Command" can have one of the following values:

Value Command number Number of payload frames Description
0x01 0x01 0 Request slave ID type 1
0x02 0x02 0 Request slave ID type 2
0x23 0x03 1 Slave ID response
0x04 0x04 0 Request slave data
0x24 0x04 1 Request slave data with control values
0x25 0x05 1 Slave data response
0x26 0x06 1 Change baud rate
0x27 0x07 1 Change sub address
0x08 0x08 0 Request extended data from slave
0x69 0x09 3 Slave response with extended data

The reserved address space for sensors and actors using VBus protocol version 3.x is 0x2000 - 0x2F7F. The addresses use the following structure:

Bit Description Range
15, 7 Always 0 (MSB) N/A
14-12 Always 2 N/A
11-4 Group address 0-255 (partially)
0-3 Sub address 0 - 15

Different types of sensors and actors each have their own group address. Currently the group address can have one of the following values:

Value Address pattern Description
0 0x2000 Broadcast (all slaves from all groups)
1 0x201? VFD 1 - 20 l/min
2 0x202? VFD 2 - 40 l/min
3 0x203? VFD 2 - 40 l/min (fast)
4 0x204? VFD 5 - 100 l/min
5 0x205? VFD 10 - 200 l/min
6 0x206? RPD 0 - 10 bar
7 0x207? VFD 1 - 12 l/min
16 0x210? FlowCheck 0,5 - 20 l/min
17 0x211? VBus 3 Meteo
18 0x212? Pumpenansteuerung
19 0x213? GIR 7

All slaves have a sub address of 0 after power-up. The VBus master can then assign sub addresses to each of the slaves.

The following table list the possible combinations of destination address and respective slave groups:

Destination address Slave group
0x2000 All slaves with sub address 0
0x2GG0 All slaves with group address GG and sub address 0
0x2GGS The slave with group address GG and sub address S

Adresses between 0x2001 and 0x200F are invalid.

The broadcast address 0x2000 can be used to force all slaves having sub address 0 to process the telegram. Responding slaves have to answer with their respective group address instead (e. g. 0x2010).

Slave detection and sub address assignment

All sensors and actors using VBus protocol version 3.x need to have the following information stored in the device permanently:

  • VBus group address (7 bit)
  • Product identifier (24 bit)
  • Production week (6 bit)
  • Consecutive number (17 bit)

This information is used to detect and configure slaves that are connected to a master.

When the master starts a slave detection cycle it performs the following operations:

  1. (optionally) switches the VBus supply voltage off and on again to reset all slaves to use sub address 0
  2. Sends telegram with command "Request Slave ID type 1" and waits for responses
  3. If a response from 2. was received, assign a sub address to the responding slave and repeat 2.
  4. Sends telegram with command "Request Slave ID type 2" and waits for responses
  5. If a response from 4. was received, assign a sub address to the responding slave and repeat 2.

The telegrams referred to in 2. and 4. can either be broadcasted (to address 0x2000) or group-casted (to address 0x2GG0 where GG is the respective group address). Only slaves that currently have a sub address of 0 and belong to the requested group (if not broadcasted) are allowed to respond to this type of requests.

But since the VBus is a single-master bus only one slave is allowed to answer this request at a time. This is achieved by calculating timeouts based on a slave specific device identifier value derived from the permanently stored values mentioned above.

The slave specific device identifier value and the corresponding timeouts are calculated using:

DeviceIdentifier = ProductionWeek * 2^17 + ConsecutiveNumber
TimeoutType1 = (DeviceIdentifier mod 100) * 8 + 50
TimeoutType2 = ((DeviceIdentifier mod 100) * 8 + ((DeviceIdentifier / 100) mod 100) * 8 + 50

For example: a sensor with the following permanently stored values:

ProductionWeek = 17
ConsecutiveNumber = 116406

calculates the following device identifier and timeout values:

DeviceIdentifier = 17 * 2^17 + 116406 = 2344630
TimeoutType1 = 30 * 8 + 50 = 290 ms
TimeoutType2 = 30 * 8 + 46 * 8 + 50 = 658 ms

If the slave receives a "Request slave ID type 1 / 2" request as a broadcast (to address 0x2000) or group-cast (to address 0x2GG0 where GG is the respective group address) it must wait for the calculated TimeoutType1 / TimeoutType2 respectively. If the slave receives another SYNC-byte during that wait it cancels its outstanding response and waits for another "Request slave ID" request. If no SYNC-byte was received while waiting for the timeout the slave is allowed to send its response.

Commands

Command 0x01 / 0x02: Request slave ID type 1 / 2

The master can send this telegram to a slave (or a group of slaves) to query their slave ID. Depending on the destination address the following slaves may respond:

Destination address Slaves Timeout?
0x2000 All slaves having sub address 0 yes
0x2GG0 All slaves having group address GG and sub address 0 yes
0x2GGS The slave having group address GG and sub address S no

If a timeout is necessary the timeout values for both the slave response and the master's maximum wait timeout depend on the command:

Timeout? Command Slave response timeout Master maximum timeout
yes 0x01 TimeoutType1 1200 ms
yes 0x02 TimeoutType2 2200 ms
no both 0 ms 80 ms

The master's maximum timeout is the period the master has to wait for incoming responses after sending the request.

The request itself has no payload frames. An example telegram looks like this:

Offset Value Description
0 0xAA SYNC-byte
1 0x10 Destination address (low-byte)
2 0x20 Destination addres (high-byte)
3 0x31 Source address (low-byte)
4 0x77 Source address (high-byte)
5 0x30 Protocol version
6 0x01 Command
7 0x76 Checksum
Command 0x23: Slave ID response

The slave sends this telegram as a response to a "Request slave ID type 1 / 2" telegram sent by the master.

Given a slave with the following permanently stored information:

  • VBus group address: 0x2010
  • Product identifier: 888888
  • Production week: 17
  • Consecutive number: 116406

The calculated device identifier is:

DeviceIdentifier = ProductionWeek * 2^17 + ConsecutiveNumber = 17 * 2^17 + 116406 = 2344630

An example telegram looks like this:

Offset Value Description
0 0xAA SYNC-byte
1 0x31 Destination address (low-byte)
2 0x77 Destination addres (high-byte)
3 0x10 Source address (low-byte)
4 0x20 Source address (high-byte)
5 0x30 Protocol version
6 0x23 Command
7 0x54 Checksum
8 0x38 Product identifier (low-byte)
9 0x10 Product identifier
10 0x0D Product identifier (high-byte)
11 0x36 Device identifier (low-byte)
12 0x46 Device identifier
13 0x23 Device identifier (high-byte)
14 0x00 Unused (0)
15 0x1A Frame Septet-Byte
16 0x71 Frame checksum
Command 0x04 / 0x24: Request data from slave

The master send this telegram to request data from the slave and optionally send control values to it.

Depending on the destination address the following slaves may respond:

Destination address Slaves
0x2000 The slave having sub address 0
0x2GG0 The slave having group address GG and sub address 0
0x2GGS The slave having group address GG and sub address S

It must be ensured that only one slave is elegible to respond even if the telegram is send to the boradcast or group-cast address.

An example telegram without control values / payload frames looks like this:

Offset Value Description
0 0xAA SYNC-byte
1 0x10 Destination address (low-byte)
2 0x20 Destination addres (high-byte)
3 0x31 Source address (low-byte)
4 0x77 Source address (high-byte)
5 0x30 Protocol version
6 0x04 Command
7 0x73 Checksum
Command 0x25: Slave data response

The slave sends this telegram in response to a "Request data from slave" telegram sent by the master.

An example telegram looks like this:

Offset Value Description
0 0xAA SYNC-byte
1 0x31 Destination address (low-byte)
2 0x77 Destination addres (high-byte)
3 0x10 Source address (low-byte)
4 0x20 Source address (high-byte)
5 0x30 Protocol version
6 0x25 Command
7 0x52 Checksum
8 0x68 Data
9 0x03 Data
10 0x69 Data
11 0x00 Data
12 0x00 Data
13 0x00 Data
14 0x00 Data
15 0x05 Frame Septet-Byte
16 0x26 Frame checksum
Command 0x26: Change baud rate

The master sends this telegram to prepare changing the baud rate. The following baudrates are supported:

  • 9600 (default)
  • 19200
  • 38400
  • 57600
  • 115200

An example telegram looks like this:

Offset Value Description
0 0xAA SYNC-byte
1 0x31 Destination address (low-byte)
2 0x77 Destination addres (high-byte)
3 0x10 Source address (low-byte)
4 0x20 Source address (high-byte)
5 0x30 Protocol version
6 0x25 Command
7 0x52 Checksum
8 0x00 Baud rate (low-byte)
9 0x42 Baud rate
10 0x01 Baud rate
11 0x00 Baud rate (high-byte)
12 0x00 Unused (0)
13 0x00 Unused (0)
14 0x00 Unused (0)
15 0x02 Frame Septet-Byte
16 0x3A Frame checksum
Command 0x27: Change slave sub address

The master sends this telegram to change the sub address part of the VBus address of a slave. All addressed slave check whether the product and device identifiers match their own and if it does set their sub address to the value at offset 14.

In VBus protocol version 3.0 slaves only needed to support changing the sub address from 0 to something non-zero. Starting with VBus protocol version 3.1 it is possible to change the sub address multiple times without having to switch power supply off and on again.

An example telegram looks like this:

Offset Value Description
0 0xAA SYNC-byte
1 0x10 Destination address (low-byte)
2 0x20 Destination addres (high-byte)
3 0x31 Source address (low-byte)
4 0x77 Source address (high-byte)
5 0x30 Protocol version
6 0x27 Command
7 0x50 Checksum
8 0x38 Product identifier (low-byte)
9 0x10 Product identifier
10 0x0D Product identifier (high-byte)
11 0x36 Device identifier (low-byte)
12 0x46 Device identifier
13 0x23 Device identifier (high-byte)
14 0x01 New sub address
15 0x1A Frame Septet-Byte
16 0x70 Frame checksum
Command 0x08 / 0x28: Request extended data from slave

TBD: for future use in protocol version 3.1

Command 0x69: Slave response with extended data

TBD: for future use in protocol version 3.1

Example telegram flow

The following topology is used in the examples:

  • Slave 1
    • VBus group address: 0x2010
    • Product identifier: 888888
    • Production week: 0
    • Consecutive number: 1023
  • Slave 2
    • VBus group address: 0x2010
    • Product identifier: 888888
    • Production week: 0
    • Consecutive number: 1099
  • Slave 3
    • VBus group address: 0x2020
    • Product identifier: 888889
    • Production week: 0
    • Consecutive number: 1233
  • Slave 4
    • VBus group address: 0x2020
    • Product identifier: 888889
    • Production week: 0
    • Consecutive number: 1333

The time ranges in the column "Time (ms)" represent transmission times for the telegram at 9600 bits per second. The times may vary for other baud rates.

Slave detection (without collision)
Time (ms) Master Slave 1 Slave 2 Slave 3 Slave 4
(t1 + 0)
...
(t1 + 8,4)
Request slave ID type 1
Master => 0x2010
max. timeout = 1200 ms
t1 + 8,4 Timeout = 234 ms Timeout = 842 ms Not addressed Not addressed
(t1 + 242,4)
...
(t1 + 260,2)
Slave ID response
0x2010 => Master
Cancels timeout
t1 + 260,2 Received slave ID
from slave 1
...
(t2 + 0)
...
(t2 + 17,8)
Change sub address
Master => 0x2010
Slave ID 1
t2 + 17,8 Received sub adress
...
(t3 + 0)
...
(t3 + 8,4)
Request slave ID type 1
Master => 0x2010
max. timeout = 1200 ms
t3 + 8,4 Has sub address Timeout = 842 ms Not addressed Not addressed
(t3 + 850,4)
...
(t3 + 868,2)
Slave ID response
0x2010 => Master
t3 + 868,2 Received slave ID
from slave 2
...
(t4 + 0)
...
(t4 + 17,8)
Change sub address
Master => 0x2010
Slave ID 2
t4 + 17,8 Received sub adress
...
(t5 + 0)
...
(t5 + 8,4)
Request slave ID type 1
Master => 0x2010
max. timeout = 1200 ms
t5 + 8,4 Has sub address Has sub address Not addressed Not addressed
t5 + 1208,4 Timeout
...
(t6 + 0)
...
(t6 + 8,4)
Request slave ID type 2
Master => 0x2010
max. timeout = 2200 ms
t6 + 8,4 Has sub address Has sub address Not addressed Not addressed
t6 + 2208,4 Timeout
Slave detection (with collision)
Time (ms) Master Slave 1 Slave 2 Slave 3 Slave 4
(t1 + 0)
...
(t1 + 8,4)
Request slave ID type 1
Master => 0x2020
max. timeout = 1200 ms
t1 + 8,4 Not addressed Not addressed Timeout = 314 ms Timeout = 314 ms
(t1 + 322,4)
...
(t1 + 340,2)
Slave ID response
0x2020 => Master
Slave ID response
0x2020 => Master
t1 + 340,2 Received garbage
from collision
t1 + 1208,4 Timeout
...
(t2 + 0)
...
(t2 + 8,4)
Request slave ID type 2
Master => 0x2020
max. timeout = 2200 ms
t2 + 8,4 Not addressed Not addressed Timeout = 410 ms Timeout = 418 ms
t2 + 418,4
..
t2 + 436,2
Slave ID response
0x2020 => Master
Cancels timeout
t2 + 436,2 Received slave ID
from slave 3
...
(t3 + 0)
...
(t3 + 17,8)
Change sub address
Master => 0x2020
Slave ID 3
t3 + 17,8 Received sub adress
...
(t4 + 0)
...
(t4 + 8,4)
Request slave ID type 1
Master => 0x2020
max. timeout = 1200 ms
t4 + 8,4 Not addressed Not addressed Has sub address Timeout = 314 ms
(t4 + 322,4)
...
(t4 + 340,2)
Slave ID response
0x2020 => Master
t4 + 340,2 Received slave ID
from slave 4
...
(t5 + 0)
...
(t5 + 17,8)
Change sub address
Master => 0x2020
Slave ID 4
t5 + 17,8 Received sub adress
...
(t6 + 0)
...
(t6 + 8,4)
Request slave ID type 1
Master => 0x2020
max. timeout = 1200 ms
t6 + 8,4 Not addressed Not addressed Has sub address Has sub address
t6 + 1208,4 Timeout
...
(t7 + 0)
...
(t7 + 8,4)
Request slave ID type 2
Master => 0x2020
max. timeout = 2200 ms
t7 + 8,4 Not addressed Not addressed Has sub address Has sub address
t7 + 2208,4 Timeout

Appendix A: Schematics

The following schematic shows an example VBus master:

VBus Hardware Master

The following schematics show example VBus slaves:

VBus Hardware Slave VBus Hardware Slave VBus Hardware Slave VBus Hardware Slave