0

I have a first generation chromecast going to an old VGA display (eMachines LE1987) through an HDMI->VGA adapter. The cast home screen shows up no problem, but when I start a cast, the screen shows noise snow and the audio is just digital pops for a minute or two. After a while, the cast suddenly shows up fine and lasts until switching to a different app to cast. Googling, I see that chromecast wouldn't be expected to work through an adapter to VGA because HDMI is encrypted to prevent copying (HDCP), and both sides have to be licensed to decode the signal. But if that is the problem I'm having, I wouldn't expect it to work at all. Is HDCP in fact my problem? If so, why does it work after a few minutes? And is there any way to eliminate or shorten the wait?

  • It's probably that the Chromecast isn't quite outputting enough power for the conversion electronics in the adaptor and it takes time to charge whatever bulk capacitance is used to smooth the input supply. HDMI to VGA requires active electronics and so needs to get power from somewhere. – Mokubai Jan 7 at 7:59
  • @Mokubai - interesting, but it's plugged in to power continuously, and shows the home page right away. it's only when starting a cast or switching to a different app to cast that the problem occurs. is that consistent with your idea? why would switching which app is casting discharge the caps? – user1441998 Jan 7 at 8:18
  • and why wouldn't HDCP be the problem? as far as i can tell, no HDMI->VGA adapter should ever work because the VGA side isn't going to know how to decrypt anything... – user1441998 Jan 7 at 8:20
  • HDCP doesn't have to be enabled all the time and for signals that do not need to be protected HDMI is allowed to fall back to an unencrypted signal for example for use with DVI converters or old TVs. It is possible that playing particular video or starting a cast triggers a negotiation on the chromecast output that tries to push the TV into an encrypted state. That could drop a dataline that is used for power until the Chromecast decides it has failed and reverts to "normal" unencrypted signals – Mokubai Jan 7 at 8:30
  • @Mokubai - ok, i could buy that... can you think of any way to test the theory? would any docs touch on this? or any way to reduce the wait for the unencrypted state? would a higher amperage usb power adapter help? – user1441998 Jan 7 at 9:58

Your Answer

By clicking "Post Your Answer", you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.