HDMI physical layer vraag

Nee, de kloksnelheid gaat naar beneden, de aderparen zijn (min of meer) de losse kleurcomponenten. Op hackaday.com staat een mooi artikel met enige details.

Ah duidelijk en dank voor het snelle antwoord!

De onderverdeling in RGB was ook mijn eerste veronderstelling, maar dat klopt niet met de klachten die ik in een apparaat tegenkom... Wellicht zit er dan een storing op de kloklijn en niet op een van de signaalparen. Terug naar af dus. Mogelijk open ik volgende week een reparatietopic.

[Bericht gewijzigd door maartenbakker op vrijdag 7 juni 2024 12:59:56 (14%)

doorgaans zijn random gekleurde pixels, blokken in kleuren ed te wijten aan slechte massa verbindingen van de stekker of kabels. soms kun je het bij kabels zo zien, dan is er 1 pin naar achter geschoven in de stekker.

Klopt, alleen bij mij lijkt het er meer op alsof vooral de sync flink staat te ruisen, dus allerlei vervorming en jitter maar dan uitsluitend bij de hogere bitrates (1080p).

Ik maak er wel een reparatietopic met foto'tjes van. Maandag nog maar even wat gaan troubleshooten. Connector controleren, printsporen meten, scope erop. Misschien ook even een ander receiver IC proberen (die erin zit is nieuw want de oude was flink opgeblazen, maar je weet maar nooit).

Er zit ook een flink verschil in de kwaliteit van HDMI kabels.

Op vrijdag 7 juni 2024 18:12:44 schreef revado:
Er zit ook een flink verschil in de kwaliteit van HDMI kabels.

klopt, de lange kabels hebben niet zelden nogal moeite met 1080P of meer dat merk je al aan het feit dat de tv moeilijk naar de resolutie wil omschakelen. de dikke kabels hebben het meeste moeite, de 5mm dikke hdmi kabels die je nu hebt zijn juist minder gevoelig voor hoge resoluties.

In mijn tijd als homeservice-monteur (2005 - 2011) kwam ik regelmatig pixelruis problemen tegen bij vooral dure HDMI kabels (ja, serieus kabels van 80cm voor €490!). Vervangen van die kabel door de HDMI kabel die de Action destijds verkocht (die met de oranje stekkers) loste het probleem ALTIJD op.

Absoluut geen kabelprobleem want dat heb ik getest, en ook geen pixelruis zoals je zou verwachten dat dat er uitziet.

Een hoop symptomen zouden hebben gepast met een fout in de HDMI bus als de kleursignalen geen eigen dedicated pair hadden gehad, vandaar dat dat mijn oorspronkelijke vraag was. Ik ben bij TV en monitor een groot aanhanger van terugredeneren vanaf het beeld waar de fout moet zitten.

Maar nu denk ik dat het probleem verderop zit, mogelijk gevolgschade (en dan waarschijnlijk van het opblazen, niet van de reparatie - want je werk dubbelchecken is belangrijk). Ik plaats later nog even plaatjes om die visuele diagnose begrijpelijker te maken. Behalve jitter, kloppen er ook kleuren niet. Dat kan zijn omdat de achterliggende logica niet meer kan zien of het RGB of YUV is, of omdat er datalijnen in de knoop liggen.

Uitleg: Het IC, de LT8619C was nieuw geplaatst en inmiddels nog een keer geswapt. De vraag is nu of ik er nog tijd in ga steken en het kristal swappen (zo op de scope te zien komt daar geen jitter af) en wat ontkoppel C'tjes. Zonder logic analyser om op de uitgaande LVDS bus van de LT8619C te kijken, is het een beetje einde verhaal. Dat is de enige plaats waar (behalve de klokfrequentie) verschillende resoluties verschil kunnen maken in de verwerking (het gebruik van andere datalijnen). Er zat een krater in het IC, dus het is niet uit te sluiten dat er via de bus nog meer opgeblazen is.

De oplossing zal vrij simpel zijn, de klant de keuze bieden tussen een nieuw mainboard of leven met het mankement.

P.S. Geen merk of typenummer deze keer, ook al hamer ik daar altijd op. Kwestie dat klanten geen verkeerde indruk krijgen als ze simpelweg op een merk of type zoeken waar de wereldwijde serviceorganisatie relatief klein is (als je verder graaft weet je het wel, maar het moet gewoon niet te erg googlebaar zijn). Reparatie op componentniveau is optioneel, ik heb schema's onder non-disclosure en het is een generieke applicatie rond de HDMI receiverchip.

Op dinsdag 11 juni 2024 13:08:52 schreef maartenbakker:
Een hoop symptomen zouden hebben gepast met een fout in de HDMI bus als de kleursignalen geen eigen dedicated pair hadden gehad, vandaar dat dat mijn oorspronkelijke vraag was.

Volgens mij is dat ook zo, de 4 aderparen zijn volgens mij zo uit mijn hoofd 8b/10b encoded of zo met een dedicated clock pair. Die encoding veranderd volgens mij ook per resolutie?

Er kan ook audio bij zitten dus dat moet ook in de data stream gefrot worden, vandaar die encoding. EDID data aan de ontvanger kan ook corrupt zijn en er voor zorgen dat sommige resoluties niet meer werken.

Misschien is onder DVI iets te vinden? Het is in ieder geval anders als een LVDS video interface (dat is 4b/5b encoding zover ik me herinner uit het verleden toen ik daar iets mee gedaan heb).

Omdat het clock signaal synchroon is met de data is die ook behoorlijk kritisch. Zien die signalen er nog goed strak uit?
Zitten er terminator weerstanden aan de bron/ontvanger zijde en zijn die nog heel? (waarschijnlijk 50, 75 of 120 ohm)

-edit- TMDS encoding:
https://en.wikipedia.org/wiki/Transition-minimized_differential_signal…

Ik heb begrepen dat de paren dedicated zijn (1 paar per kleur en 1 paar voor de sync). Mijn eerste gedachte was dat de fout te verklaren was als er een paar bijgeschakeld zou worden voor een hogere bitrate en dat paar niet lekker zou zijn, maar dat is niet zo: de klok wordt alleen maar verhoogd. Mijn tweede gedachte was dat het syncpaar misschien niet lekker zou zijn (bijvoorbeeld printspoortje beschadigd bij vervangen IC, maar die zijn verbazend sterk), maar een ohmse meting is goed en de scope die ik heb is slechts 100MHz en heeft geen differentiële probe. Op dit moment is het min of meer een hobbyprojectje omdat ik al besloten heb hoe de reparatie verder afgehandeld moet worden... Bovendien kom ik niet zo vaak HDMI-problemen tegen omdat het meeste over SDI gaat (alles over 1 aderpaar dus ook andere soort klachten). Dus speciaal hiervoor apparatuur aanschaffen is overdreven, maar ik ga wel even uitzoeken wat ik in de toekomst nodig zou kunnen hebben om diverse signalen beter zichtbaar te maken.

Het enige onderdeel in het HDMI-signaalpad dat ik niet zo goed mogelijk getest heb, is de connector zelf. Die zou ik dus nog even kunnen swappen, het zou slordig zijn als het syncpaar daar deels onderbroken wordt of slecht contact maakt, en ik dat compleet gemist heb.

Het signaalpad tussen HDMI connector en LT8619C is dus intact voor zover ik tot nu toe heb nagegaan. De ESD beveiliging (had ik niet vermeld, 2x4 snelle transzorbs in een zo klein mogelijk SMD behuizinkje) maakt geen verschil.

De bron en kabel zijn onverdacht, een signaalgenerator en een Blurayspeler met elk een eigen kabel, die op andere monitoren goed spelen.

Het belangrijkste verschil in encoding dat ik heb kunnen vinden, is dat de uitgaande LVDS bus van de LT8619C anders gecodeerd kan zijn afhankelijk van het ingaande signaal en hoe de processor hem instelt. Dat is helaas informatie die niet gedocumenteerd is (behalve op de R&D afdeling van de fabriek). Die bus verdwijnt direct in een FPGA, en die is te groot om te swappen voor een test.

Wel degelijk is HDMI gecodeerd (TDMS zie vorige post) en niet een 1-op-1 RGB/Clock signaal. Tenzij het geen echte HDMI is.
Dat moet ook wel want hoe wil je anders audio overbrengen naar de ander kant?

Wat wel kan is dat er maar 1 clock + 1 data pair gebruikt wordt voor lage resoluties, maar nog steeds gecodeerd.

HDMI naar LVDS conversie IC's (of chipsets) zijn er te kust en te keur, bijvoorbeeld van TI, zie deze application note:
https://www.ti.com/lit/an/slla325c/slla325c.pdf

LVDS zelf is ook weer gecodeerd maar dan in 4b/5b. De originele clock wordt met een factor 7 aan de ontvangerkant weer met een PLL vermenigvuldigd om de datastroom te decoderen. Zoek op Flatlink transceivers.

Maar heb je nu gechecked of de termination van lijnen goed is? Dat verdenk ik als eerste.

Helaas vermeldt die appnote niet hoe het dataformaat op die HDMI (TMDS) bus nou echt inelkaar zit, dus ik zal wat verder moeten zoeken. Maar wat jij zegt is dus dat mijn eerste twijfel klopt en de aderparen niet met kleurkanalen overeenkomen, los van hoe ze gecodeerd zijn?

Dan zou de inkomende kant toch weer verdacht kunnen zijn, maar zoveel onderdelen zitten daar niet in. Het enige onderdeel waar ik nog niet aan gemeten heb is de connector zelf.

Ik ga in elk geval donderdag nog eens meten. De terminatie gebeurt in het receiver IC LT8619C, en dat is al twee keer vervangen en de printsporen naar de HDMI bus maken goed contact. Terminatie is natuurlijk wel iets dat bij een hogere clockfrequentie eerder mee gaat spelen als er wat mis is, dus op die manier past het wel in het plaatje.

Dit is het gebruikte testbeeld (haringgraten zitten in m'n telefoon):

Dit is hetzelfde testbeeld op 1080p (glossy scherm, de TL buizen zitten aan het plafond):

dat is een enorm verschil!!

Het stoorbeeld is ook niet statisch, de storing jittert en golft, een beetje zoals wanneer er in een CRT toestel bijvoorbeeld iets in de horizontale afbuiging over staat te slaan. Er is kennelijk een stevig timingprobleem ergens in de signaalverwerking. Hoe langer ik er over denk hoe minder ik geloof dat het probleem achter de HDMI chip zit... Maar zoveel onderdelen zitten er niet aan de chip zelf die dit kunnen veroorzaken. De voedingslijnen lijken in orde, de kristaloscillator geeft een stabiele sinus.

[Bericht gewijzigd door maartenbakker op woensdag 12 juni 2024 00:08:08 (34%)

De HDMI-stream wordtd naar mijn idee wel goed ontvangen en gedecodeerd, de kleuren kloppen. Als het decoderen van de stream mis gaat (op bit-niveau), dan worden kleuren eengrote chaos.
Dit lijkt eerder mis te gaan in de timing van het panel zelf (T-CON?)
In de HDMI-stream zit wel sync informatie, maar die is net als de rest van de beeld data, in de stream gecodeerd. (Net als de audio stream trouwens, maar dat terzijde). Die sync wordt volgens mij wel gewoon correct uit de stream gedestilleerd, maar verderop gaat de clocking van de data naar het panel de mist in.

@ Mnm: dat is wat ik ook denk, want dit:

Op dinsdag 11 juni 2024 14:18:23 schreef maartenbakker:
De bron en kabel zijn onverdacht, een signaalgenerator en een Blurayspeler met elk een eigen kabel, die op andere monitoren goed spelen.

Sluit naar mijn mening andere oorzaken dan het toestel uit.

Op woensdag 12 juni 2024 16:41:53 schreef MNM(tm):
De HDMI-stream wordtd naar mijn idee wel goed ontvangen en gedecodeerd, de kleuren kloppen.

Uh, de kleuren kloppen naar mijn mening heel duidelijk niet. De kleurenbalken (en vooral de onderste) en de twee personen verschillen nogal extreem van kleur.

Aan Maarten: waar heb je dat testbeeld vandaan? Niet dat ik vaak HDMI of SDI-gerelateerd spul repareer, maar soms is een echt testbeeld wel prettig om verschillen te ontdekken en de standaard SMTPE-uitvoer die in elke professionele (of ook consumenten? geen idee) videocamera zit is lang niet altijd toereikend naar mijn mening.

@MNM:

Dan zou je dus zeggen dat het opblazen van de HDMI receiver, gevolgschade heeft veroorzaakt bij de achterliggende FPGA (hij gaat niet direct richting LCD panel, hij kan omschakelen naar een SDI input, er wordt een LUT op toegepast en hij stuurt ook nog een HDMI en SDI datastream weer naar buiten - trouwens geen idee waarom ik die data nog niet op een tweede monitor bekeken heb!)

Overigens zijn de kleuren ook niet in orde. Die lopen er op sommige delen van het beeld wel naast (alsof er bitjes verlopen in timing).

Maargoed, huiswerk tot nu toe is dus HDMI connector checken, terminatie checken, uitgangssignalen checken op tweede monitor en Omnitek.

Het kan zijn dat dit een topic wordt waar voorlopig geen uitkomst aan zit; ik doe morgen een voorlopig laatste poging. Dan gaat het mainboard in de bak voor loop en sloop (of retour klant bij niet accoord) en krijgt de klant een quote voor een nieuw mainboard. Het tempo moet er wel een beetje in blijven.

Het oorspronkelijke doel was de HDMI datastream (eigenlijk niet alleen de physical layer!) beter te begrijpen. Als iemand daar een goed document over weet, houd ik me alsnog aanbevolen.

@weardguy:

Ik heb beschikking over een Omnitek ULTRA en een Omnitek OTM1000. Dit plaatje stond oorspronkelijk op die laatste, maar heb ik gekopieerd omdat ik het een fijn testbeeld vind. De ULTRA heeft een HDMI uitgang, de OTM1000 niet. Ik weet niet of het een af fabriek testbeeld was. Er zijn me meerdere technici voorgegaan in het gebruik van deze generatoren die ze dus ook al naar hun wensen hadden ingericht (het zijn eigenlijk PC's, de OTM1000 draait gewoon Windows). Overigens is Omnitek voor de patenten overgenomen door Intel en de productlijnen zijn beeindigd.

Via die wiki pagina, die ik eerder poste, kom je uit op dit document waar de T.M.D.S. data stream in staat:

dvi_10.pdf

Daar staat vanaf pagina 24 de hele 8b/10b encoding in detail in.

Dan gooi ik er als bonus ook nog even een overview bij van de verschillende display connectoren/interfaces, hebben we alles bij elkaar hier:

video-interfaces.pdf

Uit bovenstaande blijkt dus dat de HSYNC en VSYNC in channel 0 time multiplexed wordt.
Gedeeltelijk hebben andere posters hier gelijk: De R/G/B data blijken dus uiteindelijk wel in hun specifieke channel te zitten maar time multiplexed met andere data. Zie pagina 32.

Verder is de termination van de lijnen dus 50 Ohm, dus absoluut controleren, zie pagina 35. (Prio 1 zou ik zeggen!)

Check ook of je DDC data correct is. Volgens mij bestaan er tooltjes om die uit te lezen. Als die maar 1 resolutie aangeeft dan is er iets niet in de haak.

Op woensdag 12 juni 2024 17:11:41 schreef weardguy:
[...]
Uh, de kleuren kloppen naar mijn mening heel duidelijk niet. De kleurenbalken (en vooral de onderste) en de twee personen verschillen nogal extreem van kleur.
Dat klopt, maar dat ligt volgens mij eerder aan het niet goed gelijk lopen van de bit clock met de bit data. Aangezien een lijn al niet goed begint, loopt de rest van de lijn ook compleet uit sync. Bit data die voor een andere kleur was bedoeld, 'lekt' dan door in de vorige of volgende kleur.

Daar ga ik nog even op verder door, dank!

Maar nu eerst nog even de vreemdste observatie van allemaal... De test van de uitgangen. Uit de HDMI uitgang komt precies hetzelfde defecte beeld als op het scherm, wat me niet verbaast.

Wat me wel verbaast... Uit de SDI uitgang komt een keurig strak signaal waar helemaal niets aan mankeert.... Kennelijk is het timingprobleem dusdanig miniem dat de signaalverwerking om er SDI van te maken, er probleemloos korte metten mee maakt.

Op woensdag 12 juni 2024 00:04:59 schreef maartenbakker:
...de kristaloscillator geeft een stabiele sinus.

Maar klopt de frequentie?

@ MNM: Klopt maar bij de uitspraak 'de kleuren kloppen niet' denk ik aan zichtbare kleurproblemen, en die zie ik

Beetje een beroeps'ziekte' geworden, in de luchtvaart moet je echt zo duidelijk mogelijk zijn zodat niet alleen de klant het begrijpt, maar ook je collega en dan het liefst zonder dat je rapport wedervragen oproept, zodoende.

Op donderdag 13 juni 2024 11:46:21 schreef maartenbakker:
Wat me wel verbaast... Uit de SDI uitgang komt een keurig strak signaal waar helemaal niets aan mankeert.... Kennelijk is het timingprobleem dusdanig miniem dat de signaalverwerking om er SDI van te maken, er probleemloos korte metten mee maakt.

Ik heb een keer een chip gezien (het datablad, niet de chip zelf), weet niet meer waarvan of waarvoor, die van het HDMI-signaal intern een SDI-signaal maakte, dat verwerkte/bewerkte, om het daarna weer als HDMI terug aan te bieden op een uitgang, naast de mogelijkheid een SDI-uitgang te kiezen.

Als de HDMI-uitgangsverwerking het punt is, is het niet raar dat SDI wél werkt.

Overigens wel een van de redenen dat (HD-)SDI zo wijdverbreid is in de professionele sector, het is een uiterst robuuste verbinding wat betreft data-overdracht.

Wat betreft de Omniteks: iets ander prijskaartje dus . Die gestopte productielijnen verklaarde waarom ik niets kon vinden als ik op die naam zocht (nou ja, ik vond wel wat, maar alleen viscositeits-meters of zo)

Cliffhanger tot maandag, er moest tussendoor nog wat ander spul de deur uit (waaronder ook weer een ander leuk raadsel.... Alle onderdelen geswapt maar mankement blijft, net iets makkelijker zoeken dan toestellen die hun mankement juist helemaal niet laten zien op de werkbank ).

Veel verder dan de test aan de diverse uitgangen ben ik helaas niet gekomen.

Het vreemde daar is dat de HDMI receiver chip alleen de front end is en de uitgangsverwerking er in principe los van staat. Het LVDS signaal verdwijnt in een grote FPGA die het panel, de HDMI transmitter chip en de SDI aanstuurt. Je zou dus denken dat als de SDI uitgang wel werkt, de HDMI receiver in orde is, maar ik twijfel. Misschien heeft de verwerking naar SDI als (bedoeld of onbedoeld) bijverschijnsel dat de jitter eruitgehaald wordt. Wel raar, want in principe gebeurt alles real time. Bufferen wordt zoveel mogelijk vermeden - professionele videogebruikers hebben minstens zo'n hekel aan latency als gamers.

P.S. Ik heb nog niet gezocht, weliswaar een andere prijsklasse, maar tweedehands ook nergens betaalbaar te vinden? Die OTM1000 is toch al een relatief oud ding, ik meen Windows 7 en een echte harddisk, doet maximaal 3G (voor de niet-kenner: baudrate max 3gbps dus full HD 60p en geen 4K).

voor het omzetten van HDMI naar SDI moet er altijd wel wat gebufferd worden. SDi is serieel. en als het 50P (of 60P) is , 3G dus dan heb je de A en B standaard. bij een van die twee moet je héél lang bufferen.

Op donderdag 13 juni 2024 19:19:17 schreef weardguy:

Overigens wel een van de redenen dat (HD-)SDI zo wijdverbreid is in de professionele sector, het is een uiterst robuuste verbinding wat betreft data-overdracht.

Ook fysiek kan SDI beter "tegenspanningstootjes" en andere misbruiken. Uiteraard heeft alles zijn limieten, heb hier net een "bergje" Gennum SDI driver chips vervangen

[Bericht gewijzigd door kris van damme op donderdag 13 juni 2024 22:55:37 (52%)