We continue our discussion of the CEC functionality in HDMI for Installment 025.  Before we dive into CEC though, Ian spends a little time enlightening us to his adventures with MyDevices and a couple of other applications for interacting with devices and services based on UPnP technologies/DLNA from his cell phone.


Direct Download  Subscribe via RSS  Subscribe via iTunes  Subscribe with Zune

There has been a lot of confusion regarding CEC, proprietary implementations (cross-vendor compatibility), and interoperability.  Fortunately, there finally is a trend with many of the newer products to work across different vendors’ implementations.  It still takes some sort of UI to set the CEC relationships up initially and certain vendors do a better job at that than others, but they are improving all of the time.  My view is that we finally are starting to see a workable cross-product CEC solution from several vendors which actually lives up to the original vision conceived by the HDMI founders.

We do get lost a little bit with the internals of how CEC addressing works (and may even confuse many listeners).  Sorry about that – how CEC really functions is a difficult topic to try to summarize.  Fortunately, it is not something that most custom integrators need to worry about, although it is good to understand the concepts behind it because it is a key piece of how CEC and HDMI work in general.  The basics of it are included here for clarification.  The main concept to grasp is that CEC affords the “macro-like” usage (one touch) scenarios we described in the previous Installment (024).  Those scenarios are based on communicating with device types through their physical CEC addresses while using their logical addresses for communicating with the individual devices themselves.

In other words, the CEC usage scenario functionality we discussed previously deals with a hierarchy of HDMI-based device types.  Each device type has a specific physical address assigned to it.  At first, this seems a bit limiting in practice, but the following device type list does encompass all of the major types of A/V devices in a cluster.  It does induce constraints in very large HDMI-based implementations, so it is important to take this into account when looking at large HDMI Matrix Switches and distribution platforms.



     0             TV

     1             Recording Device 1

     2             Recording Device 2

     3             STB1

     4             DVD1

     5             Audio System

     6             STB2

     7             STB3

     8             DVD2

     9             Recording Device 3

     10           Reserved

     11           Reserved

     12           Reserved

     13           Reserved

     14           Free Use

     15           Unregistered (as initiator address)

                    Broadcast (as destination address)


     • CEC devices have both physical and logical addresses. Normally, upon each hot-plug, each CEC source obtains a physical address by reading the EDID of the sink it is attached to.

     • For CEC to be able to address specific physical devices and control switches, all devices have a physical address. CEC device addressing and connectivity is negotiated whenever a new device is added to an HDMI cluster. The physical address discovery process uses only the DDC/EDID mechanism and must apply to all HDMI Sinks and Repeaters, not just the CEC-capable devices themselves.

     • The CEC line is directly connected to all nodes on the network. After discovering their own physical address, the CEC devices transmit their physical and logical addresses to all other devices, thus allowing any device to create a map of the network.

     • The physical address of each CEC device is expressed as four numbers and indicates where it is relative to the “root” display (TV), whose address is always fixed at  As an example, the first STB in the system is always given the logical address 3 (as seen above).

          – For example, a source attached to input #1 of the “root” display (TV), will have a physical address of

     • Each CEC device also obtains a logical address – reflecting its product type – by negotiating with other CEC devices in the system.


     • The physical address of each node is determined through the physical address discovery process. This process is dynamic in that it automatically adjusts physical addresses as required when devices are physically or electrically added or removed from the device tree.

     • All Sinks and Repeaters perform the steps of physical address discovery and propagation, even if those devices are not CEC-capable. Sources are not required to determine their own physical address unless they are CEC-capable.

     • A Sink or a Repeater that is acting as the CEC root device will generate its own physical address: A Source or a Repeater reads its physical address from the EDID of the connected Sink.

     • The CEC line may be connected to only one HDMI output so a device with multiple HDMI outputs will read its physical address from the EDID on the CEC-connected output. Each Sink and Repeater is responsible for generating the physical address of all Source devices connected to that device by appending a port number onto its own physical address and placing that value in the EDID for that port. The Source Address Field of the HDMI Vendor Specific Data Block (VSDB) is used for this purpose.


     • Each device appearing on the control signal line (CEC buss) has a unique logical address. This address defines a device type as well as being a unique identifier.

     • If a physical device contains the functions of more than one logical device, then it should take the logical addresses for each of those logical devices. A device may declare the functionality of another device by using a different logical address.

          –For example a recordable DVD device may take the address 4 or 8 to expose only the functionality of a standard DVD device.


     • A logical address only is allocated when a device has a valid physical address (i.e. not F.F.F.F).  At all other times, a device takes the ‘Unregistered’ logical address (15).

     • Only the device at physical address may take the logical address of a TV (0). A TV at any other physical address should take the ‘Free Use’ (14) address. If address 14 already is allocated, it takes the ‘Unregistered’ address (15).

     • Reserved addresses currently are not used and are reserved for future extensions to the specification.

     • Where more than one possible logical address is available for the given device type (i.e. STB1, STB2, etc.), an address allocation procedure is carried out by a newly connected device. The device takes the first allocated address and sends a polling message to the same address (STB1 to STB1). If the polling message is not acknowledged, then the device stops the procedure and retains that address.

     • If the first address is acknowledged, then the device takes the next address and repeats the process (STB2 to STB2). Again, if the message is not acknowledged, the device keeps that address.

     • This procedure continues until all possible ‘type specific’ addresses have been checked. If no ‘type specific’ addresses are available, the device takes the unregistered address (15).

     • A device may lose its logical address when it is disconnected or switched off. However, it may remember its previous logical address so that the next time it is reconnected, it can begin the polling process at its previous logical address.  It then tries each other allowable logical address in sequence before taking the unregistered address.

          – For example if a STB that was previously allocated address STB2 is reconnected, it would poll STB2, STB3, and STB1 before taking the unregistered address.

     • If a device loses its physical address at any time (if it is unplugged), then its logical address shall be set to unregistered (15).


