Capturing parallel RGB data with low pixel clock

[snoboleg]

So I have this project in mind but I am not sure what the best/easiest way to aproach it might be.
The goal is to capture the parallel RGB output of a TI DS90CR216 chip. https://www.ti.com/lit/ds/symlink/ds90cr215.pdf?ts=1720978293511
I "just" want to create a video stream over some kind so I can display/stream the video data on a linux machine. I wouldn't mind black bars or somewhat low fps.
The image output is 400x240pixels, I currently don't know the refresh rate. However at something like 60Hz this would result in a pixel clock below 10MHz.

Now I had a couple of ideas on how to approach this issue, but I'm not sure which one would even work.

Converting parallel RGB to DVI using the TFP410
I found a project here where a very similar issue was solved.
In this project the op created a PCB with a TFP410 to convert from parallel RGB to DVI.
As far as I can tell the underlying video data is at 480p though which satisfies the necessary pixel clock of 25MHz for the TFP410.

https://www.eevblog.com/forum/testgear/tektronix-tds3xxx-replacing-backlight-power-supply-fan-etc-(photos)/msg5502568/#msg5502568

I have been testing around a bit with one of these loiw budget HDMI to USB capture cards. And it only takes the resolution of 400x240 at weird timings. For CVT it only work at a refresh rate above 180Hz.
With some tweaking of the timings I can actually get a picture at 60Hz with black bars too. However I don't think I can replicate these timings with a TFP410.

The data sheet states that the required pixel clock is at least 25MHz. I would guess the chip would still work outside of that spec and might output a signal that is not DVI compliant. However I don't know how to capture that, because the receiving end doensn't accept a signal with a pixel clock that low.

This application note lists DS90CR218A as compatible to the TFP410, which appears similar to the DS90CR216. But I guess this is also expecting a higher pixel clock.
https://www.ti.com/lit/an/slla559/slla559.pdf


Using a ESP32 to read the parallel data and stream over http webserver
There are some ESP32 projects like the ESP32-cam etc that utilize the i2s functionality to read parallel data and stream it.
So in theory the ESP32 could be capable to do something like this.
The ESP32-camera library only supports a couple of camera sensors as far as i can tell and these use a data bus and instead of just parallel RGB bits.
The closest things i was able to find for this approach are these topics. Sadly I just don't know enough at this level of coding to make this work for me.
The first link has got some code at the end of the thread that is used to read parallel data if I understand correctly.

https://esp32.com/viewtopic.php?t=24980
https://github.com/TobleMiner/esp_i2s_parallel


Converting parallel RGB to analog Video
Last idea I had was to maybe convert to CVBS or VGA or something like that and feed it back to a capture card.
I was looking into chips like the ADV7125 for example. https://www.analog.com/media/en/technical-documentation/data-sheets/ADV7125.pdf
But I'm not sure if it would work.


I would be open to any other ideas to make this work. Would appreciate any input.
Scaling the original data from 400x240 to 800x480 would eliminate the pixel clock issue. Woulnd't even mind just padding the picture with black bars.
But i just don't know if or how that could be achieved.

[c64]

To convert to VGA you just need a DAC (or R2R) and maybe some simple logic for sync signals.

Can you find out the timings of your signal?

[Berni]

Coversion to VGA should be the easiest since it is basically the same as RGB except that the R,G and B data is in analog form rather than a parallel bus. So it can be done with a R2R resistor DAC. Sometimes you might also need some extra blanking circuitry to apply black during HSYNC and VSYNC as monitors often use that to calibrate the black level, but some RGB buses don't set the data bus to 0 during that time.

Tho it seams that most of your problem is not the conversion but the fact that you have such weird timings that a lot of off the shelf capture devices might not be able to handle(since those tend to be used on standard resolutions like QVGA, 720p etc..

With modern fast MCUs you could viably bitbang a slow pixel clock RGB input by running the RGB into a 16bit wide GPIO port and then grabbing the state into RAM at precise moments (be it a busy loop, or maybe a interrupt triggering a DMA transfer). Tho getting that to a PC later on in full realtime framerate is the more difficult part.

One thing to try might be a video upscaler box for retro gaming. These have gotten a fair bit of popularity and are made to get weird old video formats into a modern TV in the highest quality possible. They are usually FPGA based inside. But for just retiming your RGB into something more standard you could fairly easily write your own FPGA video retimer on a cheap small FPGA (But if you don't already know how to program in HDL it is likely not worth the effort)

[snoboleg]

Don't know the exact timings tbh. I found the datasheet of the original display but those only describe a range for the signal as far as I can tell.
There are only a couple of things I know about it.
Resolution 400x240, Refresh rate 60Hz and Pixel and pixel clock is around 8MHz.
Definitly going to try the VGA approach then. I have ordered a VGA capture card, gonna take a couple of days to arrive though.

[c64]

Do you have logic analyzer or scope? It may be using non-standard number of blank lines, VSYNC/HSYNC timings, or no VSYNC/HSYNC at all (DE only). Even cheap 24MHz 8-bit LA can help

[snoboleg]

I have one of those 24MHz logic analyzers on the way right now. Sadly no scope.
The display does use Vsync/Hsync timings, I have attached the pinout from the lcd connector and the timing section of the display from the datasheet. B0 and R0 are tied to ground on the display driver board though which should't make too much of a difference.

The display gets the data from the DS90CR216 receiver. Which converts a LVDS data stream to parallel RGB as far as I can tell.
This is the datasheet. I have to admit that I'm really new into this thing and I don't fully grasp the whole timing part.
https://www.ti.com/lit/ds/symlink/ds90cr215.pdf?ts=1721761518529

[radiolistener]

Just use some cheap Chinese video capture USB dongle.

[snoboleg]

What kind of dongle do you have in mind? I didn't find anything suitable while searching.

I have just tried to hook up the Vsync, Hsync, gnd and G5 signals to a VGA-Capture dongle but it didnt't show anything.
Then hooked up those 3 signals to a Display with a VGA input port and there I've got at least some green lines showing. The whole picture is moving from the bottom to the top though.
Sometimes there is something readable in the upper left corner. But it's mostly unrecognizable. I have attached a video on the output that I got.
I only took one signal (G5) as the MSB and fed it through a R2R.
 
Am I correct to assume that the timings won't work with VGA?

[macboy]

This is just a thought. Many arcade machines operate with low resolutions to their RGB CRTs. Some enthusiasts have without doubt found digitizing or conversion solutions to replace unobtainable CRTs with LCDs.

[snoboleg]

Just found this adapter on Ali: https://de.aliexpress.com/item/33061955191.html

Any chances that this one might work? Couldn't find a english datasheet for the GM7123 chip but it appears to be a ADV7123 knockoff I guess.
I have also attached a screenshot from the logic analyzer.