9 ms·

Article makes fun of how slow i2c is compared to the super high speed pairs next to it on HDMI plug. Well, please note that there is a bus that is literally a t

by phh 5y ago

Article makes fun of how slow i2c is compared to the super high speed pairs next to it on HDMI plug. Well, please note that there is a bus that is literally a thousand time slower than i2c on that same connector. It's CEC. Contrary to i2c it only occupies one wire rather than two though. CEC, which is used mainly to power TV on/off or switch sources has a whopping bandwidth of 400bps. No missing multiplier. Maximum device name is 16B. If you have a TV, a tvbox and a game console, simply asking the name of those devices can take more than a second. I'm in the process of shortening my product's CEC name, in order to reduce congestion on the bus. Mainline Linux CEC developer jokes that Voyager 1 which is on the other side of solar system, made 40 years prior to CEC, is faster than CEC. Edit: Sorry for the atrocious original formating

colejohnson66 5y ago
Voyager is so far away that it's estimated data rate is only a hundred or so bps.[0] So CEC is actually faster now than Voyager! New Horizons still has the edge with an estimated kilobit/sec. 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-calculate-data-rate-of-voyager-1 https://space.stackexchange.com/questions/24338/how-to-calcu... [1]: https://voyager.jpl.nasa.gov/mission/spacecraft/ https://voyager.jpl.nasa.gov/mission/spacecraft/
- satsuma 5y ago
  well, problem solved then! no need to update cec anymore
- dr_orpheus 5y ago
  Voyager still actually gets up to a whopping 1.4 kbps downlink! (but only 16 bps uplink) https://voyager.jpl.nasa.gov/mission/spacecraft/ https://voyager.jpl.nasa.gov/mission/spacecraft/
  - perihelions 5y ago
    That's a bit confusing; shouldn't it be the other way around? Because they're using the same antennas in both directions, but the power budget on the Earth-transmitting side is much higher. (Asked in the spirit of curiosity; I'm ignorant of radio physics).
    - NikolaNovak 5y ago
      I'm assuming that our ability to computationally aid / resolve signal is far higher than voyager's.
      - jamiek88 5y ago
        Plus receiver size.
        johnwalkr 5y ago
        It’s mainly this and it’s normal for spacecraft (especially in deep space) to have orders of magnitude more datarate on downlink.
      - phire 5y ago
        That's a factor, but I think it's more that there was never a need for large data uplinks to Voyager, while they needed to downlink large amounts of science data. 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.
    - dr_orpheus 5y ago
      There are a couple of factors at play here. 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://en.wikipedia.org/wiki/Voyager_1#Communication_system
- akira2501 5y ago
  Realtime status of the Deep Space Network: https://eyes.nasa.gov/dsn/dsn.html https://eyes.nasa.gov/dsn/dsn.html
- oblio 5y ago
  I guess this would be one of those cases where you'd want to use the most aggressive compression algorithms in the history of mankind, almost regardless of compression/decompression time, because you'd definitely make overall transmission times faster. 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.
babypuncher 5y ago
You sound like you know a lot about the HDMI CEC spec. Do you have any insight as to why CEC implementations are often buggy on so many devices? I.E. "one touch play" turning on unintended devices in addition to your display and receiver.
- deltarholamda 5y ago
  TIL what the hell was happening when I turned on my TV and the receiver usually switches to the wrong device. I'm just glad I'm not crazy.
- phh 5y ago
  First, I have to plead guilty: my own product's CEC still has many "simple" flaws. 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.
squarefoot 5y ago
> CEC, which is used mainly to power TV on/off or switch sources 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 https://www.pulse-eight.com/p/104/usb-hdmi-cec-adapter
- philistine 5y ago
  Some surprising companies have not completely figured out the correct way to use CEC either. - 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.
  - theturtletalks 5y ago
    People reading this, make sure to enable it in settings. Thought my TV didn't have HDMI-CEC, but it was deep in the settings and unchecked by default.
    - ByThyGrace 5y ago
      Some years ago I set to be able to control my smart TV via my laptop. Unfortunately, the graphics card (integrated or discrete) must also support the CEC spec in order to be able to send commands to the TV. Having a HDMI cable is not enough. My laptop did not ship with that requirement.