• To allow for extensions to the protocol in future releases of the specification, the current opcodes and parameters can be extended by adding further parameters onto them. If an older CEC node receives a message with more operands than expected, it should ACK the additional operands and simply ignore unknown ones, thus allowing extensions to already existing commands.

• For entirely new commands, new opcodes can be allocated. For entirely new device types, new standardized addresses may be allocated.


     • CEC allows a variety of usage scenarios to take occur automatically if the equipment supports it.

     • There is a limit of ten (10) devices total in a CEC/HDMI hierarchy (which is not discussed much by any of the vendors).

          – This limit partially is dependent upon the time it takes to renew the HDCP keys

          – There also may be an additional limit on the number of HDCP Key Registers in specific devices in the chain

     • HDMI Matrix Switches and CEC addressing are critical factors in your purchasing criteria and should not be overlooked when evaluating specifications.

CEC has a lot of potential.  It seems to have gotten a bad rap early on because most vendors only supported their own products.  That is changing.  We definitely are seeing a trend in the marketplace for devices to leverage the capabilities of a CEC backbone for command and control.  We hope that trend continues, because it is one of those underused features of HDMI that really gives it an edge in system designs and implementations.


One thought on “More CEC and a Little 3-D – Installment 025”
  1. Hello!
    Sorry to comment that late, but I just recently found your podcast.
    Although we set a few errors of your podcast straight here in the show notes, I would really like to mention, that a few statements were very misleading. Especially were you talk about CEC and matrix switchers.
    Many of the shortcomings of CEC are based on the simple fact, that CEC was never intended for multi-display systems. Without kicking most of the spec it is also not easy to get matrix switcher support (multiple outputs, multiple displays) into the spec.
    After designing the probably most extensive CEC implementation for control systems (Crestron to be specific) I felt the pain and learned a lot. There are dramatically less real incompatibilities in CEC than people are claiming to be. Most of them in fact relate to the “it does not work as I want it to work and therefore it must be a bug”. I could give you numerous examples.
    Long story short: CEC is indeed cool but you have to go the extra mile to do it right. Otherwise you and especially the end user will be burned badly.

Leave a Reply