There is a certain warmth that seems to emanate from stereo receivers of the 70s, 80s, and 90s. Despite their large footprint and considerable heft, the soft glow of the indicator lights and solid kerthunk of switches provide a sense of coziness. When [Tom] recently swapped his receiver for a 1970s Pioneer SX-950, he found himself getting up from the couch to adjust the volume when watching TV far too often for his liking. Resolving to do something about it, he added some magic in the form of a motorized volume knob. One of the coolest tricks for stereos was to have a small motor attached to the volume knob so that it could turn the volume up or down via a remote.
The first obstacle came when [Tom] had to forgo the center tap on the potentiometer to get a motorized one. This meant the volume compensation feature would be disabled, which is but a small price to pay for convenience. After scouring the internet, he finally had the part in hand only to discover some troublesome capacitors in the way. The new pot had a rather large motor hanging off the back that the previous one didn’t have. Fortunately, there was a good bit of space between the PCB and the bottom of the chassis, so Tom was able to just flip the capacitors to the underside of the board and bend them on their sides.
The next problem to solve was how to change the volume remotely. IR was considered as well as optical cable control signals. What [Tom] did instead was to implement HDMI CEC (consumer electronics control). CEC was well documented and seemed simple to implement on an ATTINY4313 with the help of a half-H driver. The CEC protocol implemented by [Tom’s] TV seemed to be very sensitive to timing, so an external crystal was used to get more precise timing and additional handshaking was implemented to get the TV to accept the microcontroller as valid. A few fail-safes were added to make sure the motor didn’t burn out if something went wrong with the CEC protocol and a nice enclosure wrapped up the build quite nicely.
We’ve seen CEC implemented before on a PIC 18F87J50, but as a sender of CEC commands not a receiver. [Tom’s] code is available on GitHub and might prove useful if you’re looking to implement CEC on an AVR.
Thanks [Tom] for sending this one in!
Like many of the stories you’ll find on these pages, this one starts with a user being annoyed about their device’s inability to perform a simple task. All [Jay Tavares] wanted was for his Bose Cinemate speakers to turn themselves on and off as needed. It seems like a reasonable enough request, and indeed, is exactly the point of HDMI’s Consumer Electronic Control (CEC) feature. But in this case, it would take a bit of custom hardware to get similar functionality.
Unfortunately, the speakers [Jay] has only support optical audio; so any interoperability with HDMI-CEC (hacked or otherwise) was immediately out the window. Still, he reasoned that he should be able to detect when the TOSLINK audio source is actually active or not, and give the speaker system the appropriate signal to either power on or shut down. You might think this would require some kind of separate stand-alone device, but as it turns out, all the necessary information was available by reverse engineering the connection between the receiver and the subwoofer.
After some investigation, [Jay] found that not only was the content of the TOSLINK audio source being sent over this DB9 cable, but so were the control signals required to turn the system on and off. So he designed a simple pass-through device with an ATtiny85 and a couple passives that latches onto the relevant lines in the cable.
When audio is detected over the optical connection, the MCU will inject the appropriate signals on the control line to simulate the user pressing the “Power” button the remote. When the chip hasn’t detected audio after 10 seconds, it sends the signal to shut the speakers off.
While [Jay] notes he can’t guarantee this works on anything other than the particular Bose Cinemate GS Series II system he has, we’d be willing to bet the concept could be adapted to other models or even brands that use a similar cable to link their principle components. If all else fails, you could always add an ESP8266 to your sound system and control it over WiFi.
Modern home cinema equipment is well-equipped with features for interoperability and convenience, but in practice, competing standards and arcana can make it fall over. Sometimes, you’ve gotta do a little work on your own to glue it all together, and that’s what led [Victor] to develop a little utility of his own.
ChromecastControls is a tool that makes controlling your home cinema easier by improving Chromecast’s integration with the CEC features of HDMI. CEC, or Consumer Electronics Control, is a bidirectional serial bus that is integrated as a part of the HDMI standard. It’s designed to help TVs, audio systems, and other AV hardware to communicate, and allow the user to control an entire home cinema setup with a single remote. Common use cases are TVs that send shutdown commands to attached soundbars when switched off, or Blu-Ray players that switch the TV on to the correct output when the play button is pressed.
[Victor]’s tool allows Chromecast to pass volume commands to surround sound processors, something that normally requires the user to manually adjust their settings with a separate remote. It also sends shutdown commands to the attached TV when Chromecast goes into its idle state, saving energy. It relies on the PyChromecast library to intercept traffic on the network, and thus send the appropriate commands to other hardware. Simply running the code on a Raspberry Pi that’s hooked up to any HDMI port on a relevant device should enable the CEC commands to get through.
It’s a project that you might find handy, particularly if you’re sick of leaving your television on 24 hours a day because Chromecast never bothered to implement a simple CEC command on an idle timeout. CEC hacks have a long history, too – we’ve been covering them as far back as 2010!
HDMI is implemented on just about every piece of sufficiently advanced consumer electronics. You can find it in low-end cellphones, and a single board Linux computer without HDMI is considered crippled. There’s some interesting stuff lurking around in the HDMI spec, and at DEF CON, [Joshua Smith] laid the Consumer Electronics Control (CEC) part of HDMI out on the line, and exposed a few vulnerabilities in this protocol that’s in everything with an HDMI port.
CEC is designed to control multiple devices over an HDMI connection; it allows your TV to be controlled from your set top box, your DVD player from your TV, and passing text from one device to another for an On Screen Display. It’s a 1-wire bidirectional bus with 500bits/second of bandwidth. There are a few open source implementations like libCEC, Android HDMI-CEC, and even an Arduino implementation. The circuit to interface a microcontroller with the single CEC pin is very simple – just a handful of jellybean parts.
[Joshua]’s work is based off a talk by [Andy Davis] from Blackhat 2012 (PDF), but greatly expands on this work. After looking at a ton of devices, [Joshua] was able to find some very cool vulnerabilities in a specific Panasonic TV and a Samsung Blu-ray player.
A certain CEC command directed towards the Panasonic TV sent a command to upload new firmware from an SD card. This is somewhat odd, as you would think firmware would be automagically downloaded from an SD card, just like thousands of other consumer electronics devices. For the Samsung Blu-Ray player, a few memcpy() calls were found to be accessed by CEC commands, but they’re not easily exploitable yet.
As far as vulnerabilities go, [Joshua] has a few ideas. Game consoles and BluRay players are ubiquitous, and the holy grail – setting up a network connection over HDMI Ethernet Channel (HEC) – are the keys to the castle in a device no one would ever think of taking a close look at.
Future work includes a refactor of the current code, and digging into more devices. There are millions of CEC-capable devices out on the market right now, and the CEC commands themselves are not standardized. The only way for HDMI CEC to be a reliable tool is to figure out commands for these devices. It’s a lot of work, but makes for a great call to action to get more people investigating this very interesting and versatile protocol.
[Valkyrie-MT] was frustrated by the inability to control TrueHD audio volume from his computer. That’s because digital audio passes through the cable to the receiver where the volume adjustments are done. This meant that his RF computer remote was no good because the receiver uses an IR remote. He set out to find a way to get around this and ended up working with the Consumer Electronics Control (CEC) protocol.
The CEC protocol is a 1-wire serial bus built into the HDMI standard. The solution he settled up required one solder connection on the motherboard as well as the internal USB translator module seen above. That translator box, called the RainShadow, is a PIC 18F87J50 controlled board that translates incoming commands from the USB connection and sends them out as CEC hex codes. A bit of code writing and [Valkyrie-MT] is in business. You can see in the video after the break that it’s not just controlling audio, he can now control the entire entertainment center including turning on the TV and setting it to the appropriate input.
Continue reading “Adventures In Consumer Electronics Control (CEC)” →