If you spend enough time working with KNX, you eventually find yourself staring at the ETS Bus Monitor, trying to decode telegrams. While ETS provides a great high-level view, it doesn't show you the raw electrical reality of the twisted-pair (TP) bus.
To bridge this gap, I built the KNX TP Telegram Visualizer. It is a tool designed to take standard KNX inputs and generate the exact physical bitstream and timing parameters as they would appear on the wire. Here is a look under the hood at how the visualizer works and how it models the KNX TP1 standard.
1. Stripping Away cEMI: Logical vs. Physical
One of the biggest hurdles in understanding KNX telegrams is the difference between cEMI (Common EMI) and raw TP formats. The ETS Bus Monitor displays telegrams in the cEMI format. This format adds a two-byte wrapper (Message Code and AddIL) at the beginning of the frame and splits the routing byte into two separate fields.
My visualizer strips this away to show the raw TP bus-side telegram. It calculates exactly what the hardware transmits:
Logical Bits: The software representation, ordered Most Significant Bit (MSB) to Least Significant Bit (LSB).
Physical Bits: The actual serial character transmitted on the bus. The visualizer accurately constructs this by wrapping the data in a Start-bit ('0'), reversing the payload to transmit LSB first, calculating an Even Parity bit, and appending a Stop-bit ('1').
2. Dynamic Telegram Assembly and Extended Frames
Under the hood, the visualizer dynamically constructs the telegram byte by byte based on the selected Data Point Type (DPT) and addressing parameters.
Header & Payload: It accurately builds the Control Field, Source Address, Destination Address, and the APDU (Application Protocol Data Unit).
Extended Frame Detection: The visualizer automatically detects if the payload exceeds the standard 15-byte limit. If it does, it dynamically shifts to the Extended Frame format by setting the Control Field bit 7 to
0and inserting a dedicated 8-bit Length field.The Hardware Checksum: Because cEMI doesn't include the physical layer checksum, many developers forget it exists. The visualizer calculates this final byte exactly as a KNX transceiver would: by applying a bitwise NOT to the XOR of all preceding bytes.
3. Modeling the Signal Waveform
KNX TP1 uses baseband transmission at 9600 bit/s, meaning each bit takes exactly 104 µs. To make this tangible, the visualizer generates a dynamic SVG waveform of the bitstream.
The waveform accurately models the electrical characteristics of the bus:
Logical '1' (Passive): The bus remains steady at the baseline DC voltage (around 29 V).
Logical '0' (Active): The voltage drops for about 35 µs, followed by an equalization overshoot caused by the power supply's integrated choke.
Because a logical '0' actively pulls the voltage down, it dominates a logical '1' on the bus. This physical reality is exactly how KNX handles CSMA/CA (Carrier Sense Multiple Access with Collision Avoidance) to resolve bus collisions.
4. Precise Timing and Link Layer Acknowledgements
A KNX telegram isn't just a string of data; it is a highly choreographed sequence of timings. The visualizer calculates the entire cycle time, including:
Transmission Time: Calculated based on the total number of physical bits at 104 µs per bit.
T2 Pause: The mandatory waiting period after the telegram, fixed at exactly 1.352 ms (the length of one 13-bit serial character).
LL_ACK (Link Layer Acknowledgement): The visualizer allows you to simulate Positive (0xCC), Negative (0x0C), or Busy (0xC0) responses. It appends this to the waveform, demonstrating how the receiving device acknowledges the frame.
T3 Bus Idle Time: The visualizer dynamically calculates the bus idle time required before the next transmission, which shifts based on whether the message uses System priority (50 bit-periods) or a lower priority (53 bit-periods).
Conclusion
It took me many literations, and right now I am on the version 4. The more I dig deeper into the 50090 standard and official KNX Training Documentation, the more stuff I discover, and more tweaks are made. My future goal would be mapping out every single DPT with different values, just to see what is really happening on the bus, when for example 6-bytes combined value is sending a 4-channel RGBW value to a DALI Gateway?
Kommentarer
Send en kommentar