ADC for X,Y, Z video output to HDMI - Page 1
Forum section: electronics / general

author: cncjerry
author_rank: Unknown
timestamp: February 21, 2017, 07:14:33 pm
content: I was wondering if I need an FPGA, I assume, to convert XYZ video output from my various older HP analyzers to HDMI? So I would need to do XY ADC conversion while the Z is high or maybe low, not sure of how it is blanked. I was thinking of just trying it with my STM32F7 boards but I doubt their ADC is fast enough.Thoughts? I've not used FPGA boards before, been thinking of trying them out so if you can also recommend a starter kit or board for this processing that would be helpful as well.Thanks.

author: Scrts
author_rank: Frequent Contributor
timestamp: February 21, 2017, 08:48:23 pm
content: That is very tough to go with FPGA as a beginner project...Maybe look for something specific? E.g. intersil video processors? Analog to HDMI solutions. Analog Devices also have something like that.

author: cncjerry
author_rank: Unknown
timestamp: February 22, 2017, 05:03:36 pm
content: I have a lot of experience with about every micro, none with FPGA. I saw where there are devices that do the stroke to raster or vector to video and both claim to be using an FPGA. I also know as a hard coded device they are faster than a typical general purpose micro. I'll look at the various boards ADC conversion rate to see what is available.

author: Scrts
author_rank: Frequent Contributor
timestamp: February 22, 2017, 08:15:19 pm
content: FPGA is very different to microcontroller... You will need a year or more of experience to do your first working prototype if you have plenty of time to work on it.

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: February 22, 2017, 09:19:03 pm
content: This isn't necessarily a very difficult project if you tackle it in sensible stages as a learning exercise.First off, forget HDMI for the moment, work with VGA until you have everything else working.FPGAs like Spartan6 can do native DVI out, so that can be added later.Second, use an FPGA that has enough internal memory to hold the VGA bitmap. This is vastly easier to work with as it is inherently dual-port, so the video output and input stuff can be independent with no need to synchronise.I'm not familiar with the HP output - is this actually XYZ, i.e. a vector display ?If so, you need to establish what samplerate you need to digitise it. I'd guess this wouldn't be too fast to do some pretty simple rendering into the display memory.If you're good at learning new things, have a rough idea how you'd tackle this if you were doing it with discrete hardware and start off with a suitable devboard so you have known-working hardware to start with, it could be done in a few weeks.It's probably a pretty good project if you actively want to learn about FPGAs, as it can be done in incremental steps - first get a VGA display working ( shoudl be able to find plenty of examples to get you going) , then render the data into it crudeley, improve until it looks "right", then add HDMI etc.

author: james_s
author_rank: Super Contributor
timestamp: February 22, 2017, 09:40:50 pm
content: If you have not done any HDL development before you are going to face a very steep learning curve. It took me around 2 years of tinkering in my free time to self-teach to the point where I can create working projects in VHDL.There's a free e-book called Free Range VHDL which I found very helpful.

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: February 22, 2017, 09:54:25 pm
content: Quote from: james_s on February 22, 2017, 09:40:50 pmDifferent people learn at different speeds and in different ways. By starting from a working example and tinkering you can get results pretty quickly. The most important thing IME is to have a definite project you want to get done, as when you hit a wall you have to figure it out, rather than just moving sideways onto something else.Depending on the sample rates etc. it may well be doable on a fast MCU, maybe with DMA. Maybe even a RasPi with a fast ADC on a FTDI hi-speed parallel-USB converter.

