Hi Jesus There are two main types of delay in a system that combines signals from two antennas produced by a source;
1. Delays that are produced by the geometry of the system. The physical location of the source and antennas mean that there is a different path length the signal produced by the source must travel to each antenna. If we know the location of the source and antennas, and how they move, we can calculate this path length difference ahead of time and don't need to measure it. 2. Delays introduced by our system. These include relative delays introduced by cable length differences, phase differences in sampling clocks etc. Some of these may need to be calculated in real time as they are introduced in a way that can't be worked out ahead of time. Others will stay roughly the same (e.g cable lengths) and can be worked out once ahead of time. The problem with relative delays is that they reduce the advantage gained by combining the signals from different antennas. Once addition occurs we lose the information needed to completely remove this error unless the change in relative delay is slow compared to the rate at which we read the data back. So, we aim to remove this relative delay from each antenna signal before combining them in applications where this is important. In our FX correlator systems, we remove the relative delay in two stages; * First we remove most of the delay by writing the ADC sampled data from the signals into buffers and reading out the data again such that older samples are read from one stream while newer ones are read from the other. This allows us to align the data to an accuracy of one ADC sample. The delay_wideband_prog block in Delays does this. * At this point, the delay has not been completely removed, there is still the sub-one-ADC-sample, or fractional delay component, left. An FIR filter where the group delay can be controlled would allow us to do this in the time domain but this does not (yet) exist in the CASPER DSP library. Instead we accomplish the same effect using complex multiplication after channelisation (after the FFT). A time delay will produce a phase offset for each frequency component of your signal. For the same time delay, the magnitude of this phase offset increases with decreasing wavelength (increasing frequency). So, we multiply each FFT bin by a complex exponential with amplitude 1 and phase corresponding to the phase we need to remove from that frequency bin. We also do fringe stopping in this block. We have a block that gets updated from software with a delay and fringe value and amount these change with time. This block continuously updates the delay and fringe values and supplies them to the coarse and fractional delay compensation blocks. The actual delay and fringe value calculations are done in software though, we don't directly measure relative delays in gateware in our FPGAs. The software uses geometrical calculations, as well as measured values calculated during calibration. The advantage of measuring the relative delay directly, and compensating for this value, is that you account for all possible delays in the system and don't have to understand and model them all ahead of time. The disadvantage is the possibility that, by the time you have measured and applied it, it may have changed. This depends on the stability of your system, and on the way you measure and apply the calculated delays (you could calculate the delays early in the pipeline and pass this information with the data so that the correct delay compensation is applied to the data it was measured on). Your suggestion of capturing ADC snapshot data and using correlation would work to calculate the relative delays. The fractional delay compensation could be done as we do it. Or, as you need to revert to the time domain, you could look at developing the previously mentioned programmable group delay FIR block. I would suggest not worrying about fractional delay compensation for the moment. Build a system that uses coarse delay to remove most of your delay and see the results (this should be easy to simulate too). Use software to measure the relative delays (maybe using ADC snap shots) and see how well that does. You should not do the difficult stuff unless you need to and this basic system will help you understand the problem a lot better. > - According to your answer, all the computation in order to get the > time delay between signals is made by software and off line, instead > of calculating that delay in the FPGA and in Real Time. > So first, ¿how do you get the number of samples that the signal should > be delayed in the coarse delay block? Answered above I think. > I imagine that the signals after the ADC are stored and then, for > example in Matlab or Python, a kind of cross correlation in the time > domain is calculated in order to get that number of samples. > Please, could you confirm me this? and if it is possible could you > describe which algorithm are you using? We do correlation in the FPGA (our system will be a correlator combined with beamformer) so we get this for free. However, most delay is calculated using geometrical calculations and measurements of cable lengths etc. > - Once the coarse delay is corrected, we have to correct the > fractional delay in the frequency domain. You say you don't need to > calculate the phase difference among the different bins of the > antennas because you already know the position of the source and the > antennas... > but could you please send me an example just to know how to get those > phases... The relative path length differences caused by the geometrical setup of your system is easy to calculate using trigonometry if you know the relative positions of antennas and satellite. > - Those phase differences are calculated at the beginning and then > they don' need to be updated in the time? They may need to be updated if the geometry of the system changes or relative delays introduced by your system changes. > - How do youn choose the number of bins? Number of FFT bins? Well, the complex output for each bin is multiplied by a complex value to rotate its phase. This complex value is calculated for the center of each FFT bin. Each FFT bin actually has a band of frequencies centred on this frequency so this complex value will be too high for half the frequencies in the FFT bin, and too low for the other half leading to some error at the edges. Increasing the number of FFT bins decreases this error at the expense of extra computation. We just use the number we use for our correlator. > - How do you calculate the fringe rotation? Fringe rotation depends on the delay calculation as it is caused by the relative delay of the signals and the actual sky frequency you are measuring. > I have another question connected with the reference signal of 10 MHz. > I am using the TIMETECH equipment that is advised in the Casper web, > in order to generate a 10 MHz reference. Then all my Signal generators > use this reference signal in order to generate the clock signals for > the ADC, DAC...and also for the LNBs of the two antennas. The problem > is that, although the two LNBs are using the same reference signal, > each one has its own PLL. So I think I have a little offset between > the two signals I get from the two antennas. How Casper have solved > this problem? The important thing would be to ensure that the offset is stable. If the offset changes too quickly relative to how quickly you can measure and compensate, then it cannot be removed. If you are measuring a strong wideband signal then it should be possible to capture some ADC data and use correlation to determine the relative delays of the signal paths, then feed this value to your delay compensation system. This could be done at startup to measure this clock (and other) delays, and then done periodically to update these values. Hope all of this helps Regards Andrew
