I’m pretty sure that everyone in the world knows what a KNX USB Interface device is and what it is used for. Ok, maybe not everyone in the world. 🙂 But I’m sure that everyone who is involved in the KNX world knows what a KNX USB Interface device is.

Brief intro for all you newcomers who are just starting out with the KNX. USB Interface device is communication device which you can use to communicate with the KNX network.

In case you are a KNX installer you will be using the USB Interface device to program KNX devices and make your smart KNX network. For software engineers that are developing applications for the KNX installations, you can use USB Interface device to communicate with devices in the KNX network.

In my previous posts I have already covered some topics regarding the KNX USB Interface device. You can check my post on USB Interface device which explains how to use it and communicate with it. There is another post KNX USB Interface device not working which will help you out if you are using Windows 8.1 or later and your USB Interface device is not working.

But in all my previous posts I have covered USB Interface devices from clients perspective. How to use an existing hardware USB Interface device. In this post I want to cover USB Interface device from the server side. What do you need to do and implement in order to create your own USB Interface device.

In order to implement USB Interface device there are couple of components that you need to think about:

• Physical layer
• HID report structure
• BUS Access Server
• EMI Server

Let’s go into more details regarding every of the mentioned components.

Physical layer

Physical layer is responsible for communication (sending and receiving messages) with the KNX network. This is done over Twisted Pair (TP) hardware interface. TP is used in most cases to implement KNX network bus.

There are a lot of chips on the market that implement KNX physical layer. These chips are usually called KNX/EIB Transceivers. KNX/EIB Transceivers have implemented and certified KNX communication stack, and they are ready to be use of the shelf.

I strongly recommend to use one of these KNX/EIB Transceiver chips that can be found on the market. Decision to use existing chip will significantly lower your expenses and shorten your time to market in developing USB Interface device.

For more info on KNX/EIB Transceivers you can check:

• http://www.onsemi.com/PowerSolutions/product.do?id=NCN5120
• http://www.elmos.com/produkte/interface/knxeib-transceiver.html
• http://www.opternus.com/en/siemens/knx-chipset/knx-transceiver-ics-tp-uart-fze1066.html

Every KNX/EIB Transceiver uses some kind of proprietary protocol to communicate with the client. On the other side, KNX/EIB Transceivers support various hardware protocols (UART, SPI …). These and other factors, together with price range, will play an important role while choosing the right KNX/EIB Transceiver for your solution.

HID report structure

Every USB device needs to define one USB device class which will be used with the device. Fragmentation of USB devices into device classes is made by the fact that USB devices have similar data transport requirements and that the devices share a single class driver.

KNX USB Interface device is no exception to this rule. It has to support at least one USB device class. All applications which are communicating with the KNX USB Interface device need to support this USB device class.

KNX association is in control of the KNX specification and software applications which will be used with the USB interface device. This means that they are in control to define which USB device class will be used by KNX USB Interface device.

There are a couple of criteria which was considered when selecting which USB device class to support:

• Only one USB device class will be supported and used by the KNX built tools (ETS and EITT).
• Use well known, standardized and widespread USB device class that has USB host driver available.

With above mentioned criteria in mind, KNX association has chosen to use Human Interface Device (HID) device class. HID class hardware components are available from various manufacturers. HID class uses interrupt  transfer mode. It has a maximum of 64 octets of data in one transfer.

HID class device has two pipes which are used to communicate with the Driver:

• Control pipe
• Interrupt pipe

Table below defines HID device class endpoints.

In the interrupt pipe of the HID device data is transferred in packets. To exchange the information between KNX USB Interface device and the host, KNX association has defined frame format which has to be used. HID report frame structure can be seen in the image bellow.

From the image it is clear that KNX report frame consists of two parts, KNX HID report header and KNX HID report body. Report header contains information regarding the report ID, packet info and data length. Detail information regarding the KNX HID report body can be found on next image.

First part of the report body, KNX USB transfer protocol header is located only in the first packet. It is followed by the EMI frame. If subsequent packets are needed to deliver the complete payload, second, third and every following packet will contain only EMI frame part.

You can check 9_3couplers_1_1AS document from the KNX specification for more information regarding the HID device class or HID report frame structure.

BUS Access Server

BUS Access Server supports discovery and management of the USB Interface device. It supports Device Features messages:

• Device Feature Service Frame
• Device Feature Get Frame
• Device Feature Response Frame
• Device Feature Set Frame

Example of Device Feature frames can be find below (in order they are listed above).

There is a handful of device features which are supported by the BUS Access Server:

• Supported EMI type
• Host Device Descriptor Type 0
• Bus connection status
• KNX Manufacturer Code
• Active EMI type

Supported EMI type

Supported EMI type provides information regarding which types of EMI protocols are supported by the USB Interface device. Possible options are: EMI1, EMI2 and cEMI. USB Interface device can support zero, one or multiple EMI protocols.

Before starting any communication with the USB Interface device, KNX USB access client will check which EMI protocols are supported by the device.

In case when USB Interface device does not support any EMI protocol, client does not have any means to communicate with the USB Interface device and has to drop the communication process.

In case when USB Interface device supports one EMI protocol, client can continue with the communication. Client has to use the one supported EMI protocol to communicate with the KNX device.

In case when USB Interface device supports more than one EMI protocols, KNX USB access client first need to check which EMI protocol is active. Client can choose to change the active EMI protocol of the USB Interface device. When prefered EMI protocol is set to active, client can start communication with the USB Interface device.

Host Device Descriptor Type 0

This feature of the BUS Access Server allows getting the Device Descriptor Type 0 of the USB Interface device. This information is used by the KNX USB access client to choose Local Device Management Procedure which can be used with the USB Interface device.

In plain text, Device Descriptor Type 0 provides information to the client (for example ETS) of the capabilities of the device and how the client should work with the USB Interface device.

Bus connection status

This feature provides information if the USB Interface device has active connection with the KNX network.

If the answer is positive, client can use this device to communicate with the KNX network. Client can proceed with sending and receiving telegrams with the KNX network through this USB Interface device.

If the answer is negative, there is something wrong with the KNX connection and USB Interface device cannot be used to communicate with the KNX network. This means that some debugging is in order to re-establish connection with the KNX network

KNX Manufacturer Code

It is possible that USB KNX HID device has different Manufacturer name and Vendor id, than the actual KNX Manufacturer code or Manufacturer name. This is on the hardware level of the device (HID device level).

KNX Manufacturer Code feature enables easy access to the information about commercial manufacturer of the product (information regarding manufacturer supported by the KNX).

Active EMI type

This feature works together with the Supported EMI Type feature of the USB Interface device.

Active EMI type provides information regarding currently active EMI protocol which can be used to communicate with the USB Interface device. It also provides feature for the KNX USB Device client to change the active EMI type and set the value which is prefered by the client.

When Active EMI type is set, EMI protocol which is supported by the device needs to be selected.

For detail information about all the Device Feature frames or supported Device Features check 9_3couplers_1_1AS document from the KNX specification.

EMI Server

Here is the definition found in the KNX specification: “The EMI server is thought as that functionality in the device that has hardware bus access and allows receiving and sending EMI messages”.

But what does this mean? It means that EMI Server represents layer on top of BUS Access Server. When communication with the USB Interface device is established, USB client uses EMI Server features to communicate with the device.

From the KNX specification it is clear that USB Interface device can support any of the 3 possible EMI protocols. Since you are in control of the specifications for the USB Interface device, you can choose which EMI protocol you want to support.

When choosing the EMI protocol you want to support there are a couple of factors to consider:

• All hardware USB Interface devices I came across support EMI1 protocol. This makes EMI1 protocol good option to support in your USB Interface device.
• Also cEMI protocol makes a good option. It is the newest and most modern protocol, and it should be prefered protocol for new development.

There are a lot of message types which are supported by the EMI Server. I cannot go into details regarding every possible message. I will simply state a couple of them, as an example. For more detail regarding EMI Server messages check the 03_06_03 EMI_IMI v1.1 AS document from the KNX specification.

PC_Set_Value.req, PC_Get_Value.req, PC_Get_Value.con

PC_Set_Value messages are part of the EMI1 and EMI2 protocol. These messages are used to read and write values from memory location in the USB Interface device. PC_Set_Value messages are usually used during initialization of the USB Interface device by the client (for example by ETS application).

m_code : code of the EMI message.

length : number of the data bytes in the EMI message.

Address : memory location which will be accessed to read or write value.

data : byte array which represent value which is read from the device or which will be written to the device.

Important memory locations which have to be supported by USB Interface device you are building are:

• 0x00 0x4E – Mask type
• 0x01 0x09 – PEI_Type expected
• 0x01 0x16 – UsrEEPROM $0116-$01FE (start address of the address table)
• 0x00 0x60 – SystemState
• 0x01 0x17 – UsrEEPROM $0116-$01FE (device physical address)

L_Data.req, L_Data.con and L_Data.ind

L_Data messages are supported by all three EMI protocols. These messages are used during “normal” – telegram communication between client of the USB Interface device and devices in the KNX network.