# [sdiy] [OT] CRT + Vidicon = analog convolution?

cheater cheater cheater00social at gmail.com
Sat Jan 22 08:11:07 CET 2022

```Hi all,
I have recently stumbled upon the idea of using vidicons and CRTs for
analog convolution. Convolution of a continuous incoming signal (say
audio) with a FIR (finite impulse response) is one way of creating
echo, simulating filters, etc. By far the only method of calculating
convolution nowadays is the DFT (discrete Fourier transform), a form
of the FFT (fast Fourier transform).

I was wondering if anyone used vidicons and can confirm if this scheme
would work.

The first time I heard of vidicons being used together with CRTs was
when I read up on old TV stations and how they converted from 50 to 60
Hz or between line amounts. They essentially filmed a TV, but the
device eventually was an integrated CRT-Vidicon invention where the
CRT and Vidicon both scanned horizontally. However, if you make them
scan at 90 degrees of each other, you can use that for computation.

One way of calculating convolution is as follows. Let's assume for a
second that the signal and the FIR take values from -1 to 1. For every
sample of the signal you have coming in, call that sample s_t, you
start outputting s_t * FIR - you output all samples of the FIR
subsequently, scaled by s_t. So on this sample, you output s_t *
FIR_1, where FIR_1 is the first sample of the FIR. On the next sample,
say s_t+1, you start outputting s_t+1 * FIR, while also continuing to
play back s_t * FIR. So on the second sample you output s_t+1 * FIR_1,
but also s_t * FIR_2.

Let's say you take a CRT and break it up into, say, a grid of 100 x
100 points. Scan them horizontally from top left to bottom right.
Start out in the top left. Wait for a sample of the signal, say s_1,
to come in. Horizontally, you start outputting - using the Z channel
(brightness) - the samples s_1*FIR_1, s_1*FIR_2, etc.

Wait for the next sample to come in, and meanwhile move to the 2nd
line, and start on the second point. When sample s_2 comes in, start
outputting s_2*FIR_1, s_2*FIR_2, until you hit the end of the line,
which is s_2*FIR_99. Then wrap around to the start of the line 2
(without advancing to line 3), and output s_2*FIR_100.

So on the nth scan line, you start outputting at the nth "pixel". On
the 100th scan line, you start at the 100th pixel. Then you wrap
around to the first line and start on the 1st pixel.

Next for the Vidicon. Orient it towards the CRT, but at an angle of 90
degrees. So it should be scanning vertically, top to bottom, left to
right, starting from the top left, and ending on the bottom right. It
has scan columns rather than scan rows.

For every sample you have coming in, as you are outputting the
relevant row to the CRT, scan a single column. You can start before
the row is done outputting, because all previous rows are done, and as
for the latest row, you only care about the home pixel (the pixel that
is first put on the screen, ie for the nth line it's the nth pixel).
While scanning this, sum up the brightness over your whole scan, and
that's your output. That just calculated a convolution between the FIR
and the incoming signal. It's a 100-point convolution. Cool, right?

Here's an even cooler thing. Nothing says you have to make the FIR
have as many points as there are rows. You can make the FIR a
continuous signal. Then, you can scan that 100-row image using more
than 100 columns. Say, scan it at 400 columns. This then just means
that the FIR has a bandwidth 4x higher than the signal it's being
applied to.

And finally, of course you can output different FIR for every incoming
sample (for every incoming row). This would let you eg apply, via
convolution, a parametric filter.

Regarding practical implementation of the CRT output. For simplicity,
I described above a situation where you're outputting horizontal lines
of variable brightness in a raster. However, to preserve the phosphor,
when increasing the Z (brightness) of the trace, you would also add a
little bit of a high-frequency signal, to make the line thicker. The
vidicon and the subsequent averaging circuit will like it just as
well, and probably even better. This way you can prevent incoming hot
spots. Also it doesn't matter if the lines intersect - they might just
as well all be at the same level. However, then the phosphor might get
more hot spots, and the non-linearity of the phosphor brightness vs
cathode current might come into play. The raster was just to
illustrate the structure of the algorithm, but if you need some form
of accuracy, then you might want to keep lines from intersecting, but
at that point, why are you even doing this using a Vidicon?

```