The output image suffers from pixel flickering and incorrect black level performance.

[szuping]

Hello,
I have fabricated two PCBs based on the Beta3 schematic featuring the THS7316 video amplifier. One is equipped with the WM8213 audio codec, and the other uses the WM8214. I have not tested the AFE circuit, and only verified that the HDMI output works normally. However, several visual issues occur on the display:

1.Severe irregular pixel flickering appears across the entire LCD screen, with flickering pixels randomly distributed in large numbers.
2.The overall image looks dim. This is not a simple brightness issue; it appears to be caused by incorrect black level compression or black level loss.
3.Adjusting RGB offset parameters fails to fix the above two problems.

My test signal sources are SNES and Genesis game consoles with native RGBS output. I also tried RGBHV VGA signals for testing, yet the anomalies remain unchanged. Identical issues occur with both WM8213 and WM8214 versions.

I have reworked and cleaned the soldering pins of WM8213 and WM8214, but the issue remains unchanged.
Could you kindly advise the possible root causes of these problems? Thank you very much.

[Fdiskitup]

Hi Szuping - do you have a uf2 file I can test on my hardware ?
I have spent hours getting the toolchain to work but still no main firmware - should it be the "integrationTest.uf2" ?

integrationTest.zip

[szuping]

Hi Szuping - do you have a uf2 file I can test on my hardware ? I have spent hours getting the toolchain to work but still no main firmware - should it be the "integrationTest.uf2" ?

integrationTest.zip

yes, It's main uf2

[Fdiskitup]

can you attach your here ? I am using WM8214 chip

[szuping]

can you attach your here ? I am using WM8214 chip

https://github.com/mlorenzati/pico-rgb2hdmi/releases/download/0.6.4/pico-rgb2hdmi-0.6.4.zip

Extract this file. Inside you will find the integrationTest folder and the integrationTest.uf2 file. I did not compile it myself.

[Fdiskitup]

i got a flash of an image !

[szuping]

i got a flash of an image !

Your OSD also appears to be faulty. Please first use hdmitest.uf2 to test the signal path from the RP2040 to HDMI, and clean all soldered pins of the WM8214.

[Fdiskitup]

HDMItest looks great !

[Fdiskitup]

With "IntegrationTest.uf2" version 0.6.4 I found that pressing on the pico on the side closest to the HDMI port changed the pixel noise.
I tell you this because it seems the dot crawl / problem was improved with better connection of the pico - I did not solder the pico solid to the board I used pin headers.

So perhaps it is better to solder the pico directly.

Also the OSD image is perfectly stable if I change to 320 x 240.

[szuping]

With "IntegrationTest.uf2" version 0.6.4 I found that pressing on the pico on the side closest to the HDMI port changed the pixel noise. I tell you this because it seems the dot crawl / problem was improved with better connection of the pico - I did not solder the pico solid to the board I used pin headers.

So perhaps it is better to solder the pico directly.

Also the OSD image is perfectly stable if I change to 320 x 240.

Our OSD works properly as well. We use the pin headers of the RP2040 to connect to the main PCB. The HDMI_TEST program is designed to let the RP2040 output digital patterns and send HDMI signals via PIO pins. The situation may differ when analog RGB signals are fed in. I don't think the pin headers are the main cause. Even the original test screen released by the developer has the same issue of horizontal pixel flickering.

[mlorenzati]

Do you still are able to get WM8213/WM8214?

My plan is to develop v2 with a LM98714 and an rpi pico 2, I started the support for audio in this model as a first step but no time to continue

[szuping]

Do you still are able to get WM8213/WM8214?

My plan is to develop v2 with a LM98714 and an rpi pico 2, I started the support for audio in this model as a first step but no time to continue

Hello, it’s fantastic to receive your reply from the development team. I have several technical questions to consult with you:

1. Prior to feeding signals into the THS7316, is a DC bias circuit required to ensure proper RGB signal input to the device? The THS7316 is a single-supply IC, and DC-coupled input is adopted in this design, which I suspect is incompatible with most standard RGB signal sources.

2. Between the THS7316 output and the WM8213/WM8214 input, the current circuit features a 50Ω pull-down resistor to GND followed by a series 50Ω resistor. Is this configuration implemented solely for 50Ω impedance matching at the WM8213/WM8214 input? (This topology appears to overload the THS7316).

The conventional impedance matching layout should use a 50Ω or 75Ω series resistor first, then a matching pull-down resistor to divide the doubled RGB signal down to a peak of 0.7V. Referencing the legacy Version 2 schematic, I speculate only a single 50Ω/75Ω series resistor is needed before routing signals into the WM8213/WM8214 to retain the original peak output level of 1.4V.

