network_intelligence

KNX TP Telegram Visualizer

repeat_one Repeat Flag:

adjust Target Address Type:

terminal Command (APCI):

location_on Source Address (Area.Line.Device):
Area (0-15):
Line (0-15):
Device (0-255):

my_location Destination Address:
Main Group (0-31):
Middle Group (0-7):
Group Address (0-255):

route Routing Counter / Hop Count (0-7):

numbers Priority:

swap_vert DPT Type / Payload Length:

check_circle Link Layer Acknowledgement (LL_ACK) Type:

LL_ACK (highest priority on bus wins via CSMA/CA: BUSY > NAK > ACK)

view_stream Byte Construction (Logical vs. Physical)

info

TP Bus format vs. cEMI format

This visualizer shows the raw TP bus-side telegram — the bytes that physically appear on the twisted-pair cable. ETS Bus Monitor displays the cEMI format, which adds a 2-byte wrapper (Message Code + AddIL) at the front, and splits the single routing byte (AT|HC|L) into two separate fields: Control Field 2 (AT + HC) and the L octet (payload length). The bytes after those fields are identical in both formats.

Logical Bits: As processed in software — shown MSB to LSB.
Physical Bits: Actual serial character on the bus: Start-bit '0' | Data LSB→MSB | Even Parity | Stop-bit '1'.

Start bit (always 0)

Data bits (D0–D7, LSB first)

Even parity bit

Stop bit (always 1)

Telegram bits

LL Acknowledgement character

bolt KNX TP1 Signal Shape

KNX TP1 uses baseband transmission at 9600 bit/s (104 µs per bit). The bus voltage is normally held at approximately 29 V DC by the power supply.

A logical 1 is a passive signal — the bus voltage remains steady at the DC level.
A logical 0 is an active signal — the bus voltage drops by 5–10 V for approximately 35 µs (t_active), then the integrated choke in the power supply quickly restores the voltage, causing a brief overshoot above the DC level before settling.

Because logical '0' is the active dominant state, multiple devices transmitting simultaneously will have their '0' bits "win" over '1' bits on the shared medium — this is the basis of CSMA/CA collision avoidance.

timer Timing Information

Total Serial Characters: …

Total Bits Transmitted: …

Telegram Transmission Time: …

T2 Pause (after telegram): 1.560 ms — fixed: 15 bit-periods × 104 µs, per KNX TP1 spec

LL Acknowledgement: (waiting for generation…)

Bus Idle Time T3 (priority-dependent): …

Total Telegram Cycle Time: …

account_tree Telegram Structure

compare_arrows

TP Bus byte layout (left) vs. cEMI byte layout (right — as seen in ETS Bus Monitor)

On the bus:


              Ctrl — Control field: frame type, repeat flag, priority, ACK request flag
              Src H / Src L — Source Address High / Low: the sender's individual address (Area.Line.Device)
              Dest H / Dest L — Destination Address High / Low: group address or individual address of the target
              Routing (AT|HC|L) — A single byte packing three fields: Address Type (group or individual), Hop Count (routing counter, max 6), and L (payload length index)
              APDU — Application Protocol Data Unit: contains TPCI (transport control), APCI (application command, e.g. GroupValueWrite) and the actual data
              
              Checksum — Inverted XOR of all preceding bytes; a Link Layer telegram-integrity check. The Physical Layer handles per-character even parity separately.

In cEMI:


            
              MC — Message Code: indicates direction (0x29 = received from bus, 0x2E = sent to bus) and message type
              AddIL — Additional Information Length: number of extra info bytes that follow; always 0x00 for TP and IP
              Ctrl1 — Control Field 1: same content as the TP "Ctrl" byte above
              Ctrl2 (AT|HC) — Control Field 2: splits out the Address Type and Hop Count from the TP routing byte into their own field
              Src H / Src L — Same as TP: sender's individual address
              Dest H / Dest L — Same as TP: destination address
              L — Length: the payload length index, split out from the TP routing byte into its own byte
              APDU — Same as TP: transport control + application command + data

The key takeaway:


            
              cEMI adds MC + AddIL at the front, and breaks the single TP routing byte into two separate fields (Ctrl2 and L). Everything from Src H onwards is functionally identical. The checksum byte is not present in cEMI — error detection is handled at a higher level there.

menu_book Header (6 bytes, TP bus)
Byte 0	Control Field (FT \| R \| SB \| Priority \| A \| E)
Byte 1–2	Source Address (Area.Line.Device)
Byte 3–4	Destination Address (Group or Individual)
Byte 5	Routing byte: AT(1) \| HC(3) \| L(4) ⚠ In cEMI this is split into Control Field 2 (AT+HC) and a separate L octet

inventory_2 Payload (APDU)
Byte 6–7	TPCI + APCI + small data (min. 2 bytes)
Byte 8+	Additional payload bytes (DPT-dependent)

verified_user Checksum (1 byte, Link Layer)
Last Byte	Checksum = NOT(XOR of all preceding bytes) Link Layer telegram-integrity check. Not present in cEMI. (Per-character parity is a separate Physical Layer check.)

check_circle LL Acknowledgement (1 byte)
LL_ACK	0xCC — Positive; sender does not repeat
LL_NAK	0x0C — Negative; sender repeats up to 3×
LL_BUSY	0xC0 — Busy; sender repeats up to 3×
Priority	BUSY > NAK > ACK — in multicast, the highest-priority ACK wins via CSMA/CA