author: james_s
author_rank: Super Contributor
timestamp: February 22, 2017, 10:44:25 pm
content: Sure, I wasn't implying that one should not try, I'm only saying don't expect to jump in and achieve quick results and don't give up if you find yourself banging your head against the wall and getting nowhere. I found it very useful to tinker with existing projects, porting them to different FPGA hardware and modifying them. Later I moved on to taking bits of code like CPU cores and custom chips and "wiring" them together into new projects, and finally creating more of my own code. Some people will pick it up much more quickly than others, but I would say that a background in digital circuit design is of greater benefit here than programming background. The key concept to grasp with HDL is that you are *NOT WRITING A PROGRAM*, rather you are using a special language that looks like a programming language to describe the function of hardware.

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: February 22, 2017, 10:50:10 pm
content: Quote from: james_s on February 22, 2017, 10:44:25 pmAbsolutely.Another point, which I rarely see mentioned, is that process blocks (VHDL, don't know about Verilog) , which may superficially look like code, are actually expressing priority, not sequence.

author: james_s
author_rank: Super Contributor
timestamp: February 22, 2017, 11:00:11 pm
content: One other thing that occurred to me that I've seen trap beginners, forget about the schematic entry option. To the uninitiated it looks like a great idea, simply draw up your schematic and it magically turns into code that runs on the CPLD/FPGA. Well it's great for a very, very simple application to get your feet wet and validate the hardware but beyond a dozen or so gates it starts to get very unwieldy and will only slow you down. Go straight to HDL and you will be doing yourself a favor in the long run.

author: hamster_nz
author_rank: Super Contributor
timestamp: February 23, 2017, 09:48:05 am
content: The biggest hurdle I see with this project is you will need to recover the pixel clock to run the ADC at the correct speed. This is a non-trivial problem without specialist hardware - it is far outside the capabilities of the standard FPGA on-chip PLLs I know of.If you want to output HDMI (without buffering in off-chip memory, so you can resend in a different clock domain), you will need a stable recovered clock to drive the serializers.

author: BrianHG
author_rank: Super Contributor
timestamp: February 23, 2017, 10:10:45 am
content: Run a tripple RGB ADC at a full fixed speed, say 200 Mhz for a slightly cheaper FPGA & ram interface speed. The faster you go, the faster the FPGA and the higher the $$$. For clocking, use the FPGA's internal PLL to drive the clock for ADC and pick a fixed standard video mode & clock rate for the video out, again, using the FPGA second PLL to clock the HDMI transmitter and third for the ram.To generate HDMI output, use something like an analog devices ADV7510BSTZ-P.An Altera EP3C55 should do the trick as I managed to fit a complete video scaler into one with 2 video sources and picture in picture with video zoom and crop. In fact, you should have no trouble using an EP3C40.I did everything on my own for my scaler, just a warning, you are in for a year of work here if you are doing everything from scratch...

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: February 23, 2017, 10:31:35 am
content: Quote from: hamster_nz on February 23, 2017, 09:48:05 amIt's not clear what the nature of the incoming signal is - XYZ implies vector, so pixel clock isn;t an issue. If it's actually analogue raster, you can probably derive a pixel clock from the sync pulses

author: cncjerry
author_rank: Unknown
timestamp: February 23, 2017, 06:43:14 pm
content: The signal on both channels looks pretty much like a frame. It is obvious from that standpoint. The Z channel I think is just blanking so that is easy to understand. It is vector, I think they call it stroke but either way, I would think that you get an x,y pair during the non-blanking and begin drawing from there until the next drop of the blanking pulse on Z. This is just my theory at least. So I was thinking of just grabbing the x,y points and plotting them during the Z, inverse if necessary, first. Then if needed, connect the dots during the proper blanking as a next step. I looked at the signal on a scope and my primary concern is that the X and Y voltages seem to have a lot of detail so it will need to be sampled pretty hard, at least 12 bits, maybe 14 or even higher to get the detail needed.If this takes me a year, so what, I've been thinking of learning this anyway ever since my ballistic chronograph project ran out of speed using an STM32F4 board. I had tried arduinos, parallax, etc, then moved on to the STM32F4, none of them seemed fast enough and someone mentioned FPGA so I've been looking for a project to give it a try. I've been programming this stuff for almost 40yrs so I should be able to get going pretty quickly. The real question is finding an FPGA development board that has 3 channels of fast ADC and some type of easy video or display output. The simmconnlabs team did it, why can't I?Maybe I should just look at their kit to see if I can expand the display or maybe they have an HDMI output now?

author: james_s
author_rank: Super Contributor
timestamp: February 23, 2017, 06:50:12 pm
content: You might look at the rasterizer from the Asteroids implementation from fpgaarcade.com, you might have to use wayback to grab it from an old snapshop of the site as the page is in the midst of a redesign currently. Anyway it's a relatively simple bit of code that takes a vector output and converts it to VGA using an SRAM for the frame buffer. It will fit in a rather small FPGA and may do almost what you need with very little modification.

author: Richard Crowley
author_rank: Super Contributor
timestamp: February 23, 2017, 07:03:21 pm
content: We presume that the obvious solution (using a DSO) was rejected for reasons not explained here?

author: james_s
author_rank: Super Contributor
timestamp: February 23, 2017, 07:07:46 pm
content: Using a DSO to do what?Perhaps I misunderstood but I was operating under the assumption that the OP wanted to clone the output of a vector display based instrument onto an external display. This will require some sort of rasterizer but it's not likely to need anything particularly sophisticated as the update rate is not likely to be very high, nor is the required resolution.

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: February 23, 2017, 07:27:56 pm
content: Quote from: cncjerry on February 23, 2017, 06:43:14 pmThere are some boards with HDMI, e.g. Digilent Atlys, which also has a fairly big FPGA, as well as plenty of expansion to add ADCs.You should do some research to figure out the ADC parameters - if it's vector, then I can't see you'd need more than about 10 'clean' bits, corresponding to 1024 pixels. Look at the waveforms on a scope to get an idea of the highest frequency components to work out sample rate.Can you get a reasonable-looking display on a scope in XY mode?

author: Richard Crowley
author_rank: Super Contributor
timestamp: February 23, 2017, 10:09:50 pm
content: Quote from: james_s on February 23, 2017, 07:07:46 pmIf you look at it for its functionality (vs what we have named it) a DSO is exactly that, a rasterizer.Since the OP did not identify the source, we really don't know what the refresh rate is. Perhaps I am presuming that it is significantly higher than what others are imagining. I am thinking that the refresh is on the order of 20-30-50-60 Hz. And there are probably more vectors writing scales, grids and text than are actually devoted to the data curve itself.So it is a matter of "viewing" the XYZ signal on a DSO and outputing the screen to VGA or HDMI or whatever. Unless the objective here is to learn how to use FPGAs and not simply translating ZYX into some kind of raster video? I have to agree with others that this is not a trivial Arduino-sketch kind of solution. For someone with no FPGA experience it could easily take several months to accomplish. I would certainly select an FPGA based on whether there was an available HDMI solution already available. That would give a tremendous leg-up on creating an XYZ to HDMI solution.If the refresh rate is indeed low enough, it could quite possibly be a software solution for a more sophisticated microcontroller like RasPi, Beagle, Intel Galileo/Edison, etc. They have built-in, easy to use graphics output via HDMI with high-level graphics drawing commands. One could input the X, Y, and Z signals into three ADC inputs on the microcontroller and use software to track the delta voltage (=position) changes, and plot them in native graphics routines.

author: cncjerry
author_rank: Unknown
timestamp: February 24, 2017, 12:26:36 am
content: On one of my scopes, the 3054, I get a decent picture but it has all the retrace because it isn't using the blanking from the Z channel. For some reason I can't get anything readable out of my TDS784 but it could be any one of a number of reasons.Thinking about the ADC, the 8568 and the 8566 analyzers have 1000 x 1000 resolution for the trace but the vector characters look a lot nicer than that. And as someone said, I planned to not output video as much as a sequence of rasterized frames. It doesn't seem that difficult to me but then again, there is a learning curve involved.The STM32F7 boards have ADC up to 2Mhz in certain cases. For grins I am going to see if I can get anything out of one of them. Even if it is slow as in dropping frames, I should still be able to grab a picture at that rate I would think. If I get a chance I'll plot a trace of the X and Z since the X and Y are the same but different axis and post it up here.

author: Lukas
author_rank: Frequent Contributor
timestamp: February 24, 2017, 01:46:30 am
content: Depending on how fast the display updates, "random sampling" the display might be good enough. Using equivalent time sampling, I managed to digitize a VGA signal at XGA resolution using an STM32's built-in ADC. Their analog bandwidth is surprisingly high:https://www.tablix.org/~avian/blog/archives/2013/10/undersampling_with_a_microcontroller_adc/Outputting HDMI from an STM32 isn't completely out of reach as well: Simply hook up something like an ADV7513 to the STM32's display controller and you're done. Not much more difficult than VGA.

author: cncjerry
author_rank: Unknown
timestamp: February 25, 2017, 05:17:20 am
content: This isn't a project for an arduino as the ADC sample rate and overall processing isn't anywhere near where it needs to be. I think I mentioned somewhere early on that I have a bunch of 32F4 and 32F7 boards here, actually I think all of them in the non-EVM format. Tomorrow I am going to try sampling the XY during Z to see what I get out of a simple raster. I'll have to scale the Y because the board I am using I think is limited to 800 pixel vertical on the STM32F769. If I remember correctly, this board has 12Bit ADC but I don't think all the channels are exposed because some of the lines are used for the display. That could be on the DAC side; I can't remember. One of the STM32 boards has an HDMI interface of some type so if I get favorable test results then I can explore that as well. If it all comes down to speed then I'll look at FPGA options. I'll go back an reread all the comments to see if there was a solid recommendation for a starter kit.The Y signal is <1V and it occurs in 15ms. So of that 15ms, it looks like there is a lead-in and then a ramp so the variable part of the signal is 7ms. Looking at it closely on the scope, there are a lot of wiggles in that 7ms signal to be able to draw the complete display in stroke format.Something to play around with for certain. It would be pretty darn cool to have the 8566 display native on a large HDMI monitor. I love the CRT resolution on it. Both my 8568 and 8566 have great tubes, lots of life left.Thanks for the input.

author: cncjerry
author_rank: Unknown
timestamp: March 01, 2017, 05:39:01 am
content: I started a project over the weekend using an STM32F469 board as it has a DSI HDMI adapter. I didn't have a lot of time so instead of building the project in openstm, I used MBED. I was able to get 800 samples (horizontal) in about .008 seconds. The way I measured it was by using a sine wave varying the period until I had one complete wave in the 800 pixel wide display. This is using the display on the board, not HDMI. So if I use the std peripheral library and run the ADC at a higher rate, I think this board might just work. Not sure about the frame rate though as I grabbed the samples in a tight loop and then plotted them.I am traveling this week so I will run the signal thru it when I get back to see if the resolution is there.More to come.

author: explosivo85
author_rank: Newbie
timestamp: February 24, 2023, 03:18:51 pm
content: I'm not sure what ever happened with this project, but as I'm researching a similar project I have found someone who did something very similar to the project in this post.For anyone who stumbles into this thread wanting to know if it can be done, this guy made a similar project with a STM32F746G and has all of the info on his github.https://sebholzapfel.com/blog/lcd-upgrade-for-the-hp-141t-spectrum-analyzer-part-1/