Investigating the HDMI "Green Screen After a Few Seconds" Problem

[bottletop]

I am convinced this is not the same HDMI issue. The symptom I have observed, and appears to be reported in the other posts quoted in Post 1, does not just "flash" the splash screen – it shows the full duration of the splash screen and goes on to show a second or two of live video before going to green screen. This suggests a systematic deterministic process is at work, rather than something being "broken".

It would be interesting to know whether your example also demonstrates the HDCP pop-up message, or the switching artefacts on operation of VFORMAT.

I may have remembered incorrectly. I have retested it recently and can only get it to reproduce the symptoms you describe on the first post. The HDR starts fine on the loader screen, then blanks out, then displays the live TV for a second or so followed lime green screen. My memory is not as good as it use to be!

Regarding the HDCP message that appears on an analogue connected HDR, yes I get that as well but I think I overlooked it because I followed the text instructions and only used the analogue scart (disconnecting the HDMI) for that troublesome HDR.

To induce the HDCP message I connect the green screen HDR to AV2 (analogue) and HDMI2 (digital), switch TV source to HDMI2 and the HDCP message should appear on AV2.
To get rid of the HDCP message I can leave HDMI2 disconnected, or switch TV to another HDMIx source (doesn't have to be on, wait 1-2 seconds), then switch TV back to AV2. Once I change channels on the HDR the HDCP message should disappear. This ties in with your theory that it follows an HDMI sync issue.

Note these channels seem to temporarily hide/mask the HDCP message

LCN	Channel
1, 2, etc	any BBC channel (except 107 BBC News HD)
8	local channel
16, 36, 37, etc	QVC standard definition channels
95	Create & Craft
100	Freeview Information

 

[MartinLiddle]

This is probably another red herring but someone over on DigitalSpy has reported " The problem was getting the Fox -t2 connected to the TV! Often only a Green screen was all you got. I gave the HDMI socket on the Fox-t2 a squirt of Switch cleaner, & it seems to have cured the fault - I hope!".

 

[Black Hole]

This is probably another red herring but someone over on DigitalSpy has reported " The problem was getting the Fox -t2 connected to the TV! Often only a Green screen was all you got. I gave the HDMI socket on the Fox-t2 a squirt of Switch cleaner, & it seems to have cured the fault - I hope!".

That's not entirely impossible, IMO. If we acknowledge the result of an incomplete HDCP is a geeen screen, then a poor connection on the channel used for HDCP could be to blame. Not in my case though.

 

[bottletop]

This is probably another red herring but someone over on DigitalSpy has reported " The problem was getting the Fox -t2 connected to the TV! Often only a Green screen was all you got. I gave the HDMI socket on the Fox-t2 a squirt of Switch cleaner, & it seems to have cured the fault - I hope!".

I don't have any switch cleaner. I did try unplugging unit, squirting the socket (and plug) with isopropyl alcohol followed by several insertions/removals. Waited for it to dry off before trying again - no improvement.

I'll have to agree.
HDMI seems to work during the loader sequence, but fails after a normal boot, usually just after it tries to show the current live broadcast TV channel.
I've added to my post#4 (note 4) https://hummy.tv/forum/threads/inve...after-a-few-seconds-problem.10218/post-155508
The troubled HDR green screen unit displays fine during firmware update!

Can anyone else confirm this (my post #18) - i.e. try this on their afflicted units. The HDMI output is fine during firmware update.

 

[Black Hole]

Can anyone else confirm this (my post #18) - i.e. try this on their afflicted units. The HDMI output is fine during firmware update.

I will confirm if I get the chance. It is to be expected: the boot splash screen is pre-HDCP, and there's no reason the firmware update screen shouldn't be also.

 

[bottletop]

I will confirm if I get the chance. It is to be expected: the boot splash screen is pre-HDCP, and there's no reason the firmware update screen shouldn't be also.

Oh that is fair enough - ie the loader boot splash is pre-HDCP.
I'm a bit behind the times as I thought you were trying different boot loaders to try to eradicate the issue.
I've edited my post#4 as I notice sometimes there is a brief green screen flash at the end of the loader boot splash on any HDR.

 

[Black Hole]

I'm a bit behind the times as I thought you were trying different boot loaders to try to eradicate the issue.

I was – but the unit in question has worse problems which only showed up when I was about to return it "no fault found"!

 

[bottletop]

I was – but the unit in question has worse problems which only showed up when I was about to return it "no fault found"!

If it's got multiple problems then the only thing I can think of is maybe dry joints or overheating caused some faults.
If all else fails, whack around the motherboard or bake the thing in a spare oven!

 

[Black Hole]

In this case, I can't believe the green screen thing is a hardware fault – as noted, it works on a different telly.

 

[BMAX]

Marginal logic levels or timing?

 

[everthewatcher]

In this case, I can't believe the green screen thing is a hardware fault – as noted, it works on a different telly.

Haven't there been cases of it occurring on a previously OK pairing? That suggests something changing with time and one candidate might be timing.

I see from the WP article that the HDCP is implemented via the DDC which is based on the channel based on I²C specification at 100kHz or 400kHz.

 

[Black Hole]

Haven't there been cases of it occurring on a previously OK pairing? That suggests something changing with time and one candidate might be timing.

Who says this box conforms to other examples? I agree about the possibility of a timing thing, but I was thinking of hard faults (broken tracks or whatever).

 

[/df]

...I see from the WP article that the HDCP is implemented via the DDC which is based on the channel based on I²C specification at 100kHz or 400kHz.

I couldn't see that in Wikipedia, but good details here and tl;dr here.

 

[Black Hole]

but good details here

Very good. I must read that again later.

 

[/df]

The author remarks that corrupt EDID would result in green or pink screen. I don't know whether he (?) is referring to the palette or to the sort of blank green screen that is being investigated. Occasionally my Toshiba TV fails to agree with the HDR if the latter is already on (there is a cheap 3-to-1 HDMI switch involved): the result is a picture with pink and green hues. Also, it is notable that EDID is only sent at start-up while HDCP is sent continually: do failures occur after a good picture has been shown?

There doesn't seem to be any reason why the timing issue due to excess capacitance that the company's product aims to fix would occur in a domestic setup -- other than ageing, as suggested by ETW.

... the boot splash screen is pre-HDCP, and there's no reason the firmware update screen shouldn't be also.

Can any picture can be shown "pre-HDCP"? There will be some HDMI set-up code in the loader, which could be less sensitive than the equivalent in the settop program that takes over from it; eg, perhaps the loader only uses a subset of the outboard HDMI functionality?

 

[Black Hole]

Can any picture can be shown "pre-HDCP"?

I don't see why not, surely it would start up in pure unencrypted HDMI. HDCP is only required to protect HiDef content anyway, even though the HDR-FOX defaults to that even for StDef. I wasn't aware the traffic was actually encrypted, I thought it just plain wouldn't send at all if the HDCP is not complete (which is what it does - maybe that's an alternative to encryption.

My hypothesis is that the pre-boot environment just runs plain unprotected HDMI, hence you get the splash screen and the firmware update screen regardless of HDCP.

I don't know whether he (?) is referring to the palette or to the sort of blank green screen that is being investigated.

So far as I can tell (without being able to analyse the actual HDMI data), the green screen we get is actually being transmitted as HDMI.

do failures occur after a good picture has been shown?

I don't know, but I don't think its ever been reported. We can certainly induce two-second pulsing (or something like that) by connecting HDMI and analogue at the same time.

 

[bottletop]

Here is what I get when starting up the faulty green screen HDR. It is tuned to channel QVC

Watch green2-export1 | Streamable

Watch "green2-export1" on Streamable.

streamable.com

 

[Black Hole]

That's about the size of it.

 

[/df]

If my memory stretched back to the OP,

There have been a couple of reports of video on HDMI being OK for a couple of seconds after start-up and then going green-screen
...

I wouldn't have asked those questions. A "couple of seconds" seems to finger the HDCP exchange. It's the same in the linked video above (~2s of video and then green). Two seconds is the period for repeated HDCP exchanges.

As the HDMI transmitter interface is implemented by the TDA9984A IC, perhaps study of its datasheet could be useful. Unfortunately it's not bad on electrical and timing specs but only touches on I2C programming of the device, and other online sources seem thin.

Apparently HDCP need not be enabled:

The HDMI transmitter contains an HDCP function, which encrypts the transmitted stream content (both video and audio). This function can be enabled and disabled via the I2C-bus.

There is a reset function that has to be executed at startup, and then a hot-plug sequence initiates the exchange of EDID and/or HDCP data. Code that appears to deal with this using the NEXUS API can be found here (line 1067ff., line 911ff.).

Although this is exposed for the settop program through its shared library interface

# nm -DC /usr/bin/humaxtv | grep -i '_Hdmi'
         U NEXUS_HdmiOutput_GetAudioConnector
         U NEXUS_HdmiOutput_GetBasicEdidData
         U NEXUS_HdmiOutput_GetCecConfiguration
         U NEXUS_HdmiOutput_GetCecMessageInfo
         U NEXUS_HdmiOutput_GetCecStatus
         U NEXUS_HdmiOutput_GetHdcpStatus
         U NEXUS_HdmiOutput_GetSettings
         U NEXUS_HdmiOutput_GetStatus
         U NEXUS_HdmiOutput_GetVideoConnector
         U NEXUS_HdmiOutput_HotplugCallback
         U NEXUS_HdmiOutput_ReceiveCecMessage
         U NEXUS_HdmiOutput_SendCecMessage
         U NEXUS_HdmiOutput_SetAVBlank
         U NEXUS_HdmiOutput_SetAudioMute
         U NEXUS_HdmiOutput_SetSettings
         U NEXUS_HdmiOutput_SetTmdsSignal
#

something similar must be statically linked in the loader.

 

[Black Hole]

Don't get me started on EDID! My electriQ (sic) UHD monitor returns a manufacturer ID which is identified in the tables as "do not use". That means when I go into desktop settings, the desktop layout mapping to monitor(s) disconcertingly displays "do not use" as my main (only) monitor! Very confusing.

I cured it by editing the look-up table, but that means doing it again every time the OS gets updated.