EDIT: I was partially correct. It seems Voyager can transmit at up to 1.4 kbps for certain things.[1]

[0]: https://space.stackexchange.com/questions/24338/how-to-calcu...

[1]: https://voyager.jpl.nasa.gov/mission/spacecraft/

https://voyager.jpl.nasa.gov/mission/spacecraft/

(Asked in the spirit of curiosity; I'm ignorant of radio physics).

The uplink and downlink are in different frequency bands, S-band (2-4ghz) for uplink and X-band (8-12ghz) for downlink and have different amounts of radio frequency bandwidth allocated.

Additionally, Voyager's High-gain antenna has a much narrower beamwidth in X-band at 0.5°, compared to 2.3° for S-band, though I have no idea if that's a factor.

The first is that the downlink is at a higher frequency (X-band, 8.4 GHz) so there is more available bandwidth and the beamwidth of the antenna is tighter at a higher frequency (i.e. the power is more focused). The uplink is at 2.3 GHz, but part of the advantage of the larger beamwidth is that you are able to command the spacecraft if there is an anomaly and it is the high gain antenna is more offpointed. There is also a low gain omnidirectional S-band antenna in case it is really offpointed.

Although the signals both come through the high gain antenna there are two different feeds for the X-band and S-band. If you take a look at the picture of the antenna on Wikipedia [0] you can see the X-band feed is the prime focus behind the subreflector. The S-band feed is mounted on the subreflector so its not seeing the optimally focused signal (which the lower frequencies are less sensitive to this overall loss of focus for the reasons above).

Generally a lot of spacecraft are designed with a much higher downlink to get science data down, but you only need a pretty small link to get commands up to the spacecraft.

[0] https://en.wikipedia.org/wiki/Voyager_1#Communication_system

https://eyes.nasa.gov/dsn/dsn.html

Of course, this wouldn't help Voyager, but it would help similar modern projects, since we can throw billions more computing power at these kinds of projects, these days.

CEC is much more than that as it allows the use of a single remote instead of two or more, which is super handy; the TV remote sends its commands through the HDMI cable to the active device, so if you switch from TV to an external source like PVR or media center on the TV remote, if that device supports CEC (Kodi on a Raspberry PI does that) you can control it seamlessly through the TV remote. I recently switched my media center from a Raspberry PI 4 to an older (but much faster) unlocked Chromebox whose video chipset doesn't support CEC, so I had to connect an external interface that does USB to CEC conversion. Unfortunately there is only one manufacturer of such interface, which means it's not that cheap. https://www.pulse-eight.com/p/104/usb-hdmi-cec-adapter

- Apple: When you start an Airplay stream on your phone directed at an Apple TV, the Apple TV doesn't send a switch input command.

- Nintendo: The Nintendo Switch switch input command when waking from sleep is unreliable at best.

- Microsoft: Surprisingly the worst offender. The only switch input command it ever sends is when it wakes from user-induced sleep. If you let the console go to sleep on its own, and wake up the controller and press the big Xbox button, it never sends a CEC command.

However, I think that the issue is that CEC support has never been 100% reliable and interoperable. My TV is also made by Sony, which likely helps with compatibility. Probably all these devices work well with some TVs and not others, despite everything claiming to support CEC.

Frankly I find the technology to be a total mess, and there's no way to debug it.

You can disable this in config, but it's all-or-nothing: now the PS5 can't wake the TV at all.

Attempting to report the misbehavior to LG and Sony is like shouting into the void. They don't care, or it's the other entity's problem, or both.

Also my xbox turns on the TV, but that never turns on the speaker bar.

I think it depends on the equipment combination, and its state.

I'm able to send an Airplay stream to my AppleTV and it both turns on my LG television, and switches the input to the AppleTV.

However, if the TV is already on, and I send an Airplay stream to the TV it will not switch the input. Which I think is an OK measure if you have kids or roommates or the TV is in a public setting so that someone might hijack your viewing as a joke or to be annoying. My memory is that this used to be possible with an earlier model AppleTV, or an earlier version of iOS.

That said, ever since I attached a $23 no-name Chinese DVR to another HDMI input on the same LG TV, the AppleTV no longer has the ability to wake or change inputs. Very strange.

In my case, the TV is from 2015.

I know because my wife and I just happened to be in an electronics store when the Pope was visiting the United States in 2015, and it was on all of the televisions.

At the time, we had a 32-inch TV from 2003ish, and when my wife saw the Pope on the 65-inch screen in the store, she immediately grabbed a salesperson and said, "I want to see the Pope like that."

So, in case you've ever wondered if the programming on a TV in a store matters, the answer is "sometimes."

I have almost the opposite problem. Any time I turn on my TV and receiver to use another device (often my Nintendo Switch), the Apple TV somehow wakes up and then switches my receiver's input to itself. (My receiver is my HDMI switcher and has a single HDMI output to my TV.) This is a very annoying problem, and is the only reason I still need to have the receiver's remote nearby.

Another unrelated but incredibly annoying problem I have with this whole setup is that it's essentially impossible to play music through my receiver with my AppleTV without the TV being on. Turning off the TV will, of course, turn off the receiver too.

CEC won't work at all then of course, but it will fix that problem.

I don't have an Apple TV. Does it have a setting to disable CEC?

Oh? My Apple TV 4K (2021) turns on the TV and receiver when I start AirPlay, and the receiver switches the input to the AppleTV if it wasn't already on it. This works whether the TV+receiver were on or off. My TV is a Sharp from ~2013, and the receiver is a Yamaha also from around the same time.

Like if I press it once, the ATV wakes up and usually the TV does, but often showing the wrong source. 5x fast consistently wakes the TV to the right input.

Chromecast with Google TV contains an IR emitter to handle that, and IR is the default not CEC.

https://en.wikipedia.org/wiki/Consumer_Electronics_Control

On the same topic, I once bought a vacuum cleaner on which they wrote on the box « ExtraRangePlus (R) TM: Up to 12m power cable length ». Just why !?

My Apple TV 4K wakes my TV and to the right input with Airplay though!

I don’t know if there are switches capables of turning on and off the TV based on the presence or lack or signal but that could be the ultimate solution to this issue.

I'm surprised that they'd get it wrong though given that they've properly supported the HDMI VRR and ALLM features since the Xbox One X. (AFAIK Sony doesn't have either of those, even on the PS5. And with Nintendo it's surprising they have any CEC support at all)

That seems to be the main use case, but instead the design forces every source to be a universal remote control.

In a dark room, you can still see a dim glow coming from the LCD panel that only goes away if I press the power button on the Samsung remote.

But yes it can do much more: You can program records over CEC! You can directly select broadcast service! (i.e. not just through key presses, but indeed say which channel you want) You can display some message on TV's OSD! You can discover another device's language! You can make audio 0.1% or 0.01% slower (or 1% and 0.1%? I don't remember)

I don't think I've crossed any device that supports any of the command I just mentioned however.

Though "Dispay some message on TV's OSD" from CEC bus would be perfectly on point based on TFA.

While on the page I was curious if the firmware was open source. While writing this and properly articulating the bit about HDMI royalty (and also just now realizing it might need to deal with HDCP... ah) I now realize the question is moot, but I didn't think of any of what while looking at the webpage, so I wondered if it would be interesting to have a cursory poke at the firmware download.

7-Zip (also available as a commandline program as p7zip-full on debian et al) is honestly grossly understated it its capabilities. I didn't feel like remembering how to invoke binwalk so tried `7z x firmware-v7.exe` almost as a bit of a challenge and it actually worked :)

  $ 7z l ~/Downloads/firmware-v7.exe 
  Path = /home/i336/Downloads/firmware-v7.exe
  Name = WEXTRACT.EXE            .MUI
  OS Version = 6.1
  Image Version = 6.1
  Subsystem Version = 5.0
  Subsystem = Windows GUI
  DLL Characteristics = Relocated NX-Compatible TerminalServerAware
  Comment = FileVersion: 9.0.8112.16421
  FileVersion: 9.00.8112.16421 (WIN7_IE9_RTM.110308-0330)
  CompanyName: Microsoft Corporation
  FileDescription: Win32 Cabinet Self-Extractor                                           
  ----
  Path = .rsrc/RCDATA/CABINET
  Type = Cab
  Physical Size = 1348694
  ID = 7086

    Date      Time    Attr         Size   Compressed  Name
  ------------------- ----- ------------ ------------  ------------------------
  2016-04-13 13:05:12 ....A       184800               flash.exe
  2012-08-29 16:19:56 ....A       619536               driver1.exe
  2012-02-21 04:24:52 ....A       816224               driver2.exe
  2012-07-31 15:35:30 ....A          400               flash.cmd
  2012-03-10 11:27:28 ....A        67008               libusb0.dll
  ...

Awesome.

Hmm... what if I do the same to `flash.exe`?

  $ 7z l flash.exe 
  ...
  Linker Version = 10.0
  OS Version = 5.1
  Image Version = 0.0
  Subsystem Version = 5.1
  Subsystem = Windows CUI
  DLL Characteristics = Relocated NX-Compatible TerminalServerAware

     Date      Time    Attr         Size   Compressed  Name
  ------------------- ----- ------------ ------------  ------------------------
  ...
                      .....        67392        67392  .rsrc/RCDATA/101
                      .....         2496         2496  .rsrc/RCDATA/102
  ...
  ------------------- ----- ------------ ------------  ------------------------
  2016-04-13 22:05:07             183568       183568  9 files

Extracting (`7z x ../flash.exe` from an empty subdir) produced newline-less ASCII hex output ("EF19541A19D258B099B877545DE0B65BBBC5602..."), so after a bit of `printf "$(cat 101 | sed 's/../\\x&/g')" > 101.bin` I came up with... nothing.

Binwalk has no idea what it is. Perhaps the start of the files ring bells for some humans?

  $ ls -l
  -rw-r--r-- 1 i336 i336 67392 Apr 13  2016 101
  -rw-r--r-- 1 i336 i336 33696 Apr  1 05:46 101.bin
  -rw-r--r-- 1 i336 i336  2496 Apr 13  2016 102
  -rw-r--r-- 1 i336 i336  1248 Apr  1 05:48 102.bin

  $ xxd 101.bin | head -n 5
  00000000: ef19 541a 19d2 58b0 99b8 7754 5de0 b65b  ..T...X...wT]..[
  00000010: bbc5 6020 54e7 ca9a 1fb7 beca 0a39 95c4  ..` T........9..
  00000020: c876 de8a 4705 19a5 9f03 4c56 5d83 9550  .v..G.....LV]..P
  00000030: f5ad 2930 5f07 9b46 21b1 91a0 d091 4685  ..)0_..F!.....F.
  00000040: 3ada 0ce3 305b 49e1 939e 7384 3c5a 5794  :...0[I...s.<ZW.

  $ xxd 102.bin | head -n 5
  00000000: f3f1 7b55 3f33 cbed 426e 1ab7 5792 4425  ..{U?3..Bn..W.D%
  00000010: 8e75 1566 5597 8183 c1ce 9265 6acf 3b73  .u.fU......ej.;s
  00000020: 1370 47b4 5431 399b f73f 0f6a 6323 3329  .pG.T19..?.jc#3)
  00000030: 0e52 25ad 0530 5d03 9393 bc8c 40c8 f0fb  .R%..0].....@...
  00000040: c63c 7ddb 4d3a cd89 ab4a e6c7 cb2f ab4f  .<}.M:...J.../.O

I've toyed with the idea of replicating its functionality on an Arduino, but ended up just buying the adapter :)

In the end, I'm not sure how doable it is, but it shouldn't be too complex. Licensing is another matter. I'm at a loss as to why GPU makers don't wire it up though.

I incidentally found https://hackaday.io/project/168696-cec2usb while poking around, last updated a couple years ago so probably not available for sale anymore, but open source at least.

  ---
  http://s2.symcb.com0
  http://www.symauth.com/cps0(
  http://www.symauth.com/rpa00
  http://s1.symcb.com/pca3-g5.crl0
  SymantecPKI-1-5670
  Symantec Corporation1
  Symantec Trust Network100.
  Symantec Class 3 SHA256 Code Signing CA
  ---

1: https://www.pulse-eight.com/p/154/intel-nuc-hdmi-cec-adapter

The listed photos are just at the wrong angle to be able to read the chip markings (grr)... but I had a bit of a further poke around, and found a listing for a discontinued internal board for HTPC (!) setups: https://www.pulse-eight.com/p/117/internal-hdmi-cec-adapter

A reasonable bit of eye-strain later I at last identified that I was staring at an AT90USB162-15AU. Here's a reference for the -16AU: https://www.mouser.com/ProductDetail/Microchip-Technology-At...

Huh. 16MHz. That answers that then.

(Now I'm a tad more idly curious why the firmware was unreadable.)

Otherwise you might try binwalk with the --disasm option (you'll need capstone installed for it to work) then it will attempt to search files for assembly for any of wide range of processors (obviously would fail if the firmware is encrypted, but I doubt a cheap product like this would bother). I'll also just briefly say that even though RCDATA is microsoft's recommended way to embed a file into an executable I've seen plenty of software that embeds files in other creative ways, so I wouldn't rule out the possibility that the firmware is somewhere else in the executable, binwalks entropy analysis mode can sometimes work firmware that is otherwise hard to locate.

That being said, I indeed have the feeling that CEC is specifically badly implemented by most people.

I feel like the standard is rather under-specified (or there are things I don't understand), like it's said how some kind of devices are supposed to behave based on some commands, but no explanation as to how other devices are supposed to behave on those commands.

For instance, it is specified that a Player (there are various types of devices in CEC, more on that later) can send an AVR (which is different kind of CEC device, there can only be one in the whole network) volume commands. More specifically, a Player can send an AVR VOL+ and VOL- key presses to change volume. What happens if you send VOL+/VOL- to a TV? That's not specified until 2016 with CEC 2.0. So you can't control volume on most TVs if you don't have an AVR.

The number of "slots" available per device kind is constant: exactly one TV, exactly one AVR three players, 4 tuners, 3 recorders. You have a tvbox, and three game consoles (all shold be Players)? Well someone will have to lie and become a tuner or a recorder, or they won't be allowed on the bus.

Another thing that makes this messy, is that CEC needs to fit in small power budget during suspend. For instance, in Europe, the legal power budget in sleep is 0.5W. This means that your main application processor can't handle CEC in suspend. Usually, this leads to multiple "concurrent" CEC stacks, running in different CPUs, switching from always-on Cortex-M, to full-blown Cortex-A (and then you add Android TV on top of that with its own CEC stack, and you get three CEC stacks co-working together). Often the communication pipeline between those people is pretty light, and going through all those layers, you might end up losing the info of whether the wakeup instruction came from your remote (so you legit want to have the TV wake to you), or from CEC (so you want to let TV decide of the output).

I believe one gigantic factor is that CEC has started very poorly (no matter the reason), and since then, interoperability problem has been considered by most QA as "yeah well, this is life"

Back specifically to your question "I.E. "one touch play" turning on unintended devices in addition to your display and receiver.": This is very very usual. I don't know what the specs say precisely, on the matter, but here's what I witnessed on many TVs (many enough that I expect this to be the standard, but it's possible it's related to what I said earlier about dual-stack):

- Say you have HDMI1 and HDMI3 devices connected, you suspended TV on HDMI1, you wakeup from HDMI 3.

1) On wakeup, TV sends Set Stream Path to the previously selected device. If you suspended your TV on HDMI1, and you're waking up from HDMI 3, TV will start with a Set Stream Path to say "hey, the screen I'm currently displaying is HDMI 1".

2) HDMI1 device listens, and wakes up. In the process of waking up, it needs to tell the TV it is ready with ACTIVE_SOURCE command, so they do.

3) If HDMI3 is in the "clever" range, HDMI3 will send again "Please TV switch to HDMI 3" with ACTIVE_SOURCE

4) Even if HDMI3 isn't in the "clever" range, TV will later send Set Stream Path to HDMI3, because it remembered HDMI3's command to wake up to them, or because of thanks to -3-

5) Everyone's happy, TV's on HDMI 3

6) Message sent in -2- finally manages to reach the bus more than one full second later, because HDMI1 is less aggressive on CEC bus than the other.

... And there you go, TV switches back to HDMI 1.

Fixing this is possible, HDMI 1 "just" needs to cancel -2- when seeing -3- or -4-, but most CEC implementation's send_pkt doesn't include cancellation signals. So, it's possible to make better CEC implementations (though it requires mechanism that are pretty complicated for an embedded world), but I don't think it's possible to make a perfect implementation that will never miss.

At times, I regret DisplayPort not having something comparable (it has data channels, but nothing "as well specified" as CEC for controlling other devices). I think you explained part of the reason. If it were specified, it would require careful consideration, and probably a conformance test suite. I still fully expect manufacturers to try to re-brand it, extend it themselves, and generally botch their software like they end up doing most of the time.

One solution I've always felt would be handy would be for devices to have an option to ignore any CEC commands that would normally cause them to wake. As it is right now, everything is so buggy between my LG TV, Yamaha Reciever, and "players" that I have to disable the feature entirely on either my PS5 or Apple TV in order for things to not go haywire.

This is the kind of post that I come to Hacker News for.

I'm just glad I'm not crazy.

in my experience it doesn't even do that very well. I tried getting a raspberry pi to power off an attached display and support of on/off seems to be hit or miss and specialized.

I suspect it isn't supported because it will commoditizes the device, when manufacturers really want their own protocol that connects only to their own products.

much better sales of acme products if an acme tv can only connect to an acme soundbar and an acme dvd player using acme protocols.

But I can't blame TV manufacturer for not implementing it: When sending vol+/vol- commands, you're already stretching the CEC bus pretty thin, you can't afford to spam the bus more with more commands...