This article presents the analysis of a post detector processor for SETI work based on software; that is, the characteristics of speed are relaxed to permit it to be solved by a personal computer.
In the previous article we analyzed the possibility of building a post detector processor for SETI work, and the analysis was based on the condition of getting as wide a band of operation as possible. We found that this condition requires speed and, consequently, it was necessary to do it in hardware. Before going into the details of the design of the hardware, it is interesting to analyze other possibilities.
It is an axiom of computer engineering that everything that can be done in hardware can be done in software and vice versa, usually with a change in the operating speed. The same process explained in the previous article is now implemented in software.
The following assumptions will be made for this analysis: the computer to be used is a top of the line computer, with a processor of at least the quality of the Motorola 68000, the Intel 80386, or equivalent. The computer will be expected to have enough memory for the operation, say 1/2 Megabyte of read write memory. Details will be discussed later.
The computer is expected to be connected to the telescope through an A/D converted that produces data continuously at a rate that matches the speed of operation of the computer. This data is stored in the input buffer without program or operator intervention.
The program to be considered first, takes 1024 data points from the buffer and performs the FFT on these points; the resulting frequency components are threshold and converted into 128 bytes of data, this data and the clock at the moment of the operation are stored in memory.
When eight of these values have been accumulated, the computer makes an analysis of the data. If it is found that at a given frequency, at least five of the eight components are above the threshold, the whole sample is saved, otherwise it is destroyed.
It is important to convert these specifications into conditions that represent something in the context of SETI work. First, since the process is not continuous, as explained in the previous article, the results to be obtained represent some kind of integration of the frequency characteristics of the signal during the sampling time; that is, the total time it takes to obtain a block of 1024 samples. This means that any pulse that is shorter that this time is greatly reduced in amplitude (averaged) and this will tend to reduce the effect of noise pulses of short duration.
Second, the fact that we will be looking only for components of the different samples where the same frequency is enhanced corresponds to the idea of looking at continuous signals or pulses that last at least for the sampling time of several samples, with a constant frequency. Note that any Doppler effect produced by a moving source affects only the actual frequency of operation but if the signal is of constant frequency, it will be of constant frequency after the Doppler. This is not true when we consider acceleration. If a source is in a space station in orbit around Mars, for example, the acceleration with respect to us will vary the frequency of the signal as the source goes in its orbit. If the orbital acceleration is large enough, such a signal will not be detected by the program that is being considered. The program can be changed to cover this case, at the expense of slower operation.
Since the process is slow, we will be analyzing with narrow bin width and narrow band width. It should be considered that today an Atari 1040ST, the computer used for this analysis, costs on the order of 700 dollars, so it is not illogical to consider that several computers will be used, each taking a slice of the total signal. This would not be practical with an IBM or compatible computer which runs on the order of three thousand dollars for equivalent characteristics. Computers using a 68020 or 68030 are available today and will speed up operation very much but at a higher cost. The use of a math coprocessor will speed up operation substantially without a large increase in cost.
The program to be studied is based on the use of 1024 samples to compute the FFT. This value comes from the analysis done in the previous article under different conditions. It is necessary to consider the changes that will be produced if this value is changed. Computing the FFT in software takes a time that is somewhat proportional to the double of the number of points. Working with 2048 points will take twice the time (roughly) it takes with 1024. This means that the sampling rate will be the same (double number of data points in double time), the bin width will be one half (the sample has twice the length), and the band width will be about the same (twice as many frequencies at half the spacing). More on this later.
There is another possibility, and the number of choices is quite large. The other possibility to be mentioned is to sample fast, to increase the bin width and the total band covered by the operation, but not process continuously. The system will ignore the input while the computations are taking place. Notice that any short event happening during this time will be lost. In any case, the user can select the characteristics he desires, and this is one of the most important characteristic of the software solution.
The program will have the following parts:
1) Initialization and setting parameters;
2) Get sample from the A/D converter;
3) Compute the FFT;
4) Threshold the result and store it with the clock;
5) Repeat process until eight samples are stored;
6) Get the eight samples and compare them, counting matches. If five
matches are found, abandon matching process and get new sample. If no matches
are found, put storage pointer back at the beginning, actually destroying
the sample. Go get another sample.
A program for doing this has been written in GFA BASIC, a very fast program for the Atari ST, and compiled, to make it even faster. The results are presented in next paragraph.
The program for the Atari 1040ST takes 24 seconds to process eight blocks of 1024 data points and to analyze the results. The program was written in such a way that the search for a match always fails, so this result indicates the maximum time it will take to process a block where there is no information of interest.
This time means that, if we use the constant sampling we mentioned before, we should use a sampling rate of 43 data points per second. The length of the sample will be 24 seconds, the bin width will be 1/24 of a hertz and we will cover a band width of 21 Hz. This also means that if we are using an A/D converter that connects to the computer through the RS232 port, the communication must be done at 1200 baud because each data point requires two accesses.
The Atari 1040ST permits another form of connection for the A/D converter and it is through the cartridge port. In this case the transmission rate can be much larger because it is done 16 bits at a time. In this case, the access can be up to 250,000 data points per second.
In this last case, the possibility exists of getting the program to sample the port at a fast speed and process the data as mentioned above, only in bursts. The possibility then exists to produce any bin width desired up to a maximum of 250 hertz per bin. The corresponding band covered by the operation can be as large as a maximum of 128 Khz, considering that we work with 1024 samples.
If the program is written in assembler language, instead of BASIC, an improvement in speed of the order of at least 20 times can be expected. This will not change the values given above for the maximum bin width and the maximum band width because they do not depend on the program. What will change in this case is the data that is lost. Since the program works much faster, that much data is processed and consequently, much less information is lost while the computer is processing the block.
It needs also to be noted that it is always possible to decrease the bin width, at the expense of the total band width, by letting the computer wait in between samples, until the sample is completed. There is another alternative, that reduces the bin width without reducing the total band width and is to work with more samples. A bin width of close to 1 hertz can be produced working with 2048 samples and the total band width will be 1 Khz.
To test this fact, another program was written to process blocks of 32768 samples each. Getting eight of these blocks, computing the FFT of each one and, when the eight blocks were ready, processing the eight sets of 4096 bytes each, took exactly 20 minutes; that is, 1200 seconds, or 50 times as much as with 1024 samples per block. If such a program is used to work with a sampling rate of 32768 samples per second, the bins will be 1 hertz and the total band analyzed will be 16 Khz. This alternative does not look too attractive in BASIC because we process only eight samples every 20 minutes, but in assembler language it might become interesting, where we process eight samples every minute.
The analyses presented above shows that it is possible to develop a post detector processor for SETI work totally in software, with the exception of the A/D converter that must be external to the computer. The applications of such processor are limited to narrow bin width, narrow total band width operations, unless several computers are used simultaneously on the signal.
The last analysis presented, of a program written in assembler language to process 32768 samples per block seems attractive, especially for those that do not have any other way to do any type of SETI work. Processing one block every minute or so is better than processing none at all. The attractive part is the cost. Any one of our members desiring to go this route is welcome to write me for more detailed information about the program.