m463 5y ago
> CEC, which is used mainly to power TV on/off 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.
ziml77 5y ago
I wish they'd made CEC a little more powerful. I like that I can control my AV receiver's volume with the TV remote, but I don't like that I can't see what the volume is actually set to on the TV. Even if I had a receiver that could overlay onto 4K video, that wouldn't help for the cases where I'm feeding audio back from the TV to the receiver.
- phh 5y ago
  It's ""fun"", because there is definitely a CEC command for TV to know AVR's current volume. 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...
anthk 5y ago
I played Slashem and edited files with ed(1) over 600bps. Not bad, but things start to get usable enough at 9600 BPS.

by phh 5y ago

colejohnson66 5y ago

Voyager is so far away that it's estimated data rate is only a hundred or so bps.[0] So CEC is actually faster now than Voyager! New Horizons still has the edge with an estimated kilobit/sec. 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-calculate-data-rate-of-voyager-1 https://space.stackexchange.com/questions/24338/how-to-calcu... [1]: https://voyager.jpl.nasa.gov/mission/spacecraft/ https://voyager.jpl.nasa.gov/mission/spacecraft/

satsuma 5y ago
well, problem solved then! no need to update cec anymore
dr_orpheus 5y ago
Voyager still actually gets up to a whopping 1.4 kbps downlink! (but only 16 bps uplink) https://voyager.jpl.nasa.gov/mission/spacecraft/ https://voyager.jpl.nasa.gov/mission/spacecraft/
- perihelions 5y ago
  That's a bit confusing; shouldn't it be the other way around? Because they're using the same antennas in both directions, but the power budget on the Earth-transmitting side is much higher. (Asked in the spirit of curiosity; I'm ignorant of radio physics).
  - NikolaNovak 5y ago
    I'm assuming that our ability to computationally aid / resolve signal is far higher than voyager's.
    - jamiek88 5y ago
      Plus receiver size.
      - johnwalkr 5y ago
        It’s mainly this and it’s normal for spacecraft (especially in deep space) to have orders of magnitude more datarate on downlink.
    - phire 5y ago
      That's a factor, but I think it's more that there was never a need for large data uplinks to Voyager, while they needed to downlink large amounts of science data. 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.
  - dr_orpheus 5y ago
    There are a couple of factors at play here. 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://en.wikipedia.org/wiki/Voyager_1#Communication_system
akira2501 5y ago
Realtime status of the Deep Space Network: https://eyes.nasa.gov/dsn/dsn.html https://eyes.nasa.gov/dsn/dsn.html
oblio 5y ago
I guess this would be one of those cases where you'd want to use the most aggressive compression algorithms in the history of mankind, almost regardless of compression/decompression time, because you'd definitely make overall transmission times faster. 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.

babypuncher 5y ago

You sound like you know a lot about the HDMI CEC spec. Do you have any insight as to why CEC implementations are often buggy on so many devices? I.E. "one touch play" turning on unintended devices in addition to your display and receiver.

deltarholamda 5y ago
TIL what the hell was happening when I turned on my TV and the receiver usually switches to the wrong device. I'm just glad I'm not crazy.
phh 5y ago
First, I have to plead guilty: my own product's CEC still has many "simple" flaws. 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.

squarefoot 5y ago

> CEC, which is used mainly to power TV on/off or switch sources 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 https://www.pulse-eight.com/p/104/usb-hdmi-cec-adapter

philistine 5y ago
Some surprising companies have not completely figured out the correct way to use CEC either. - 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.
- theturtletalks 5y ago
  People reading this, make sure to enable it in settings. Thought my TV didn't have HDMI-CEC, but it was deep in the settings and unchecked by default.
  - ByThyGrace 5y ago
    Some years ago I set to be able to control my smart TV via my laptop. Unfortunately, the graphics card (integrated or discrete) must also support the CEC spec in order to be able to send commands to the TV. Having a HDMI cable is not enough. My laptop did not ship with that requirement.

m463 5y ago

> CEC, which is used mainly to power TV on/off 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.

ziml77 5y ago

I wish they'd made CEC a little more powerful. I like that I can control my AV receiver's volume with the TV remote, but I don't like that I can't see what the volume is actually set to on the TV. Even if I had a receiver that could overlay onto 4K video, that wouldn't help for the cases where I'm feeding audio back from the TV to the receiver.

phh 5y ago
It's ""fun"", because there is definitely a CEC command for TV to know AVR's current volume. 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...

anthk 5y ago

I played Slashem and edited files with ed(1) over 600bps. Not bad, but things start to get usable enough at 9600 BPS.