Design Question: 20 MS/s data acquisition

Question

Let me preface that I am fairly new at working with sampling high speed signals. Specifically, I want to do some processing on slightly corrupt NTSC signals. For this, I need to sample at above 14.3 MHz. So suppose I want to take 12 to 16 bit samples at 16 MS/s with an ADC - that figure is reasonable enough to attain judging by the selection available. However, the challenge is in storing this result. Can someone give me any suggestions to solve this problem?

I don't yet have the schematics as it is still early in the design process. But the general idea is that I will have an ADC, which will collect samples and a microcontroller that will facilitate storing those samples.

In terms of total size, I am looking at (worst case) say:

$$\frac{16\ MS}{s} \cdot\frac{16\ bits}{S}\cdot\frac{byte}{8\ bit} = \frac{32\ MB}{s}$$

And the NTSC video source I am trying to recover is about 2 hours long worst case, so:

$$\frac{32\ MB}{s}\cdot\frac{3600\ s}{hr}\cdot\frac{2\ hr}{tape}\cdot\frac{GB}{1000\ MB} = \frac{230.4\ GB}{tape}$$

Further clarifications:

Why do I have to do this in real time: The video I am trying to restore comes from a Video8 tape, that can only be read using an old analog video recorder. The recorder spits out the content of the tape onto its NTSC port, but the data is slightly corrupted (vertical sync signal missing, horizontal line data okay). This shouldn't be too hard to fix in software if only I could digitize the tape.

Is the NTSC video in color: Yes. But as long as I can digitize the NTSC signal, I will be able to process it in software and convert it from lines -> fields -> frames.

Why not use a frame grabber: Because the video signal is corrupt. Like I mentioned before, it is missing the proper vertical sync signal. The line data, however is completely fine so I believe it is salvageable by software. A frame grabber usually uses hardware decoding for NTSC, which will not work in this case because the signal has to be processed first.

Answer 1

A microcontroller is not appropriate for what you are trying to do. The data is coming too fast for a micro to be able to do anything useful with it.

Let's say you get a micro that runs at 100 MIPs. That's really fast for a micro. New data words are coming in at 16 MHz rate. That leaves only 6¼ instructions per sample, which is probably not even enough to grab it from some input port and send it on somewhere else.

From your description, I think you're right in that software processing the stream of samples can allow for video reconstruction. However, realistically, that's not going to happen in real time. All you can hope to do in real time is store the total data, then process it into good video, or frames, or whatever you want, in a batch process later. That can afford to run as long as it takes to produce the cleaned result.

Modern disk drives you can get off the shelf for PCs can handle both the data rate and the data volume. 32 Mbytes/s and 230 Gbytes aren't pushing any limits. A USB 3.0 port on a modern PC can handle that data rate.

Your problem is therefore how to get a stream of 16 bit words at 16 MHz rate into a USB 3.0 port. I'd look around for off the shelf chips that can do this. I'd start by looking at what FTDI has to offer, but would also check out TI and others. You may need to use a small FPGA to clock the A/D, grab the data, present it as two bytes to the USB chip, etc. That's a fairly straight forward, but high speed, process well suited to a small FPGA.

Answer 2

Well, what I would do is something like this: ADC -> uC/FPGA/ARM -> PC -> HDD. My HDD on my PC can do 100 MB/s, giving you sufficient bandwidth. You can use something like the USB 3.0 FTDI or an Ethernet IC to transmit the data to the PC. It all depends with what you are familiar with, budget, what equipment you have etc. You need to ensure the processor you are using is fast enough to handle the bandwidth.

You will need to write some code for the PC to capture and store the packets. Think also how you are going to read them back for processing. If you are going to read them sequentially, you can just dump them to a file. Otherwise, it can be really annoying trying to find a packet in the middle of a 200GB dump. Look at something like B trees, if you need some structure to the data.

In order to get the maximum HDD bandwidth, you need to use large buffer sizes. Something like a 1MB buffer should enable you to get the maximum write speed. If you use a small buffer the needle will move past your sector, and you will need to wait for the hard disc to rotate, decreasing the maximum write speed achievable.

P.S. Nothing here seems too difficult. 20 MSPS isn't that fast to be honest. I've had to deal with 4GSPS systems before, and that was achievable, so your system should be relatively straight forward. I am not entirely sure where is your main difficulty. I guess it's the transfer of the data to the PC, but using USB 3.0, gigabit Ethernet, or PCIe can easily handle those bandwidths.