3. Should a coupling capacitor be inserted ahead of the WM8213/WM8214 inputs to block the DC component from the THS7316’s DC-coupled output? By feeding AC-coupled RGB signals into the codec, the WM8213/WM8214 can apply its internal self-bias for incoming signals independently.

4. The displayed picture suffers from crushed black levels, flickering pixels and recurring horizontal black banding across the screen. Is this defect rooted in hardware flaws, or fixable via firmware adjustments?

Sourcing brand-new WM8213 parts has become extremely difficult; available WM8214 units on the market are mostly used reclaimed tested-good dies.

Pairing the LM98714 with the RP2350 (including HSTX peripheral) is an outstanding hardware combination. However, flawed existing circuitry and source code result in unstable, subpar video output quality at present.

Thank you sincerely for all your development work, and best regards.

[mlorenzati]

1. There is no need, the offset can be managed by the configuration of the WM8213, or use high capacitance electrolytic
2. Yes, the idea is to match impedance and keep same levels as the prior beta without the op amp
3. As in 1 is optional, example if you have SOG (sync on green) and there is a future plan to detect it
4. Those are good but multple questions in one
   black level -> adjust gain (even individually)
   flickering pixels -> this is totally able to be improved, firmare is fast but not smart enough when it comes to detect next start line, options are to use the hsync an clocking to generate an artificial stable signal or use a PIO to manage that, did not have the time but totally worth it
   Also there is a relation between the capture width and the pixel width, with faster cpu (e.g pico 2) this can also be improved by oversampling
   Also too, each retro computer is a source of lots of noises and the video input is not limited, there was the option to use another video amp with less gain, this makes the system less prone to this errors but did not like the "80's Video" quality, up to you to test.
   Also, do not enable usb if you care for smooth video, is just to play with RGB capture to USB (tearing on USB samplings periods)

So bottomline, a lot can be improved by firmware and a bit with hw changes
But at this point with all my other priorities, if I have time is to:

• Make it work with rp2350
• add audio support as I did with picoDVI on pico
• move to a long term support AFE with greater capabilities and more importantly higherlifespan

Hope it helps!
PD: there are people that shared nice results but not clear if they did changes not shared with me, shame... shame...

[szuping]

I have a general understanding, but I still have questions regarding the following points:

1. For most retro consoles and legacy RGB signals, large-value electrolytic capacitors are fitted either inside the console or on external RGB cables to eliminate inherent DC offset in advance. This results in AC-coupled signals feeding into the 7316. Without sync information, the RGB levels cannot be pulled up to positive voltage by the 7316 alone. For this reason, most dedicated RGB amplifier circuits add an input-side DC offset restoration circuit to shift full RGB swing into the 0V~3.3V range, ensuring intact signal input and proper processing by the 7316.

2. A 50Ω pull-down to GND followed by a series 50Ω resistor may overload the 7316 and cause dimmer displayed images. We have observed excessive heating on the 7316. Would it be advisable to remove the 50Ω ground resistor entirely, and switch the series 50Ω component to 75Ω if needed?

Regarding add audio support as I did with picoDVI on pico:
Will audio be sampled directly via onboard ADC on RP2040/RP2350, or will an extra codec IC be used to convert audio into I2S? Can perfect audio-video synchronization be guaranteed?

PD: there are people that shared nice results but not clear if they did changes not shared with me, shame... shame...

Is this factual? That is indeed a pity.
I will experiment with circuit tweaks myself and report back once I achieve improved results.

Thanks a lot for your detailed reply.

[mlorenzati]

1. good point, but again the afe can set a dc level
2. it would be a matter of testing yes, share your tests
3. It's the concept of at least play audio in the hdmi data island, current board wasted pins I know and the extesion was spi, on a new model it could be either an i2s capture (works nicely since you configure it and the chip captures audio data chunks effortlessly) or use the ADC with DMA, but only with 12 bits
4. regarding the images yes, people shared me results, but without any feedback on how it was achieved

[Fdiskitup]

Do you still are able to get WM8213/WM8214?

My plan is to develop v2 with a LM98714 and an rpi pico 2, I started the support for audio in this model as a first step but no time to continue

The WM8214 was only available from China seller on ali express and was $30 usd for 5 pieces.

The RGB2HDMI project uses raspberry pi zero ($15) + CPLD XC9572XL ($10 on digikey) this chip is also end of life.
we really need a solution for our retro computers.